We are using JRebel to quickly reload Java code changes into our JVM. This is working great!
But, we are also using Eclipse as IDE. And for some reason, Eclipse can really rebuild the whole project in my workspace, just because I add an annotation, I remove a method, or any other little code change ...
Because of this rebuild phase, all classes are regenerated and are required to be reloaded by JRebel.
Is there any way to debug why Eclipse is always rebuilding our project for even a stupid little code change?
I'm using Eclipse Indigo.
Thanks,
Jochen
You need to disable (or) uncheck Build Automatically.
Goto Project menu--->uncheck Build Automatically.
NOTE: This disables Automatic build. But as JesperE commented, it may impact the cause why you JRebel.
Disabling build automatically option does not break JRebel. JRebel depends on the results of the compilation, so if you disable the automatic build you will have to just compile the changed classes yourself, that's it.
You can try setting a VM argument -Drebel.check_class_hash=true which will check the checksum before reloading the classes. It may slow down the reloading time from a few milliseconds to some milliseconds extra. But it is still better than the situation when all the project classes have to be reloaded.
Related
since I've updated to IntelliJ 2016.3 on my mac, it seems like classes doesn't get recompiled if I restart my application. I always need to call mvn compile which I didn't need to do before the update. I didn't found anything that would explain such a behaviour. Am I missing something?
Edit:
With restart I mean rerun my app in debug mode. See the screenshot. (Needed to black out a few things due to security reasons)
What is the purpose of Build Automatically option in Eclipse (Project-->Build Automatically)? Mine will always be checked. But when ever I have some java code changes I still have to do a full build. I was told that it should always be checked. I don't see any benefit in doing so. Please somebody explain.
Eclipse has a good answer on their website:
You have two modes of working: auto-build mode and manual build mode. By default, you are in auto-build mode and Eclipse takes care of compiling source files automatically. Builds occur automatically in the background every time you change files in the workspace (for example saving an editor). Auto-build is convenient because it means problems view, binaries, etc. are are up-to-date at all times. The downside is that in large workspaces auto-builds can be time-consuming if you are changing files in projects with lots of downstream dependent projects.
If auto-build is taking too long and is interfering with ongoing development, it can be turned off. Once in manual build mode, the user is in complete control over when builds occur and what gets built. Project > Build All (Ctrl+B) can be invoked at any time to trigger what auto-build was doing automatically. This allows you to build up a larger set of changes before invoking a build (Eclipse remembers which files have changed so that it does not have to do more work than required when you do ask for a build.
Note that when they say "auto-build mode" they mean if you have checked "Build Automatically", when they say "manual build mode" they mean you do not have "Build Automatically" checked.
Yes, you still have to do a build - but it's done automatically when you save (not an external build like an Ant build, but the "internal" build). If you didn't want to build on save, you'd uncheck the box. Having it build automatically makes some people nervous, I believe.
NOTE
For C/C++ users it's told (from help.eclipse.org):
By default, the Eclipse workbench is configured to build projects automatically. However, for C/C++ development you should disable this option, otherwise your entire project will be rebuilt whenever, for example, you save a change to your makefile or source files. Click Project > Build Automatically and ensure there is no checkmark beside the Build Automatically menu item.
Project - Disable Autobuild option does not always mean autobuild is off. For example "Makegood" test automation plugin will trigger autobuild when Preferences - Run/Debug - launching - (General opt) Build before launch is ON. So turn it off if manual build needed.
One thing that people didn't mention here (and it took a while for me to figure this out too) is that eclipse build (either automatic or manual) would basically follow what you have outlined in the project's "Java Build Path" source tab. So when a file is covered in that build source tab, when you change the file, it gets copied/compiled to the output folder that was specified for that directory/file.
One more difference is:
Most of the time while working on JSPs it helps me when checking "Build Automatically". It automatically picks up the changes in JSPs.
But if you make changes in your java classes/XMLs you need a manual build.
Since I'm using resin server which is run outside eclipse via command prompt, i prefer checking the option.
When i have my server setup in eclipse, i turn it off and use Publish on server.
This is the way i use and the answer is based on my experience.
If Build Automatically is checked, the IDE will automatically compile your Java code whenever you modify and save a file. This does not mean it will completely build and package your entire solution as if you were going to deploy it such as if you are working in a Web project on a WAR module. It basically really just compiles your code.
We have a pretty big project. We use ant for setting the environment. One of the things that happens during the ant script is that a jar is copied to the lib folder of a project. Then, we use ant tasks: eclipse.refreshLocal and eclipse.incrementalBuild so that the jar now copied will resolve compilation problems in the project that refer to it.
Unfortunately, the projects seem unsynchronized with the filesystem. Project > properties > build path shows that the jar is present (probably information that is refresh while looking at the propertiesw) but the incrementalBuild didn't do what we expected it to do.
Also, sometimes a project that depends on this jar and we refreshed and built it (through ant) has a single compilation error: "The project cannot be resolved until build path errors are resolved". In other times, the are many compilation errors indicating the project hasn't noticed the new jar.
When I build it through eclipse, it is ok.
I was worried that maybe there are circular dependencies between the projects, but it appears the are no such dependencies (Build properties: the circular dependencies option is set to "Error", and the are no errors of this form in the projects).
Anybody is fimiliar with the problem?
What is the proper way to deal with this problem?
Thank you for your help.
If you right click on the build.xml and select Run as → Ant Build... you'll see a tab called Refresh. Just check the option Refresh resources upon completion.
(I use this myself when generating code in an ANT xslt target and it works like a charm.)
You may also want to check Refresh automatically under Window → Preferences → Workspace
Try Cleaning the entire workspace and refresh :)
One solution which might work for you is to modify the Eclipse launch config for the Ant build (Run -> External Tools -> External Tools Config), and explicitly configure it to refresh the workspace (or parts of it) when the Ant build finished. This removes the need to perform the refresh from within the Ant script itself, and it always triggers the correct build reaction when the script completes.
Eclipse does not generally like it very much if you change files in its workspace from outside. There is an option in the Eclipse Preferences to automatically sync with the filesystem, but that can be very intense with regards to IO.
And it will probably still not solve all your problems, esp. when you change library jars.
Even considering skaffman's suggestion with the Refresh on build completion, I am not sure this would really improve your situation, but give it a try.
From my experience, realistically I would have yet to see a solution in a big setup that really works and makes life easier instead of just creating a different set of problems.
So I have a maven module (module-A) in IntelliJ. I recently moved some classes from it into another new maven module (module-B) and added a dependency to it. Once I had done this I also modified the signature of a method of one of the moved classes (now in module-B).
I re-imported the poms so that IntelliJ would pick up the dependency changes and ensured all Java imports for the affected files were correct again. Now when I attempt to run my webapp (which depends on the two modules) I get a compile error in a class in module-A calling the modified method of the class in module-B.
The error message is basically saying that that method doesn't exist but believes the old method still exists! I click on the 'make' error and it takes me to the line in a class in module-A calling the modified method...the weird thing is, IntelliJ knows it is fine in the file. i.e. The method is not underlined in red like a compile error would normally be, but the class file name is :(
I compiled it from the command line using 'mvn install' (having also installed module-B) and it is all successful. I have deleted the classes directory in the target of both module-A and module-B and also invalidated IntelliJ's caches and restarted...still happening...any ideas?
I found out that this might help:
File -> Invalidate Caches
Maven Projects -> Reimport should help.
I spent a few hours on this same issue. All of the cleans in the world didn't help.
I deleted my out and target directory in my project and recompiled - that cleared it.
Edit: There is also a magic feature under the file menu: "Invalidate Caches / Restart" This fixes a bunch of "intellij is confused" problems.
Change "Java Compiler" setting in IDEA (User compiler javac in-process) to fix the problem.
Try to mvn clean your projects and mvn install your project B.
The maven integration with intelliJ is kind of buggy when you use the make command directly provided by Intellij. You should directly use the mvn commands, or start them from the maven panel.
I ran across a very similar problem that was driving me insane.
My code would compile fine with the ant task I normally run, but it would not build in IntelliJ, complaining about "Cannot Find Symbol blah blah"
Turns out, you can add "Excluded" files for the compiler. My file somehow got added to that list.
This list is located in File > Settings > Compiler > Excludes (IntelliJ 13)
Following steps should fix this problem :
delete .IntelliJIdea12 / .IdeaIC12 older under c:/user/.../
Invalidate Intelli's cache: File > Invalidate Caches.
This re-indexes your workspace on start-up and also clears your local history. Before you do this, commit or back up all your uncommitted changes.
Once your workspace is back after indexing, do a maven clean install.
when the build is successful, click on Maven Re-imports
This worked for me, I think it should work for others too with a similar problem.
So just stated it up this morning and it's all working!
Last night what I did do was open a new project (intelliJ project) from module-A's and module-B's parent pom and successfully got it to build, possibly doing that and then opening my original project again fixed it somehow...very annoying though
The behavior I see is similar to the one described by the original author.
Error markers show up on the right side of the editor in Intellij 14 and less so in 13.
This happens also if using Scala instead of Java and using SBT instead of Maven.
Also noticed this occurs after the second project is loaded. The first is always fine.
(After much trial and error) Figured it might be caused by Intellij's internal caches becoming somehow corrupt. "Invalidate caches" worked sometime and sometimes did not.
I work with a number of projects using Play! Framework and they use different versions of Scala and lots of dependencies.
I hypothesized the caches become corrupt because the internal key Intellij uses is not good enough to handle situations when the same class, loaded multiple times in different jars, has different signatures, and this results in the editor errors while external builds work fine.
Then the "Changing Ivy Cache Location for sbt projects in IntelliJ IDEA?" post gave the idea to segregate the ivy cache SBT and Intellij use in the hope that the ivy path is part of the internal cache key.
Paul Phillips of TypeSafe provide the "SBT extras" tooling and here I found a way to instruct SBT to use a project based ivy home, cache and SBT boot:
https: //raw.githubusercontent.com/paulp/sbt-extras/master/sbt
declare -r noshare_opts="-Dsbt.global.base=project/.sbtboot -Dsbt.boot.directory=project/.boot -Dsbt.ivy.home=project/.ivy"
How to configure Intellij
: see http://content.screencast.com/users/SemanticBeeng/folders/Snagit/media/ec8ec491-6d0c-4691-9598-916a63ba65ef/12.02.2014-08.59.png
Then did the same for the external SBT build to work in sync
: see http://content.screencast.com/users/SemanticBeeng/folders/Snagit/media/dcb287c4-200f-47f3-a937-42865675a22b/12.02.2014-09.01.png
Finally got rid of the user home based .ivy2 and all the contents.
To be sure Intellij does not use this folder I made it readonly.
This was a mistake. Intellij seems to silently fail resolve dependencies if you do this.
This solved the errors and believe they will not come back. :-)
If Intellij guys hear this: please test your releases (Scala, SBT, editor) with all the Play Framework templates from TypeSafe. The problem becomes apparent quickly this way.
I just had a similar issue that was driving me insane. I had done all the other things mentioned in the answers above because I have used Intellij forever, but none worked. In the end I found out that in the maven projects portion of Intellij, one of my modules had been marked "ignore" a simple unignore command from the context menu did the trick.
In my case, I had manually marked a directory as "Test Sources Root" but IDEA marked it on a parent Maven project. Unmarking it in File->Project structure...->Modules fixed the problem.
This could happen if you are using different version of java while building outside IntelljJ. My IntelliJ had java10 and I was using java8 while building at terminal. Changing java version to IntelliJ fixed this issue for me.
I had a very similar behavior. Running (Scala-)tests would always fail due to errors in unrelated java classes during the 'make' step.
It turned out, I had included a 'global' SDK library that collided with one of the dependencies from the project. A proper helpful error message only showed up after I deleted the 'make' step from the test.
I then deleted the duplicate library, re-added the make step to the test and everything is now working fine.
I ran into this problem today after upgrading from 12 to 13.
Later I fixed issue as I used the same name for Project and Module and looks Intellij allows this but cannot handle it correctly.
No idea why setting will impact the compilation, although there is no error in java editor. Should be a bug in version 13.
I was facing a similar issue after upgrading from IntelliJ 12 to 13. After multiple uninstalls and re-installs (of multiple intelliJ versions), numerous cleans and .m2 repository clearing, I finally figured out what my issue was.
In my intelliJ settings, the repositories mentioned in my main POM file could not be connected to. this was in turn due and alternate repository that was mentioned as a part of my pom file.
Once the POM was made to point to the correct repository, all my classes had their compilation issues resolved.
To check if your repositories are being connected to, go to File -> Settings -> Maven -> Repositories
Here, your indexed maven repositories should be connected to successfully. If they are not, then intelliJ will not be able to resolve most 3rd party and module dependencies.
I'm embarrassed to say, but we also had this problem, but it was due to a mistake in our package name.
When creating the packages for a new project I accidentally created a package called "org.package".
My project then had a directory structure like:
/src/main/java/org.package/
Which caused all sorts of havoc with IntilliJ.
Once the correct folder structure was created on the file system, IntelliJ worked great.
/src/main/java/org/package/
Note the difference in /org.package/ vs /org/package/
The fix was i made it javac instead of Ajc and i put 1.8 of course according to your jdk version.
for some reason when i invalidate and restart intellij it was set to be the default !
my version is
This happened to me...what fixed it was realising there was an extra main.iml file in the source directory. Deleting that instantly made the compile errors go away.
None of the above answers worked for me.
In my case, I had to finally create an explicit Maven Run Configuration for the module (with Command Line as "clean install") and then run it.
It is in Run > Edit Configurations
close the project
go-to the project folder and delete idea project file and .iws file
run mvn idea:idea
restart the project.
seems idea keeping the old project dependencies without cleaning even though we run file -> invalidate caches
Setting the proper Java SDK solves the issue
Right click on the project and select "Open Module Settings"
Check if you have the right Java SDK under platform settings
Check the SDK under Modules
Rebuild the project from "Build" menu
Delete the installation directory.
Remove the following directories:
~/.config/JetBrains/
~/.cache/JetBrains/
~/.local/share/JetBrains/
This will remove each and every configuration plus installation of jetbrains tools, be it IDEA, goland,etc.
Now install everything from scratch.
That's the only way it worked for me
New to Java and Eclipse. For some reason, the first time I load Eclipse on a given day, it freezes at "Initializing Java Tooling : 59%". Eventually, it gets past this and I can do my work. However, this "Initializing Java Tooling : 59%" stage takes a REALLY REALLY REALLY long time. Does anybody know why it does this or how to fix it?
You can take several thread dumps of the Eclipse Java process to see what plugins are being executed. Here is some info on how to take thread dumps.
What happen is that Eclipse loads all project configurations and then for each project it initializes all declared builders. The builder loading and initialization is what takes most of the time. Some builders need to resolve and/or reload project dependencies such as jars and other projects and also check if project resources had changed. This process can also trigger initialization of builders on other projects and it may take longer depending on 3rd party plugins you are using.
It breaks on a per workspace basis. I have had some success removing plugin data. Usually this can be found by at:-
[workspace-directory]/.metadata/.plugins
If you delete everything except:-
org.eclipse.core.resources
You will keep your projects but everything else will be deleted (preferences, scm repositories ... etc.) and will need to be recreated/reimported (you will be greeted by the welcome page, but do not be alarmed).
There is probably a specific set of plugin data that should be deleted, but this fixed my last occurence, and so I have nothing else against which to further hone in on the problem state ... for the time being.
Following mike's advice, I resurrected my workspace by just deleting [workspace-directory]/.metadata/.plugins/org.eclipse.jdt.core. That directory doesn't seem to store any important information.
I had this problem and found a solution here:
http://tedvinke.wordpress.com/2010/06/21/eclipse-initializing-java-tooling-hangs/
Here's what I did.
Rename the .projects folder in .metadata/.plugins/org.eclipse.core.resources
in the workspace folder. This doesn’t seem to affect any project and
the .project folder will be recreated when Eclipse restarts.
A more simple-minded approach than Eugene's very clever one is to remove all your plugins, one by one, keep notes, and watch performance after each removal. This should help pinpoint the plugin that's doing the big initialization. It's possible that you didn't really need that plugin after all.
In my experience, there is often a big delay associated with source control plugins because some feel the need to check project state against the repository on startup. There may be options to control this. You can also look at what kind of label decoration is in effect; if some decoration is dependent on repository state, that could be your time waster right there.
Be warned that this procedure may be destructive! You probably included those plugins for a reason, and if you remove the plugins it's possible you'll lose capabilities on already present projects, and that even replacing the plugins will not necessarily restore everything in all projects to the former state. As the disk repartition people say: We assume that you have everything backed up!
How about doing the following
eclipse.exe -clean
Just uncheck "Build Automatically" and force quit Eclipse. Then start it again.
Project>Build Automatically - uncheck
-force quit
-start Eclipse