Re: Activating a profile if an executable exists on the path?
If you know where the file should be, certainly: path-to-dot-file ... You can specify either or depending on what you want the profile to do > On Oct 1, 2017, at 8:25 PM, Alex O'Ree wrote: > > I've been using the umlgraph/graphviz/dot as a javadoc extension for a > while now and i was wondering how i could support builds on machines > whereby graphviz is not installed. I was thinking a profile with some > activate rules would do it that would override the javadoc settings. > Looking at the docs, it doesn't seem like this is possible. Anyhow, is > this possible? > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Activating a profile if an executable exists on the path?
I've been using the umlgraph/graphviz/dot as a javadoc extension for a while now and i was wondering how i could support builds on machines whereby graphviz is not installed. I was thinking a profile with some activate rules would do it that would override the javadoc settings. Looking at the docs, it doesn't seem like this is possible. Anyhow, is this possible? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Updating from 3.3.9 to 3.5.0 causing strange unit test failures
after further investigation, it's probably not a maven issue. On Sun, Oct 1, 2017 at 11:15 AM, Alex O'Ree wrote: > I thought i had cleaned that up. One of those, if it's not broke don't fix > it, kind of things. > > > On Sun, Oct 1, 2017 at 10:24 AM, Karl Heinz Marbaise > wrote: >> Hi, >> >> On 01/10/17 15:35, Alex O'Ree wrote: >>> >>> Apache jUDDI PMC here. >>> >>> I just spent the better part of my weekend trying to update and revamp >>> some code in Apache jUDDI and ran into a bit of strange situation that >>> is reporting worthy. >>> >>> All of our previous release builds were ran using maven 3.3.9 on >>> windows with JDK7. I recently switched to maven 3.5.0 (love the >>> colors!) and have been happily moving along without any troubles on >>> any of my projects up until now. >>> >>> I still don't understand it and can't really explain what the issue >>> is, but I'm seeing consistent unit test failures in jUDDI but only >>> when running with maven 3.5.0. I even rolled back the source code for >>> two different release version of jUDDI only see the same issue. >>> Switching back to maven 3.3.9 somehow fixes the test failures. >>> >>> I wish i could tell you all what the root cause is, but I honestly >>> have no idea. I've been subscribed to this list for probably 6 months >>> now and I don't recall seeing anything else similar in nature reported >>> so I figured I'd give this a shot. >>> >>> >>> Relevant product info >>> jUDDI is a server based web app that stores a registry of service >>> endpoints. This data is stored using JPA in an Apache Derby database >>> during unit tests. It also supports replication across multiple server >>> instances. >>> >>> Test details: >>> Tests related to server replication, in which multiple instances of >>> jUDDI are started and replication is triggered between 3 instances are >>> failing. I initially thought this may have been some kind of string to >>> byte encoding issue (it still may be). Still investigate this. >>> >>> Using surefire 2.4 with junit 4.12. >> >> >> >> based on the pom files there two definitions one for maven-surefire-plugin >> 2.4 and one for maven-surefire-plugin 2.15...which I would suggest clean >> up... >> >> Kind regards >> Karl Heinz Marbaise >> >>> >>> Steps to reproduce >>> using maven 3.5.0 with jdk7 (windows) >>> git clone https://git-wip-us.apache.org/repos/asf/juddi.git >>> mvn clean install -Pdist >>> >>> This will take a while by the way and will fail in the uddi-tck module. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Updating from 3.3.9 to 3.5.0 causing strange unit test failures
I thought i had cleaned that up. One of those, if it's not broke don't fix it, kind of things. On Sun, Oct 1, 2017 at 10:24 AM, Karl Heinz Marbaise wrote: > Hi, > > On 01/10/17 15:35, Alex O'Ree wrote: >> >> Apache jUDDI PMC here. >> >> I just spent the better part of my weekend trying to update and revamp >> some code in Apache jUDDI and ran into a bit of strange situation that >> is reporting worthy. >> >> All of our previous release builds were ran using maven 3.3.9 on >> windows with JDK7. I recently switched to maven 3.5.0 (love the >> colors!) and have been happily moving along without any troubles on >> any of my projects up until now. >> >> I still don't understand it and can't really explain what the issue >> is, but I'm seeing consistent unit test failures in jUDDI but only >> when running with maven 3.5.0. I even rolled back the source code for >> two different release version of jUDDI only see the same issue. >> Switching back to maven 3.3.9 somehow fixes the test failures. >> >> I wish i could tell you all what the root cause is, but I honestly >> have no idea. I've been subscribed to this list for probably 6 months >> now and I don't recall seeing anything else similar in nature reported >> so I figured I'd give this a shot. >> >> >> Relevant product info >> jUDDI is a server based web app that stores a registry of service >> endpoints. This data is stored using JPA in an Apache Derby database >> during unit tests. It also supports replication across multiple server >> instances. >> >> Test details: >> Tests related to server replication, in which multiple instances of >> jUDDI are started and replication is triggered between 3 instances are >> failing. I initially thought this may have been some kind of string to >> byte encoding issue (it still may be). Still investigate this. >> >> Using surefire 2.4 with junit 4.12. > > > > based on the pom files there two definitions one for maven-surefire-plugin > 2.4 and one for maven-surefire-plugin 2.15...which I would suggest clean > up... > > Kind regards > Karl Heinz Marbaise > >> >> Steps to reproduce >> using maven 3.5.0 with jdk7 (windows) >> git clone https://git-wip-us.apache.org/repos/asf/juddi.git >> mvn clean install -Pdist >> >> This will take a while by the way and will fail in the uddi-tck module.
Re: unable to generate site with module-info defined
Thanks; I have filed https://issues.apache.org/jira/browse/MJAVADOC-498 > On Oct 1, 2017, at 4:05 AM, Hervé BOUTEMY wrote: > > ok > > with 3.4, you can see "Error generating maven-javadoc-plugin:3.0.0-M1:javadoc" > you're issue is only indirectly with maven-site-plugin, but more directly > with > maven-javadoc-plugin > > reproducing this issue is then best done with "mvn javadoc:javadoc", to > directly use the offending plugin (instead of trying to aggregate every > report) > > > then with 3.5.1: if you look at the end of the stacktrace: >> Caused by: java.lang.StringIndexOutOfBoundsException: begin 0, end 3, length > 1 >> at java.base/java.lang.String.checkBoundsBeginEnd(String.java:3116) >> at java.base/java.lang.String.substring(String.java:1885) >> at > org.apache.commons.lang.SystemUtils.getJavaVersionAsFloat(SystemUtils.java: > 1133) > you'll find a typical issue with Java 9 when some lib expects java version to > be 1.x and finds 9.x in Java 9 > This time, the issue is maven-site-plugin, it was discusse on users@maven.a.o > just one week ago, and Robert Scholte is currently releasing the fix in Doxia > Sitetools 1.7.5 > The issue is tracked with: > - https://issues.apache.org/jira/browse/MSITE-796 at maven-site-plugin level, > - and https://issues.apache.org/jira/browse/DOXIASITETOOLS-177 at Doxia > Sitetools level > > And, as any Java 9 compatibility issue, it should be tracked on our Java 9 > Wiki page: https://cwiki.apache.org/confluence/display/MAVEN/Java+9+-+Jigsaw > > I see that we forgot to trace MSITE-796: I'll add it soon. > > > Pfeewww, to summarize, you're mixing 2 independant issues: > - javadoc:javadoc issue, not yet precisely understood, but which is the > initial issue > - known site plugin issue with Java 9, fixed in latest snapshots but not yet > in > any release > > to continue our investigations, please stay with maven-site-plugin 3.4, and > run "mvn javadoc:javadoc": perhaps you found a new issue with this plugin > regarding Java 9 modules > > Regards, > > Hervé > > Le samedi 30 septembre 2017, 21:57:00 CEST Russell Gold a écrit : >> And here is the stack trace with 3.5.1: >>> at >>> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBui >>> ldPluginManager.java:183) at >>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.ja >>> va:208) ... 20 more >>> >>> Caused by: org.apache.maven.plugin.PluginContainerException: An API >>> incompatibility was encountered while executing >>> org.apache.maven.plugins:maven-site-plugin:3.5.1:site: >>> java.lang.ExceptionInInitializerError: null >>> - >>> realm =plugin>org.apache.maven.plugins:maven-site-plugin:3.5.1 >>> strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy >>> urls[0] = >>> file:/Users/rgold/.m2/repository/org/apache/maven/plugins/maven-site-plug >>> in/3.5.1/maven-site-plugin-3.5.1.jar urls[1] = >>> file:/Users/rgold/.m2/repository/org/apache/maven/reporting/maven-reporti >>> ng-exec/1.2/maven-reporting-exec-1.2.jar urls[2] = >>> file:/Users/rgold/.m2/repository/org/apache/maven/reporting/maven-reporti >>> ng-api/3.0/maven-reporting-api-3.0.jar urls[3] = >>> file:/Users/rgold/.m2/repository/org/apache/maven/shared/maven-shared-uti >>> ls/0.3/maven-shared-utils-0.3.jar urls[4] = >>> file:/Users/rgold/.m2/repository/com/google/code/findbugs/jsr305/2.0.1/js >>> r305-2.0.1.jar urls[5] = >>> file:/Users/rgold/.m2/repository/org/sonatype/aether/aether-util/1.7/aeth >>> er-util-1.7.jar urls[6] = >>> file:/Users/rgold/.m2/repository/org/eclipse/aether/aether-util/0.9.0.M2/ >>> aether-util-0.9.0.M2.jar urls[7] = >>> file:/Users/rgold/.m2/repository/org/apache/maven/maven-aether-provider/3 >>> .0/maven-aether-provider-3.0.jar urls[8] = >>> file:/Users/rgold/.m2/repository/org/codehaus/plexus/plexus-interpolation >>> /1.14/plexus-interpolation-1.14.jar urls[9] = >>> file:/Users/rgold/.m2/repository/org/codehaus/plexus/plexus-component-ann >>> otations/1.5.5/plexus-component-annotations-1.5.5.jar urls[10] = >>> file:/Users/rgold/.m2/repository/org/sonatype/plexus/plexus-sec-dispatche >>> r/1.3/plexus-sec-dispatcher-1.3.jar urls[11] = >>> file:/Users/rgold/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/pl >>> exus-cipher-1.4.jar urls[12] = >>> file:/Users/rgold/.m2/repository/org/apache/maven/maven-archiver/2.5/mave >>> n-archiver-2.5.jar urls[13] = >>> file:/Users/rgold/.m2/repository/org/sonatype/sisu/sisu-inject-bean/1.4.2 >>> /sisu-inject-bean-1.4.2.jar urls[14] = >>> file:/Users/rgold/.m2/repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu- >>> guice-2.1.7-noaop.jar urls[15] = >>> file:/Users/rgold/.m2/repository/org/codehaus/plexus/plexus-archiver/2.9/ >>> plexus-archiver-2.9.jar urls[16] = >>> file:/Users/rgold/.m2/repository/org/codehaus/plexus/plexus-io/2.4/plexus >>> -io-2.4.jar urls[17] = >>> file:/Users/rgold/.m2/repository/org/apache/commons/commons-compress/1.9/
Re: Updating from 3.3.9 to 3.5.0 causing strange unit test failures
Hi, On 01/10/17 15:35, Alex O'Ree wrote: Apache jUDDI PMC here. I just spent the better part of my weekend trying to update and revamp some code in Apache jUDDI and ran into a bit of strange situation that is reporting worthy. All of our previous release builds were ran using maven 3.3.9 on windows with JDK7. I recently switched to maven 3.5.0 (love the colors!) and have been happily moving along without any troubles on any of my projects up until now. I still don't understand it and can't really explain what the issue is, but I'm seeing consistent unit test failures in jUDDI but only when running with maven 3.5.0. I even rolled back the source code for two different release version of jUDDI only see the same issue. Switching back to maven 3.3.9 somehow fixes the test failures. I wish i could tell you all what the root cause is, but I honestly have no idea. I've been subscribed to this list for probably 6 months now and I don't recall seeing anything else similar in nature reported so I figured I'd give this a shot. Relevant product info jUDDI is a server based web app that stores a registry of service endpoints. This data is stored using JPA in an Apache Derby database during unit tests. It also supports replication across multiple server instances. Test details: Tests related to server replication, in which multiple instances of jUDDI are started and replication is triggered between 3 instances are failing. I initially thought this may have been some kind of string to byte encoding issue (it still may be). Still investigate this. Using surefire 2.4 with junit 4.12. based on the pom files there two definitions one for maven-surefire-plugin 2.4 and one for maven-surefire-plugin 2.15...which I would suggest clean up... Kind regards Karl Heinz Marbaise Steps to reproduce using maven 3.5.0 with jdk7 (windows) git clone https://git-wip-us.apache.org/repos/asf/juddi.git mvn clean install -Pdist This will take a while by the way and will fail in the uddi-tck module. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Updating from 3.3.9 to 3.5.0 causing strange unit test failures
Hi, On 01/10/17 15:35, Alex O'Ree wrote: Apache jUDDI PMC here. I just spent the better part of my weekend trying to update and revamp some code in Apache jUDDI and ran into a bit of strange situation that is reporting worthy. All of our previous release builds were ran using maven 3.3.9 on windows with JDK7. I recently switched to maven 3.5.0 (love the colors!) and have been happily moving along without any troubles on any of my projects up until now. I still don't understand it and can't really explain what the issue is, but I'm seeing consistent unit test failures in jUDDI but only when running with maven 3.5.0. I even rolled back the source code for two different release version of jUDDI only see the same issue. Switching back to maven 3.3.9 somehow fixes the test failures. I wish i could tell you all what the root cause is, but I honestly have no idea. I've been subscribed to this list for probably 6 months now and I don't recall seeing anything else similar in nature reported so I figured I'd give this a shot. Relevant product info jUDDI is a server based web app that stores a registry of service endpoints. This data is stored using JPA in an Apache Derby database during unit tests. It also supports replication across multiple server instances. Test details: Tests related to server replication, in which multiple instances of jUDDI are started and replication is triggered between 3 instances are failing. I initially thought this may have been some kind of string to byte encoding issue (it still may be). Still investigate this. Using surefire 2.4 with junit 4.12. Are you really using maven-surefire-plugin version 2.4 which is from 2008 ? Have you correctly defined to use maven-surefire-plugin 2.4 somewhere ? First I would suggest to keep Maven 3.3.9 and upgrade maven-surefire-plugin to newer versions and see if it does not break anything... Afterwards I would upgrade to Maven 3.5.0... Kind regards Karl Heinz Marbaise Steps to reproduce using maven 3.5.0 with jdk7 (windows) git clone https://git-wip-us.apache.org/repos/asf/juddi.git mvn clean install -Pdist This will take a while by the way and will fail in the uddi-tck module. Switching to maven 3.3.9 will work though - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Updating from 3.3.9 to 3.5.0 causing strange unit test failures
Apache jUDDI PMC here. I just spent the better part of my weekend trying to update and revamp some code in Apache jUDDI and ran into a bit of strange situation that is reporting worthy. All of our previous release builds were ran using maven 3.3.9 on windows with JDK7. I recently switched to maven 3.5.0 (love the colors!) and have been happily moving along without any troubles on any of my projects up until now. I still don't understand it and can't really explain what the issue is, but I'm seeing consistent unit test failures in jUDDI but only when running with maven 3.5.0. I even rolled back the source code for two different release version of jUDDI only see the same issue. Switching back to maven 3.3.9 somehow fixes the test failures. I wish i could tell you all what the root cause is, but I honestly have no idea. I've been subscribed to this list for probably 6 months now and I don't recall seeing anything else similar in nature reported so I figured I'd give this a shot. Relevant product info jUDDI is a server based web app that stores a registry of service endpoints. This data is stored using JPA in an Apache Derby database during unit tests. It also supports replication across multiple server instances. Test details: Tests related to server replication, in which multiple instances of jUDDI are started and replication is triggered between 3 instances are failing. I initially thought this may have been some kind of string to byte encoding issue (it still may be). Still investigate this. Using surefire 2.4 with junit 4.12. Steps to reproduce using maven 3.5.0 with jdk7 (windows) git clone https://git-wip-us.apache.org/repos/asf/juddi.git mvn clean install -Pdist This will take a while by the way and will fail in the uddi-tck module. Switching to maven 3.3.9 will work though - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: unable to generate site with module-info defined
ok with 3.4, you can see "Error generating maven-javadoc-plugin:3.0.0-M1:javadoc" you're issue is only indirectly with maven-site-plugin, but more directly with maven-javadoc-plugin reproducing this issue is then best done with "mvn javadoc:javadoc", to directly use the offending plugin (instead of trying to aggregate every report) then with 3.5.1: if you look at the end of the stacktrace: > Caused by: java.lang.StringIndexOutOfBoundsException: begin 0, end 3, length 1 > at java.base/java.lang.String.checkBoundsBeginEnd(String.java:3116) > at java.base/java.lang.String.substring(String.java:1885) > at org.apache.commons.lang.SystemUtils.getJavaVersionAsFloat(SystemUtils.java: 1133) you'll find a typical issue with Java 9 when some lib expects java version to be 1.x and finds 9.x in Java 9 This time, the issue is maven-site-plugin, it was discusse on users@maven.a.o just one week ago, and Robert Scholte is currently releasing the fix in Doxia Sitetools 1.7.5 The issue is tracked with: - https://issues.apache.org/jira/browse/MSITE-796 at maven-site-plugin level, - and https://issues.apache.org/jira/browse/DOXIASITETOOLS-177 at Doxia Sitetools level And, as any Java 9 compatibility issue, it should be tracked on our Java 9 Wiki page: https://cwiki.apache.org/confluence/display/MAVEN/Java+9+-+Jigsaw I see that we forgot to trace MSITE-796: I'll add it soon. Pfeewww, to summarize, you're mixing 2 independant issues: - javadoc:javadoc issue, not yet precisely understood, but which is the initial issue - known site plugin issue with Java 9, fixed in latest snapshots but not yet in any release to continue our investigations, please stay with maven-site-plugin 3.4, and run "mvn javadoc:javadoc": perhaps you found a new issue with this plugin regarding Java 9 modules Regards, Hervé Le samedi 30 septembre 2017, 21:57:00 CEST Russell Gold a écrit : > And here is the stack trace with 3.5.1: > > at > > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBui > > ldPluginManager.java:183) at > > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.ja > > va:208) ... 20 more > > > > Caused by: org.apache.maven.plugin.PluginContainerException: An API > > incompatibility was encountered while executing > > org.apache.maven.plugins:maven-site-plugin:3.5.1:site: > > java.lang.ExceptionInInitializerError: null > > - > > realm =plugin>org.apache.maven.plugins:maven-site-plugin:3.5.1 > > strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy > > urls[0] = > > file:/Users/rgold/.m2/repository/org/apache/maven/plugins/maven-site-plug > > in/3.5.1/maven-site-plugin-3.5.1.jar urls[1] = > > file:/Users/rgold/.m2/repository/org/apache/maven/reporting/maven-reporti > > ng-exec/1.2/maven-reporting-exec-1.2.jar urls[2] = > > file:/Users/rgold/.m2/repository/org/apache/maven/reporting/maven-reporti > > ng-api/3.0/maven-reporting-api-3.0.jar urls[3] = > > file:/Users/rgold/.m2/repository/org/apache/maven/shared/maven-shared-uti > > ls/0.3/maven-shared-utils-0.3.jar urls[4] = > > file:/Users/rgold/.m2/repository/com/google/code/findbugs/jsr305/2.0.1/js > > r305-2.0.1.jar urls[5] = > > file:/Users/rgold/.m2/repository/org/sonatype/aether/aether-util/1.7/aeth > > er-util-1.7.jar urls[6] = > > file:/Users/rgold/.m2/repository/org/eclipse/aether/aether-util/0.9.0.M2/ > > aether-util-0.9.0.M2.jar urls[7] = > > file:/Users/rgold/.m2/repository/org/apache/maven/maven-aether-provider/3 > > .0/maven-aether-provider-3.0.jar urls[8] = > > file:/Users/rgold/.m2/repository/org/codehaus/plexus/plexus-interpolation > > /1.14/plexus-interpolation-1.14.jar urls[9] = > > file:/Users/rgold/.m2/repository/org/codehaus/plexus/plexus-component-ann > > otations/1.5.5/plexus-component-annotations-1.5.5.jar urls[10] = > > file:/Users/rgold/.m2/repository/org/sonatype/plexus/plexus-sec-dispatche > > r/1.3/plexus-sec-dispatcher-1.3.jar urls[11] = > > file:/Users/rgold/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/pl > > exus-cipher-1.4.jar urls[12] = > > file:/Users/rgold/.m2/repository/org/apache/maven/maven-archiver/2.5/mave > > n-archiver-2.5.jar urls[13] = > > file:/Users/rgold/.m2/repository/org/sonatype/sisu/sisu-inject-bean/1.4.2 > > /sisu-inject-bean-1.4.2.jar urls[14] = > > file:/Users/rgold/.m2/repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu- > > guice-2.1.7-noaop.jar urls[15] = > > file:/Users/rgold/.m2/repository/org/codehaus/plexus/plexus-archiver/2.9/ > > plexus-archiver-2.9.jar urls[16] = > > file:/Users/rgold/.m2/repository/org/codehaus/plexus/plexus-io/2.4/plexus > > -io-2.4.jar urls[17] = > > file:/Users/rgold/.m2/repository/org/apache/commons/commons-compress/1.9/ > > commons-compress-1.9.jar urls[18] = > > file:/Users/rgold/.m2/repository/org/codehaus/plexus/plexus-i18n/1.0-beta > > -7/plexus-i18n-1.0-beta-7.jar urls[19] = > > file:/Users/rgold/.m2/repository/org/codehaus/plexus/plexus-uti
