I'm looking around in my ~/.gradle folder (relocated to P:\caches\gradle, which doesn't affect this behaviour) and I found some strange folders.
In the past I have updated multiple projects from 2.0 to 2.1 via running gradle wrapper which updated project\gradle\wrapper\gradle-wrapper.properties
I just found out that for some reason the exact same distributionUrl zip file was downloaded multiple times. As you can see they all have the same size and I did a binary diff, they're the same bit by bit except the timestamps:
The contents of each folder above look like this:
I just updated from 2.2 to 2.2.1 and it happened again: this time it's 2 folders not 3. Does anyone know why this happens?
I'm using Gradle from both IntelliJ Idea and the command line.
Related
I have seen variants of this question asked, but I have not seen an answer that was accepted. I am using IntelliJ IDEA to simply compile the TraversDemo sample plug in that Neo4J posted on GitHub. When I run mvn clean package I get no errors. But when I actually tried putting the .jar file into my plug ins folder on Neo4J Desktop . . . neo4j didn't recognize the plug in. So, I assumed something was wrong with my .jar file and I just tried to 'build' the java file in IntelliJ. When I did, I get this error:
Module 'TraversalPlugIn' production: java.lang.UnsupportedClassVersionError: org/neo4j/annotations/api/PublicApiAnnotationProcessor has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 54.0
I have checked and rechecked my Java (for Windows 10) is Java 8. I checked the Java Configuration GUI and asked for updates. It said I had the most recent version. Does anyone have any idea how to solve this? I already tried screwing around with various options in Build,Execution,Deployment Java compiler. No combination seemed to work.
I finally fixed this. The solution was: (i) cut existing java code (and POM file); (ii) delete original project altogether; (iii) create a new maven project but choose JDK 16 as SDK this time; and (iv) paste Java code and POM xml into new project. Then I built it, and ran maven clean package, inserted the target snapshot into the plug ins folder and ... it finally worked.
We are working on a a system that uses cloud runner, where we have a tech like Spring + Gradle plus Mongo.
The system is containerized and runs on cloud-run in gcp. However, gcp has a hard limit of 2gb on container size, which we are trying to fit into, as of now.
Upon deeper investigation, I found that, the gradle wrapper that we use downloads at least 170mb extra than what we needed.
It includes following -
It contains documentation, which is not needed while running a build via wrapper.
It does not delete the zip file after extracting the same..
Together it counts to 270 mb, which quite big for us.. What I want to know is, Is there any wrapper configuration OOTM that will help me avoid these extra files being downloaded on our system?
It seems you used the Gradle distribution type "all", which includes source code and the Gradle documentation (e.g., for IDE support -- source).
Since you run the Gradle wrapper in the cloud, you probably do not require IDE support: Use distribution type "bin". At least in latest versions of Gradle (version 7) this is the default, but you can still be explicit to make sure:
# gradle wrapper --gradle-version 7.0.2 --distribution-type bin
The size difference is about 200 MB:
# du -hs ~/.gradle/wrapper/dists/gradle-7.0.2-{all,bin}
438M ~/.gradle/wrapper/dists/gradle-7.0.2-all
229M ~/.gradle/wrapper/dists/gradle-7.0.2-bin
Gradle still keeps the zip-file, so you will have to delete that manually.
For us, this what we went with.
Although we used gradle wrapper, We also made sure that we install relavent gradle wrapper upfront on the machine, so that when we run gradlew command, we dont download it again.
When you download gradle wrapper while building image, you have liberty to delete the file from the filesystem while building container image. So you can free up some space.
Next step is you can squash the image to remove all unnecessary layers. How can i remove layers from my docker image?
I made changes to Intellij Community Edition (ce). I can compile and run those changes from within the IntelliJ editor. That launches a second instance of IntelliJ ce which is running from classes containing my changes. What I want to do is just run those changes without having to first load the source, compile and run from within IntelliJ.
Netbeans made this easy by just producing an executable as a result of the build. With Intellij, it's not at all clear what has to be done. I have tried the following-
using the Run configuration Intellij itself uses to run the altered classes- this includes setting the working directory , main class, vm options and classpath. Actually, this doesn't work for reasons unknown to me.
on someone's suggestion, running dist.gant in build. This blows up with very many errors which are not helpful (no class def found errors which indicate some confusion on Intellij's part on classpaths somewhere)
Running WinLauncher.exe under bin gives the error message that it can't find VM options file (although it's in bin, (and also for good measure under bin/win with the other files which are co-located with vmoptions in the intellij directory structure for Intellij proper. )
ALl this is just harder than it should be. The solution is to provide an executable as a result of the build and place it in a predictable location.
Has anyone ever actually DONE what I am trying to do- make changes to the community source then use the resultant editor not as a project you're working with in IntelliJ but as the Intellij editor you're working through?
FOLLOW UP
User60561 had the correct answer. Just to mop up the details, in artifacts, there is a compressed file (win.zip for Windows, mac.zip for Mac etc.). In order to run your snapshot, you have to unzip this archive (after which it will have the same name, minus the zip extension) then go into folder "bin". There you'll see two executables: idea.exe and idea64.exe, for 32 and 64 bit versions, respectively. Clicking on these runs your snapshot.
Adjusting contents of the files idea.exe.vmoptions and idea64.exe.vmoptions lets you set the VM parameters to suit yourself, typically people might want to give the VM more memory through the -Xmx value.
It seems straightforward:
To build the distribution archive of IntelliJ IDEA Community Edition, execute build.xml Ant build script in the root directory of the source code. The results of the build execution can be found at out/artifacts.
https://github.com/JetBrains/intellij-community#building
So download ant, and run ant in the directory that you have it stored in. Make sure to use the commandline to launch ant in order to make sure everything is working correctly.
Initially execute getPlugins.bat/sh, then:
Use update.bat/sh according to it's instructions
Or
Click on: Main Menu | Build | IntelliJ IDEA CE build
Copy content of intellij-community\out\deploy (lib, plugins folder) into existing IJ installation (sometimes it is better to delete existing folders if they contain older dependencies or when the installation was of Ultimate version)
My IDEA 10.5.2 hilights all guava (10.0.1) classes with error (no class found). But code is compilling correctly. I have this trouble only with guava jar's. Other jar's warks correctly.
I try to change guava version and jdk version (1.6, 1.7) and idea version but there is no result.
What am i doing wrong?
IntelliJ's indexes must not be seeing the class files, even if javac is. Depending on how your project is set up, your build process may have a different classpath than IntelliJ's indexes. At least as likely, though, is simply the presence of some corrupt entry in IntelliJ's indexes. Either way, do the following:
From the "Project Structure" dialog (in the File menu), go to the Libraries screen and ensure that the guava jar or its parent folder is listed in one of your libraries
In the same dialog's Modules screen, ensure that the above library is listed in your module.
Exit the dialog and click File -> Invalidate Caches.
Restart IntelliJ. This might take awhile.
With the information given, I can't be sure this is your problem, but it's always the steps I go through when a library mysteriously stops working (which happens more often than I'd like...).
[Answering this old question as I came across this situation even in Idea Community Edition 2019.3.1]
For me it had been due to a change in the version of the library in the build.gradle file, and the solution was to recreate the project in a fresh folder
(or maybe I could've deleted some .idea or cache folders).
It mainly depends on the version of the library in the build.gradle file.
In my case, at first, the version of the library referred to was an earlier version and everything worked fine.
compile group: 'com.google.guava', name: 'guava', version: 'r05'
Later, had to use a newer version of the library and some classes in this new version.
compile group: 'com.google.guava', name: 'guava', version: '23.5-jre'
Since build.gradle was updated, the project built fine as a gradle task.
IntelliJ hadn't got updated - though usually it does after a change in the gradle file.
Even after trying to mess around with File->Project Structure, and File->Invalidate Cache and Restart, etc... it hadn't worked, and finally recreating the project seemed to be a good workaround.
Ok, so I've got a somewhat complicated problem with my build environment that I'm trying to deal with.
I have a solution file that contains multiple C# projects which is built by a NAnt script calling MSBuild - passing MSBuild the name of the solution file and a path to copy the binaries to. This is because I want my automated build environment (CruiseControl.Net) to create a folder named after the revision of each build - this way I can easily go back to previous binaries for any reason.
So idealy I have a folder layout like this
c:\build\nightly\rev1
c:\build\nightly\rev2
c:\build\nightly\rev3
...
c:\build\nightly\rev10
etc.
The problem that's arisen is I recently added the latest version of the Unity IoC container to my project, checking it directly out of MS's online SVN repository. What's happening is I have a Silverlight 3 project that references the Silverlight version of Unity but I also have other projects (namely my Unit testing project) that reference the standard (non-Silverlight) version of Unity.
So what happens is since MSBuild is dumping everything into one single folder the Silverlight version of the Unity assembly is overwriting the non-Silverlight version because they have the exact same assembly file name.
Then when CruistControl runs my unit tests they fail because they don't have the proper dependencies available anymore (they try to load the Silverlight specific Unity assembly which obviously doesn't work).
So what I want to do is:
keep my desired output directory
structure (folder\revision)
I don't want to have to manually edit
every single proj file I have as this
is error prone when adding new
projects to the solution
Idealy I would like MSBuild to put everything into a folder structure similar to this:
nightly\revision1\project1
nightly\revision1\project2
nightly\revision1\project3
...
nightly\revision2\project1
nightly\revision2\project2
nightly\revision2\project3
etc
I can't modify the Unity project to give it a different file name because it comes from another SVN repository I cannot commit changes to. I found a similar question posted here and the suggested solution was to use a "master" MSBuild file that used a custom task to extract all the project file names out of the solution then loop over each one building them. I tried that but it doesn't build them in the order of their dependencies, so it fails for my project.
Help?
Firstly I would always have the build server delete the old working copy and check out a fresh copy to avoid any problems with stale artifacts from the previous build.
Next I would have nant or msbuild build the solutions as before with the artifacts from each build going to their local working output folders.
After that I'd move the artifacts from their working paths to their output paths, this shouldn't require digging through the project files since you can just tell msbuild/nant to copy working\project1\bin\release\**\*.* to artifacts\project1\.
The script that does this should ideally be stored along with the source with the main file, e.g. build.nant or build.proj in top level of the trunk.
For third party libraries I would simple include the DLLs directory in your repository. Nothing worse than writing some code and having a third party dependency break your build because of changes on their end.
Simply document the versions of the libraries you are using, and if you must update them, you'll have a better sense of what breaks the build before you even check it in.
Also, doesn't CC.Net automatically handle the providing of releases based on revision? I'm using TeamCity and it keeps a copy of the artifacts of every build.
I highly recommend reading JP Boodhoo's Automating Builds with NAnt blog series. That's been my starting point and have made lots of changes for my own taste. I also highly recommend checking out the builds of many open sources projects for examples. I've learned a lot from the builds of the Castle/Nhibernate/Rhino-Tools stack.