Community
Participate
Working Groups
I constantly run into this issue and none of the remedies that I've found on Stack Overflow seemed to help. Whenever I activate "Build Automatically", building starts to hang with two alternating states that are illustrated in the attached "sleeping-1.png" and "sleeping-2.png" screenshots. I have also attached 5 randomly collected thread dumps ("jstack-N.txt"), if this helps. In jstack-1.txt, I might have had a lucky punch that showed some activity in M2E's invoking the JAXB plugin, which generates new files: "Worker-104" #15544 prio=5 os_prio=0 tid=0x0000000051fbb800 nid=0x2c9c runnable [0x00000000549ca000] java.lang.Thread.State: RUNNABLE at java.util.zip.Inflater.inflateBytes(Native Method) at java.util.zip.Inflater.inflate(Unknown Source) - locked <0x00000000d7da9850> (a java.util.zip.ZStreamRef) at java.util.zip.InflaterInputStream.read(Unknown Source) at sun.misc.Resource.getBytes(Unknown Source) at java.net.URLClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.access$100(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) - locked <0x00000000d86cb430> (a java.lang.Object) at java.lang.ClassLoader.loadClass(Unknown Source) at org.jvnet.annox.parser.XAnnotationParser.parseField(XAnnotationParser.java:182) at org.jvnet.annox.parser.XAnnotationParser.parseFields(XAnnotationParser.java:139) at org.jvnet.annox.parser.XAnnotationParser.parse(XAnnotationParser.java:86) at org.jvnet.jaxb2_commons.plugin.annotate.AnnotatePlugin.annotate(AnnotatePlugin.java:387) at org.jvnet.jaxb2_commons.plugin.annotate.AnnotatePlugin.annotateClassOutline(AnnotatePlugin.java:268) at org.jvnet.jaxb2_commons.plugin.annotate.AnnotatePlugin.processClassOutline(AnnotatePlugin.java:153) at org.jvnet.jaxb2_commons.plugin.annotate.AnnotatePlugin.run(AnnotatePlugin.java:115) at com.sun.tools.xjc.model.Model.generateCode(Model.java:294) at org.jvnet.mjiip.v_2_2.XJC22Mojo.generateCode(XJC22Mojo.java:65) at org.jvnet.mjiip.v_2_2.XJC22Mojo.doExecute(XJC22Mojo.java:40) at org.jvnet.mjiip.v_2_2.XJC22Mojo.doExecute(XJC22Mojo.java:26) at org.jvnet.jaxb2.maven2.RawXJC2Mojo.doExecute(RawXJC2Mojo.java:309) Maybe, there is really a loop between XJC / M2E / and the resources listener, which thinks that a new build has to be triggered! I profiled this with Oracle's Java Mission Control, whose results I have also attached ("profiler-N.png") I'm happy to provide additional information, if needed.
Created attachment 239941 [details] Symptom: Build task is sleeping (1)
Created attachment 239942 [details] Symptom: Build task is sleeping (2)
Created attachment 239943 [details] Thread dump (1)
Created attachment 239944 [details] Thread dump (2)
Created attachment 239946 [details] Thread dump (3)
Created attachment 239947 [details] Thread dump (4)
Created attachment 239948 [details] Thread dump (5)
Created attachment 239949 [details] Profiler (1) - M2E building
Created attachment 239950 [details] Profiler (2) - DeltaProcessor listening and firing all the time
Some version information: Eclipse Version: Kepler Service Release 1 Build id: 20130919-0819 M2E Version 1.4.0.20130601-037 Although... After having seen this issue here (https://bugs.eclipse.org/bugs/show_bug.cgi?id=203058) and after having uninstalled all SVN plugins, everything worked smoothly again :-/ So, I'm not sure if this is really an Eclipse issue
Stephan, this looks almost the same as your bug 417735 (and also m2e with SVN).
Lukas, are you able to prepare reproducible test case that you could attach to this bug? This would greatly help us to troubleshoot this problem further.
I might have some time on Monday.
(In reply to Lukas Eder from comment #13) > I might have some time on Monday. Thanks! Can you also attach a screen shot with the bottom part of profiler output (the remaining third part of the output)? I expect we should see there some SVN resource change listener that is probably interacting with m2e.
I will, on Monday :-)
Moving to platform for investigation.
(In reply to Szymon Ptaszkiewicz from comment #11) > Stephan, this looks almost the same as your bug 417735 (and also m2e with > SVN). Yes, thanks for making the connection. I'm curious to see if the profiler data will reveal more than my manual debugging.
Guys, I'm sorry, I cannot seem to reproduce this easily...
(In reply to Lukas Eder from comment #18) > Guys, I'm sorry, I cannot seem to reproduce this easily... Thanks for trying. Let us know when you see it again.
This is most likely a user problem (of sorts). Although m2e does not do this by default, the user is able to force execution of Maven plugins during Eclipse workspace build. Forcing execution of "incompatible" maven plugins (as defined in [1]) results in endless workspace build. I can have a closer look and tell for sure this this is the case if somebody provides me with a small standalone example that demonstrates the problem. [1] https://wiki.eclipse.org/M2E_compatible_maven_plugins
(In reply to Igor Fedorenko from comment #20) > This is most likely a user problem (of sorts). I guess m2e is free to give an error message exactly when the dangerous situation happens, and precisely point to the user's fault. In that case m2e would be free of all suspicion :) Anyway, I just observed another instance of this issue on a project that normally builds just fine. Profiler showed activity at - org.eclipse.core.internal.events.AutoBuildJob.run() ... - org.eclipse.m2e.core.internal.builder.MavenBuilder.build() ... - org.apache.maven.plugin.resources.ResourceMojo.execute() - org.eclipse.jdt.internal.core.builder.JavaBuilder.build() - org.eclipse.team.svn.ui.decorator.SVNLightweightDecorator.decorate() ... - org.eclipse.team.core.subscribers.Subscriber.accept() ... - org.eclipse.team.svn.core.synchronize.AbstractSVNSubscriber.getDiff() In this state the project in question had a build error in Eclipse because a subdirectory of target/test-classes could not be deleted (I had a shell open in that directory, as a Linux-native I keep forgetting that Windows cannot delete what someone is looking at). And here's the rub: the very moment I made a "cd ../.." in that shell, the build error disappeared *and* the infinite build loop came to an end. Does this ring a bill with anybody?
(In reply to Stephan Herrmann from comment #21) > Anyway, I just observed another instance of this issue on a project that > normally builds just fine. Profiler showed activity at This doesn't tell me much, full stacks would be more helpful. > In this state the project in question had a build error in Eclipse because a > subdirectory of target/test-classes could not be deleted (I had a shell open > in that directory, as a Linux-native I keep forgetting that Windows cannot > delete what someone is looking at). > > And here's the rub: the very moment I made a "cd ../.." in that shell, the > build error disappeared *and* the infinite build loop came to an end. > > Does this ring a bill with anybody? Interesting. It seems that workspace state could be involved, but I don't know how doing "cd ../.." outside Eclipse could break the endless loop. Maybe auto-refresh kicks in? I just fixed bug 368376 related to refresh which impacted m2e build, so if that bug was related, hopefully after M6 things will get better. Regarding general problems with m2e build, here is a tip from Igor copied from bug 368376 comment 2: "As a side note, m2e provides "Maven Workspace Build" view that helps troubleshooting endless workspace builds. When enabled, the view shows resource deltas that trigger invocation of MavenBuilder and also about resources changed through m2e APIs. Although not perfect, it often gives enough clues to help understand the problem."
(In reply to Szymon Ptaszkiewicz from comment #22) > > Interesting. It seems that workspace state could be involved, but I don't > know how doing "cd ../.." outside Eclipse could break the endless loop. > Maybe auto-refresh kicks in? I just fixed bug 368376 related to refresh > which impacted m2e build, so if that bug was related, hopefully after M6 > things will get better. Builders tend to do less amazing things when they hit exceptions. For example, I 95% certain JavaBuidler will escalate build from incremental to full mode when it runs into exceptions, which may explain the observed endless build. > > Regarding general problems with m2e build, here is a tip from Igor copied > from bug 368376 comment 2: > > "As a side note, m2e provides "Maven Workspace Build" view that helps > troubleshooting endless workspace builds. When enabled, the view shows > resource deltas that trigger invocation of MavenBuilder and also about > resources changed through m2e APIs. Although not perfect, it often gives > enough clues to help understand the problem." Loosely related to this problem -- if there was a way for me to somehow observe incoming and outgoing resource deltas for each workspace builder invocation, I'd be able to extend that view to work for all projects and builders, not just m2e.
Lukas, have you seen this problem recently or maybe you have some more info about it?
*** This bug has been marked as a duplicate of bug 417735 ***
