Re: plugin:descriptor fails with java.util.NoSuchElementException
wow, nice idea I noticed the issue for a long time, but never figured out the link with Java 7 nor this idea of fix that is so "magic"... thank you for the help Regards, Hervé Le vendredi 30 novembre 2018, 05:11:56 CET Gabriel Belingueres a écrit : > Indeed, that seems to be the case. It magically worked after replacing the > following line: > http://codehaus-plexus.github.io/plexus-utils/xref/org/codehaus/plexus/util/ > xml/PrettyPrintXMLWriter.html#L307 > > with this: > String element = elementStack.removeLast(); > write( "" ); > > I will soon create the issue and PR. > > Gabriel > > El jue., 29 de nov. de 2018 a la(s) 15:25, Robert Scholte ( > > rfscho...@apache.org) escribió: > > At builds.apache.org: > > Java version: 1.7.0_79, vendor: Oracle Corporation > > > > Local > > Java version: 1.7.0_80, vendor: Oracle Corporation > > > > does seem to be Java7 only... > > I need to check this for a longer period, but might be a good conclusion. > > > > thanks, > > Robert > > > > > > On Thu, 29 Nov 2018 04:54:59 +0100, Gabriel Belingueres > > > > wrote: > > > Hi Robert: > > > > > > I'm testing it and getting *consistently* the same exception with this > > > config: > > > > > > Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; > > > 2018-10-24T15:41:47-03:00) > > > Maven home: C:\productos\apache-maven-3.6.0\bin\.. > > > Java version: 1.7.0_80, vendor: Oracle Corporation, runtime: C:\Program > > > Files\Java\jdk1.7.0_80\jre > > > Default locale: es_AR, platform encoding: Cp1252 > > > OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows" > > > > > > (actually it is a win 10 but it fails to recognze it). > > > > > > It works OK when remote debugging with mvnDebug. > > > > > > Don't know why throws a NoSuchElementException when trying to remove an > > > element on a non empty LinkedList...my best guess is that it is some > > > sort > > > of bug in the hotspot optimization of the JVM. > > > > > > Which Java 7 specific update is running on Jenkins? > > > > > > Gabriel > > > > > > El mar., 27 de nov. de 2018 a la(s) 17:52, Robert Scholte ( > > > > > > rfscho...@apache.org) escribió: > > >> Hi, > > >> > > >> sometimes the maven-plugin-plugin fails to write the plugin descriptor > > >> and > > >> exits with the exception below. > > >> I see the same unreliable behavior on our Jenkins servers too, > > >> re-running > > >> often fixes the issue. > > >> I have seen the issue several times locally when running with mvn.cmd, > > >> so > > >> far never with mvnDebug.cmd and always running with default #threads. > > >> I can't find a reason why elementStack[1] gets out of sync. > > >> > > >> If there are others experiencing the same or similar issues, please > > >> share > > >> your analysis. > > >> Hopefully we can solve this instability issue soon. > > >> > > >> thanks, > > >> Robert > > >> > > >> [1] > > > > http://codehaus-plexus.github.io/plexus-utils/xref/org/codehaus/plexus/uti > > l/xml/PrettyPrintXMLWriter.html#L40> > > >> [ERROR] Failed to execute goal > > >> org.apache.maven.plugins:maven-plugin-plugin:3.5.2:descriptor > > >> (default-descriptor) on project maven-javadoc-plugin: Execution > > >> default-descriptor of goal > > >> org.apache.maven.plugins:maven-plugin-plugin:3.5.2:descriptor failed. > > >> NoSuchElementException -> [Help 1] > > >> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to > > >> execute > > >> goal org.apache.maven.plugins:maven-plugin-plugin:3.5.2:descriptor > > >> (default-descriptor) on project maven-javadoc-plugin: Execution > > >> default-descriptor of goal > > >> org.apache.maven.plugins:maven-plugin-plugin:3.5.2:descriptor failed > > >> > > >> > > >> > > >> Caused by: java.util.NoSuchElementException > > >> > > >> at java.util.LinkedList.removeLast (LinkedList.java:281) > > >> at org.codehaus.plexus.util.xml.PrettyPrintXMLWriter.endElement > > >> > > >> (PrettyPrintXMLWriter.java:297) > > >> > > >> at > > > > org.apache.maven.tools.plugin.generator.PluginDescriptorGenerator.writeDes > > criptor> > > >> (PluginDescriptorGenerator.java:175) > > >> > > >> - > > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > >> For additional commands, e-mail: dev-h...@maven.apache.org > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: plugin:descriptor fails with java.util.NoSuchElementException
Indeed, that seems to be the case. It magically worked after replacing the following line: http://codehaus-plexus.github.io/plexus-utils/xref/org/codehaus/plexus/util/xml/PrettyPrintXMLWriter.html#L307 with this: String element = elementStack.removeLast(); write( "" ); I will soon create the issue and PR. Gabriel El jue., 29 de nov. de 2018 a la(s) 15:25, Robert Scholte ( rfscho...@apache.org) escribió: > At builds.apache.org: > Java version: 1.7.0_79, vendor: Oracle Corporation > > Local > Java version: 1.7.0_80, vendor: Oracle Corporation > > does seem to be Java7 only... > I need to check this for a longer period, but might be a good conclusion. > > thanks, > Robert > > > On Thu, 29 Nov 2018 04:54:59 +0100, Gabriel Belingueres > wrote: > > > Hi Robert: > > > > I'm testing it and getting *consistently* the same exception with this > > config: > > > > Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; > > 2018-10-24T15:41:47-03:00) > > Maven home: C:\productos\apache-maven-3.6.0\bin\.. > > Java version: 1.7.0_80, vendor: Oracle Corporation, runtime: C:\Program > > Files\Java\jdk1.7.0_80\jre > > Default locale: es_AR, platform encoding: Cp1252 > > OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows" > > > > (actually it is a win 10 but it fails to recognze it). > > > > It works OK when remote debugging with mvnDebug. > > > > Don't know why throws a NoSuchElementException when trying to remove an > > element on a non empty LinkedList...my best guess is that it is some sort > > of bug in the hotspot optimization of the JVM. > > > > Which Java 7 specific update is running on Jenkins? > > > > Gabriel > > > > El mar., 27 de nov. de 2018 a la(s) 17:52, Robert Scholte ( > > rfscho...@apache.org) escribió: > > > >> Hi, > >> > >> sometimes the maven-plugin-plugin fails to write the plugin descriptor > >> and > >> exits with the exception below. > >> I see the same unreliable behavior on our Jenkins servers too, > >> re-running > >> often fixes the issue. > >> I have seen the issue several times locally when running with mvn.cmd, > >> so > >> far never with mvnDebug.cmd and always running with default #threads. > >> I can't find a reason why elementStack[1] gets out of sync. > >> > >> If there are others experiencing the same or similar issues, please > >> share > >> your analysis. > >> Hopefully we can solve this instability issue soon. > >> > >> thanks, > >> Robert > >> > >> [1] > >> > >> > http://codehaus-plexus.github.io/plexus-utils/xref/org/codehaus/plexus/util/xml/PrettyPrintXMLWriter.html#L40 > >> > >> > >> > >> [ERROR] Failed to execute goal > >> org.apache.maven.plugins:maven-plugin-plugin:3.5.2:descriptor > >> (default-descriptor) on project maven-javadoc-plugin: Execution > >> default-descriptor of goal > >> org.apache.maven.plugins:maven-plugin-plugin:3.5.2:descriptor failed. > >> NoSuchElementException -> [Help 1] > >> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to > >> execute > >> goal org.apache.maven.plugins:maven-plugin-plugin:3.5.2:descriptor > >> (default-descriptor) on project maven-javadoc-plugin: Execution > >> default-descriptor of goal > >> org.apache.maven.plugins:maven-plugin-plugin:3.5.2:descriptor failed > >> > >> > >> > >> Caused by: java.util.NoSuchElementException > >> at java.util.LinkedList.removeLast (LinkedList.java:281) > >> at org.codehaus.plexus.util.xml.PrettyPrintXMLWriter.endElement > >> (PrettyPrintXMLWriter.java:297) > >> at > >> > org.apache.maven.tools.plugin.generator.PluginDescriptorGenerator.writeDescriptor > >> > >> (PluginDescriptorGenerator.java:175) > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: For 3.6.1 - MNG-5995 and MNG-6069
Hi, branches for MNG-5995 and MNG-6069 ready in maven core - build passed https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/MNG-5995/ https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/MNG-6069v2/ Please review. BR Sylwester czw., 8 lis 2018 o 20:52 Karl Heinz Marbaise napisał(a): > Hi, > > On 08/11/18 20:33, Sylwester Lachiewicz wrote: > > Hi Karl, today i removed my branches with fixes and proposals from gitbox > > and leave only PR in Github for easier commenting. > > As I mentioned already ...create the branches on maven-core (gitbox > url). The branches will be mirrored to github as well...otherwise we > have no check with our CI which is vital... > > Apart from that you can comment the commit on branches in GitHub...we > don't loose anything (maybe some convenience..)...But it might be good > thing to check with INFRA if that can be improved more ... > > Kind regards > Karl Heinz Marbaise > > > > > Sylwester > > > > czw., 8 lis 2018 o 20:18 użytkownik Karl Heinz Marbaise < > khmarba...@gmx.de> > > napisał: > > > >> Hi Sylwester, > >> > >> On 08/11/18 20:00, Sylwester Lachiewicz wrote: > >>> Hi, I have 2 fixes (leftovers from 3.6.0) ready to merge - anyone to > >> review? > >>> > >>> [MNG-6069] https://github.com/apache/maven/pull/153 > >> > >> I can't see the code in the branch MNG-6069 ...(Ok..was originally mine > >> but you can simply push (force) that code on that branch). hijack > >> that branch ... > >> > >> Furthermore if I check the old branch (If this is the correct one): > >> > >> > https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/slach-build8/ > >> > >> That contains test failures... > >> > >> So -1 to merge... > >> > >> > >>> [MNG-5995] https://github.com/apache/maven/pull/185 > >> > >> Unfortunately I don't see a branch here as well which has been built on > >> CI ... > >> > >> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/ > >> whch job? > >> > >> It would be great if you could create an appropriate branch on Maven > >> Core named by the issue which is built on CI ... > >> > >> so I have to say -1 here as well... > >> > >> > >> Kind regards > >> Karl Heinz Marbaise > >> > >>> > >>> Sylwester > >>> > >> > > >
Second ITs - MNG-6513 and MNG-6521
Looking for someone to second 2 fixes to ITs MNG-6513 Migrate Plexus Javadoc tags to annotations - we still use deprecated solution here MNG-6521 Prepare ITs to tests with Java 12 - with the latest enablement of Java 12-ea we can try to use for testing - no surprise here, for me tests looks green. I'm also working on MNG-5995 - to remove a dependency on maven-compat and unfortunately lots of plugins/tests still depends on Maven 2.x code. So question is - should we also migrate ITs to 3.x or keep as-is forever? BR Sylwester
Re: plugin:descriptor fails with java.util.NoSuchElementException
At builds.apache.org: Java version: 1.7.0_79, vendor: Oracle Corporation Local Java version: 1.7.0_80, vendor: Oracle Corporation does seem to be Java7 only... I need to check this for a longer period, but might be a good conclusion. thanks, Robert On Thu, 29 Nov 2018 04:54:59 +0100, Gabriel Belingueres wrote: Hi Robert: I'm testing it and getting *consistently* the same exception with this config: Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T15:41:47-03:00) Maven home: C:\productos\apache-maven-3.6.0\bin\.. Java version: 1.7.0_80, vendor: Oracle Corporation, runtime: C:\Program Files\Java\jdk1.7.0_80\jre Default locale: es_AR, platform encoding: Cp1252 OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows" (actually it is a win 10 but it fails to recognze it). It works OK when remote debugging with mvnDebug. Don't know why throws a NoSuchElementException when trying to remove an element on a non empty LinkedList...my best guess is that it is some sort of bug in the hotspot optimization of the JVM. Which Java 7 specific update is running on Jenkins? Gabriel El mar., 27 de nov. de 2018 a la(s) 17:52, Robert Scholte ( rfscho...@apache.org) escribió: Hi, sometimes the maven-plugin-plugin fails to write the plugin descriptor and exits with the exception below. I see the same unreliable behavior on our Jenkins servers too, re-running often fixes the issue. I have seen the issue several times locally when running with mvn.cmd, so far never with mvnDebug.cmd and always running with default #threads. I can't find a reason why elementStack[1] gets out of sync. If there are others experiencing the same or similar issues, please share your analysis. Hopefully we can solve this instability issue soon. thanks, Robert [1] http://codehaus-plexus.github.io/plexus-utils/xref/org/codehaus/plexus/util/xml/PrettyPrintXMLWriter.html#L40 [ERROR] Failed to execute goal org.apache.maven.plugins:maven-plugin-plugin:3.5.2:descriptor (default-descriptor) on project maven-javadoc-plugin: Execution default-descriptor of goal org.apache.maven.plugins:maven-plugin-plugin:3.5.2:descriptor failed. NoSuchElementException -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-plugin-plugin:3.5.2:descriptor (default-descriptor) on project maven-javadoc-plugin: Execution default-descriptor of goal org.apache.maven.plugins:maven-plugin-plugin:3.5.2:descriptor failed Caused by: java.util.NoSuchElementException at java.util.LinkedList.removeLast (LinkedList.java:281) at org.codehaus.plexus.util.xml.PrettyPrintXMLWriter.endElement (PrettyPrintXMLWriter.java:297) at org.apache.maven.tools.plugin.generator.PluginDescriptorGenerator.writeDescriptor (PluginDescriptorGenerator.java:175) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MNG-6530 - Please fix or revert important regression from MNG-6311
Hi guys, Another kind of projects (after IDEs) that may be affected by this issue and receiving out of date MavenProject from Project.build(...) can be for example CI systems ( https://github.com/jenkinsci/maven-dependency-update-trigger-plugin/blob/53ba25f12ee37ef221a9cfe81f9841a0270961b9/src/main/java/org/jvnet/hudson/plugins/mavendepsupdate/MavenUpdateChecker.java ) whose lifetime and amount of processed poms could be much bigger than what IDEs do. (For those who are not reading the bug, just be informed that Eclipse IDE, NetBeans and IntelliJ are affected too).
Re: MNG-6530 - Please fix or revert important regression from MNG-6311
Hi guys, Thanks for your answer. I like the proposal of the system property to disable this bug. Let's continue discussion on the Jira ticket. Cheers,
Re: MNG-6530 - Please fix or revert important regression from MNG-6311
Hi, On 28/11/18 21:21, Robert Scholte wrote: On Wed, 28 Nov 2018 17:13:32 +0100, Mickael Istria wrote: Hi, I'm writing that in the context of some maintenance work in Eclipse m2e. Eclipse m2e likes to use the latest Maven release, but we identified (and shared it publicly on the bugtracker before the 3.6.0 release) that MNG-6311 was a risky change. We unfortunately didn't have the opportunity to prove our point back then, which probably didn't help our concerns to be taken into account seriously. This is a bit too black/white to me. Every software change could be considered a risky change and to improve Maven we must make changes. MNG-6311 is a response to MNG-6030 and based on the improve performance by that patch it seemed like we were on the right way. Should we not apply this patch for a *potential* risk for M2Eclipse? Considering both pros and cons it does make sense to apply the patch. Now we know that it did effect m2eclipse we need to move forward. IMHO reverting is not the right answer. As proposed in MNG-6530 in the worst case we need to introduce a system property to control the cache, but I really hope we (Maven team and Eclipse team) can cooperate to find a better solution. +1 agreed Kind regards Karl Heinz thanks, Robert Still, now we have more time for it, and we demonstrated with a JUnit test that MNG-6311, despite all the shiny effect of a performance improvement in some cases, actually introduces a severe regression that makes all downstream adopters keeping a ProjectBuilder instance for a long term usage in a context where pom files can change (like m2e does) are basically broken by the change as it will ignore modifications on pom files when resolving dependencies. The test case I attached to MNG-6350 shows that by reverting the commit introduced by MNG-6311, everything is back to green and modifications of pom files are properly taken into account. On MNG-6350, I've put some notes about what seems easily achievable after 1.5 day of work on this topic (which isn't much, especially for someone who never wrote a line of code for Maven so far), but I have the impression no proper fix can be easily reached (at least by me). So I'd like the Maven community to 1. help finding a solution for MNG-6350 before the next release, and 2. if no solution seems achievable for next release, consider reverting MNG-6311 so the downstream community can safely adopt it. Note that this is part of a longer story of improving the state of m2e in general, both technically, in term of internal community and in term of interaction with the Maven project. We are aiming at making m2e able to work more and more closely from Maven snapshots and staging builds to report such issues earlier and have the opportunity to prevent regressions to happen in Maven. We'll probably share more messages about it in the next weeks/months. Cheers, - - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
