[jira] (SUREFIRE-773) surefire forked processes not always killed after timeout
[
https://jira.codehaus.org/browse/SUREFIRE-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360597#comment-360597
]
Tibor Digana commented on SUREFIRE-773:
---
We will send command to the forked process via in-stream and exit the
subproces. All options including timeout will be considered.
> surefire forked processes not always killed after timeout
> -
>
> Key: SUREFIRE-773
> URL: https://jira.codehaus.org/browse/SUREFIRE-773
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 2.8
> Environment: 64 bit RHEL 5.5 , 64-bit Java 1.6.0_23
>Reporter: David Biesack
>
> Our forked JUnit/surefire processes are not always stopping correctly when
> timing out within a Maven build
> (running inside our Jenkins CI server, ver 1.425).
> The maven build finishes and Jenkins shows a failed/unstable build.
> These running processes cause problems later, because the tests may be
> holding a resource like a port, and subsequent rebuilds fail because the
> tests fail.
> For example, even though no Maven builds are currently running, ps shows
> about a dozen Java processes running,
> with commands such as:
> {noformat}
> /usr/local/java-1.6_23/jre/bin/java -Xms1g -Xmx5g
> -Djava.library.path=/u/jenkinsci/.hudson/jobs/rtolap.jtt.tests/workspace/target/lib
> \
>-jar
> /u/jenkinsci/.hudson/jobs/rtolap.jtt.tests/workspace/target/surefire/surefirebooter1374560535780866887.jar
> \
>
> /u/jenkinsci/.hudson/jobs/rtolap.jtt.tests/workspace/target/surefire/surefire65313...
> /usr/local/java-1.6_23/jre/bin/java -Xmx2g -Xms1g
> -Djava.library.path=/u/jenkinsci/.hudson/jobs/rtolap/workspace/target/lib \
>-jar
> /u/jenkinsci/.hudson/jobs/rtolap/workspace/target/surefire/surefirebooter6814971258434039335.jar
> \
>
> /u/jenkinsci/.hudson/jobs/rtolap/workspace/target/surefire/surefire5806103969370259371tmp
> /u/jenkinsci/...
> ...
> {noformat}
> We have our Maven surefire preferences set to fork the tests (via a parent
> pom)
> {code:xml|title=pom.xml excerpt}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.8
>
> once
>
> 720
>
>
> {code}
> I suspect the timeout is the problem - i.e. perhaps the test is timing out
> and the attempt to kill the forked process
> fails, leaving it running.
> Has anyone seen something similar and/or know how to fix this so that
> surefire *really* kills the process?
> When this happens, doing
> kill
> (logged in as the process owner) usually does not work, but
> kill -9
> does.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-773) surefire forked processes not always killed after timeout
[
https://jira.codehaus.org/browse/SUREFIRE-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-773.
-
Resolution: Duplicate
Should be solved in https://jira.codehaus.org/browse/SUREFIRE-524
> surefire forked processes not always killed after timeout
> -
>
> Key: SUREFIRE-773
> URL: https://jira.codehaus.org/browse/SUREFIRE-773
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 2.8
> Environment: 64 bit RHEL 5.5 , 64-bit Java 1.6.0_23
>Reporter: David Biesack
>
> Our forked JUnit/surefire processes are not always stopping correctly when
> timing out within a Maven build
> (running inside our Jenkins CI server, ver 1.425).
> The maven build finishes and Jenkins shows a failed/unstable build.
> These running processes cause problems later, because the tests may be
> holding a resource like a port, and subsequent rebuilds fail because the
> tests fail.
> For example, even though no Maven builds are currently running, ps shows
> about a dozen Java processes running,
> with commands such as:
> {noformat}
> /usr/local/java-1.6_23/jre/bin/java -Xms1g -Xmx5g
> -Djava.library.path=/u/jenkinsci/.hudson/jobs/rtolap.jtt.tests/workspace/target/lib
> \
>-jar
> /u/jenkinsci/.hudson/jobs/rtolap.jtt.tests/workspace/target/surefire/surefirebooter1374560535780866887.jar
> \
>
> /u/jenkinsci/.hudson/jobs/rtolap.jtt.tests/workspace/target/surefire/surefire65313...
> /usr/local/java-1.6_23/jre/bin/java -Xmx2g -Xms1g
> -Djava.library.path=/u/jenkinsci/.hudson/jobs/rtolap/workspace/target/lib \
>-jar
> /u/jenkinsci/.hudson/jobs/rtolap/workspace/target/surefire/surefirebooter6814971258434039335.jar
> \
>
> /u/jenkinsci/.hudson/jobs/rtolap/workspace/target/surefire/surefire5806103969370259371tmp
> /u/jenkinsci/...
> ...
> {noformat}
> We have our Maven surefire preferences set to fork the tests (via a parent
> pom)
> {code:xml|title=pom.xml excerpt}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.8
>
> once
>
> 720
>
>
> {code}
> I suspect the timeout is the problem - i.e. perhaps the test is timing out
> and the attempt to kill the forked process
> fails, leaving it running.
> Has anyone seen something similar and/or know how to fix this so that
> surefire *really* kills the process?
> When this happens, doing
> kill
> (logged in as the process owner) usually does not work, but
> kill -9
> does.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-327) Changes in r1643577 have removed Site Plugin version requirement
[
https://jira.codehaus.org/browse/MPIR-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MPIR-327:
Fix Version/s: 2.8
> Changes in r1643577 have removed Site Plugin version requirement
>
>
> Key: MPIR-327
> URL: https://jira.codehaus.org/browse/MPIR-327
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 2.8
>
>
> Revision [1643577|http://svn.apache.org/r1643577] claims to remove
> configuration already inherited from the parent but the parent does not
> contain Site Plugin version requirement.
> {code}
>
>
>
> org.apache.maven.plugins
> maven-plugin-plugin
>
>
> 1.5
>
>
> Maven Site Plugin
> 3.0
>
>
>
>
>
>
>
> {code}
> That information needs to be restored.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-327) Changes in r1643577 have removed Site Plugin version requirement
[
https://jira.codehaus.org/browse/MPIR-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MPIR-327:
---
Assignee: Michael Osipov
> Changes in r1643577 have removed Site Plugin version requirement
>
>
> Key: MPIR-327
> URL: https://jira.codehaus.org/browse/MPIR-327
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 2.8
>
>
> Revision [1643577|http://svn.apache.org/r1643577] claims to remove
> configuration already inherited from the parent but the parent does not
> contain Site Plugin version requirement.
> {code}
>
>
>
> org.apache.maven.plugins
> maven-plugin-plugin
>
>
> 1.5
>
>
> Maven Site Plugin
> 3.0
>
>
>
>
>
>
>
> {code}
> That information needs to be restored.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAR-192) Sporadic NPE in maven-jar-plugin:2.5:jar
[
https://jira.codehaus.org/browse/MJAR-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360599#comment-360599
]
Michael Osipov commented on MJAR-192:
-
Not helpful if you do not provide how to reproduce the issue.
> Sporadic NPE in maven-jar-plugin:2.5:jar
>
>
> Key: MJAR-192
> URL: https://jira.codehaus.org/browse/MJAR-192
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.5
> Environment: win 2008 server x64 java 8u25 maven 3.2.5
>Reporter: Alexander Ashitkin
>
> Strange npe at jar goal:
> {code}
> 16:41:50 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-jar-plugin:2.5:jar (default-jar) on project
> my-model: Error assembling JAR: NullPointerException -> [Help 1]
> 16:41:50 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-jar-plugin:2.5:jar (default-jar)
> on project my-model: Error assembling JAR
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:188)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:184)
> 16:41:50 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 16:41:50 at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 16:41:50 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 16:41:50 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 16:41:50 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 16:41:50 at java.lang.Thread.run(Thread.java:745)
> 16:41:50 Caused by: org.apache.maven.plugin.MojoExecutionException: Error
> assembling JAR
> 16:41:50 at
> org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:233)
> 16:41:50 at
> org.apache.maven.plugin.jar.AbstractJarMojo.execute(AbstractJarMojo.java:251)
> 16:41:50 at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 16:41:50 ... 11 more
> 16:41:50 Caused by: java.lang.NullPointerException
> 16:41:50 at
> org.apache.maven.project.MavenProject.getArtifacts(MavenProject.java:715)
> 16:41:50 at
> org.apache.maven.project.MavenProject.deepCopy(MavenProject.java:1218)
> 16:41:50 at
> org.apache.maven.project.MavenProject.(MavenProject.java:197)
> 16:41:50 at
> org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:501)
> 16:41:50 at
> org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:226)
> 16:41:50 ... 14 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5749) Support installation of Maven via GVM (Groovy Versions Manager)
[ https://jira.codehaus.org/browse/MNG-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360600#comment-360600 ] Michael Osipov commented on MNG-5749: - I understand, though I highly doubt that any Maven developer will contribute anything to resolve that issue. I do not even know who has what to provide. I guess this issue will linger for a year and then will be closed due to inactvitiy. > Support installation of Maven via GVM (Groovy Versions Manager) > --- > > Key: MNG-5749 > URL: https://jira.codehaus.org/browse/MNG-5749 > Project: Maven > Issue Type: Improvement > Components: Deployment >Affects Versions: 3.2.5 > Environment: Mac OS & *NIX >Reporter: Sean Gilligan > > Installing and managing Maven versions could be made much easier with GVM. > GVM works great for managing Groovy, Grails, and Gradle versions. As far as I > know there is no technical reason it couldn't install and manage Maven as > well. > The GVM developers have no plans to add support for 'maven', but they may > accept a contribution. In the meantime I'm using Homebrew on Mac OS X, but > GVM would be much nicer. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-327) Changes in r1643577 have removed Site Plugin version requirement
[
https://jira.codehaus.org/browse/MPIR-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360601#comment-360601
]
Herve Boutemy commented on MPIR-327:
good catch, thank you: removing jdk requirement configuration was intentional,
but not site plugin requirement
I discover the site plugin requirement configuration, didn't ever see the
config nor the result :)
Notice that I don't see any result on
http://maven.apache.org/plugins-archives/maven-project-info-reports-plugin-2.7/project-summary.html
even if the config was already in code (I don't know for how long):
http://svn.apache.org/viewvc/maven/plugins/tags/maven-project-info-reports-plugin-2.7/pom.xml?revision=1481609&view=markup
And in fact, I'm not convinced by this config, because:
1. the m-project-info-report-p doesn't really require m-site-p at all: it can
be used standalone
2. it doesn't require any specific version
it doesn't really make any harm, I don't have strong problem with it, but I'd
like to understand the documentation intent
> Changes in r1643577 have removed Site Plugin version requirement
>
>
> Key: MPIR-327
> URL: https://jira.codehaus.org/browse/MPIR-327
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 2.8
>
>
> Revision [1643577|http://svn.apache.org/r1643577] claims to remove
> configuration already inherited from the parent but the parent does not
> contain Site Plugin version requirement.
> {code}
>
>
>
> org.apache.maven.plugins
> maven-plugin-plugin
>
>
> 1.5
>
>
> Maven Site Plugin
> 3.0
>
>
>
>
>
>
>
> {code}
> That information needs to be restored.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-327) Changes in r1643577 have removed Site Plugin version requirement
[
https://jira.codehaus.org/browse/MPIR-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360602#comment-360602
]
Michael Osipov commented on MPIR-327:
-
You are looking at the wrong site, look here:
http://maven.apache.org/plugins-archives/maven-project-info-reports-plugin-2.7/plugin-info.html#System_Requirements
But I think you are right, even though. We cannot enforce a version, especially
when it is not run as a report. We should leave it out. I would close as not a
bug if you agree.
> Changes in r1643577 have removed Site Plugin version requirement
>
>
> Key: MPIR-327
> URL: https://jira.codehaus.org/browse/MPIR-327
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 2.8
>
>
> Revision [1643577|http://svn.apache.org/r1643577] claims to remove
> configuration already inherited from the parent but the parent does not
> contain Site Plugin version requirement.
> {code}
>
>
>
> org.apache.maven.plugins
> maven-plugin-plugin
>
>
> 1.5
>
>
> Maven Site Plugin
> 3.0
>
>
>
>
>
>
>
> {code}
> That information needs to be restored.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-762) Add support for test compile and test runtime separation
[ https://jira.codehaus.org/browse/SUREFIRE-762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-762: - Assignee: Tibor Digana > Add support for test compile and test runtime separation > > > Key: SUREFIRE-762 > URL: https://jira.codehaus.org/browse/SUREFIRE-762 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Surefire Plugin >Affects Versions: 2.9 >Reporter: Aslak Knutsen >Assignee: Tibor Digana > Attachments: SUREFIRE-762 > > > In some cases it is interesting to bind surefire to multiple execution > targets but have it operate on different classpaths. > e.g: > - Have the same test suite run against multiple JPA providers; EclipseLink > and Hibernate > - Arquillian test suite run against Tomcat and Jetty > In these cases you would have the TestCompile scope defined in your normal > dependency chain scoped as "test", while you can tell surefire to activate > another profile during test. > TestCompile = JPA API > TestRuntime = Hibernate | EclipseLink > Example: > https://gist.github.com/1155271 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-762) Add support for test compile and test runtime separation
[ https://jira.codehaus.org/browse/SUREFIRE-762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360603#comment-360603 ] Tibor Digana commented on SUREFIRE-762: --- @Aslak You can use different dependencies in profiles instead of profiles in surefire execution. Are you still interested in this fix, or should i close this? > Add support for test compile and test runtime separation > > > Key: SUREFIRE-762 > URL: https://jira.codehaus.org/browse/SUREFIRE-762 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Surefire Plugin >Affects Versions: 2.9 >Reporter: Aslak Knutsen >Assignee: Tibor Digana > Attachments: SUREFIRE-762 > > > In some cases it is interesting to bind surefire to multiple execution > targets but have it operate on different classpaths. > e.g: > - Have the same test suite run against multiple JPA providers; EclipseLink > and Hibernate > - Arquillian test suite run against Tomcat and Jetty > In these cases you would have the TestCompile scope defined in your normal > dependency chain scoped as "test", while you can tell surefire to activate > another profile during test. > TestCompile = JPA API > TestRuntime = Hibernate | EclipseLink > Example: > https://gist.github.com/1155271 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-759) In project with Unit tests (surefire) and integration tests (failsafe) would like ability to run single test of either variety
[ https://jira.codehaus.org/browse/SUREFIRE-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-759: - Assignee: Tibor Digana > In project with Unit tests (surefire) and integration tests (failsafe) would > like ability to run single test of either variety > -- > > Key: SUREFIRE-759 > URL: https://jira.codehaus.org/browse/SUREFIRE-759 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Affects Versions: 2.9 >Reporter: Steve Cohen >Assignee: Tibor Digana > > In project with both plugins specified, would like a way to run a single > test, whether it's an integration test or a unit test. I find I can either > use -Dtest= and run one unit test and all integration tests or -Dit.test= and > run one integration test and all unit tests. Would be nice if this could be > integrated into a single plugin or at least have a unified syntax enabling > the running of one and only one test of either type. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-759) In project with Unit tests (surefire) and integration tests (failsafe) would like ability to run single test of either variety
[ https://jira.codehaus.org/browse/SUREFIRE-759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360604#comment-360604 ] Tibor Digana commented on SUREFIRE-759: --- These are two plugins triggered in different lifecycle phase. Any objections to close this? > In project with Unit tests (surefire) and integration tests (failsafe) would > like ability to run single test of either variety > -- > > Key: SUREFIRE-759 > URL: https://jira.codehaus.org/browse/SUREFIRE-759 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Affects Versions: 2.9 >Reporter: Steve Cohen > > In project with both plugins specified, would like a way to run a single > test, whether it's an integration test or a unit test. I find I can either > use -Dtest= and run one unit test and all integration tests or -Dit.test= and > run one integration test and all unit tests. Would be nice if this could be > integrated into a single plugin or at least have a unified syntax enabling > the running of one and only one test of either type. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-646) Overlapping -D's for surefire and failsafe make it hard to control combination
[ https://jira.codehaus.org/browse/SUREFIRE-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-646. - Resolution: Duplicate We will fix properties in 3.0. The property -DskipTests will become -Dsurefire.skipTests and -Dfailsafe.skipTests. > Overlapping -D's for surefire and failsafe make it hard to control combination > -- > > Key: SUREFIRE-646 > URL: https://jira.codehaus.org/browse/SUREFIRE-646 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Affects Versions: 2.6 >Reporter: Benson Margulies > > I have a project with both surefire unit tests and failsafe integration > tests. This works until I try to start controlling things from command line. > 1. Both plugins respect -DskipTests. failsafe has skipITs, but surefire does > not seem to have a corresponding property that just skips the unit tests, not > the integration tests. > 2. When I use -Dtest= and specify an integration test, SUREFIRE runs it > before failsafe gets a chance, and of course it fails because the > pre-integration-test phase hasn't set up. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAR-192) Sporadic NPE in maven-jar-plugin:2.5:jar
[
https://jira.codehaus.org/browse/MJAR-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MJAR-192:
Labels: close-pending (was: )
> Sporadic NPE in maven-jar-plugin:2.5:jar
>
>
> Key: MJAR-192
> URL: https://jira.codehaus.org/browse/MJAR-192
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.5
> Environment: win 2008 server x64 java 8u25 maven 3.2.5
>Reporter: Alexander Ashitkin
> Labels: close-pending
>
> Strange npe at jar goal:
> {code}
> 16:41:50 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-jar-plugin:2.5:jar (default-jar) on project
> my-model: Error assembling JAR: NullPointerException -> [Help 1]
> 16:41:50 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-jar-plugin:2.5:jar (default-jar)
> on project my-model: Error assembling JAR
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:188)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:184)
> 16:41:50 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 16:41:50 at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 16:41:50 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 16:41:50 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 16:41:50 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 16:41:50 at java.lang.Thread.run(Thread.java:745)
> 16:41:50 Caused by: org.apache.maven.plugin.MojoExecutionException: Error
> assembling JAR
> 16:41:50 at
> org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:233)
> 16:41:50 at
> org.apache.maven.plugin.jar.AbstractJarMojo.execute(AbstractJarMojo.java:251)
> 16:41:50 at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 16:41:50 ... 11 more
> 16:41:50 Caused by: java.lang.NullPointerException
> 16:41:50 at
> org.apache.maven.project.MavenProject.getArtifacts(MavenProject.java:715)
> 16:41:50 at
> org.apache.maven.project.MavenProject.deepCopy(MavenProject.java:1218)
> 16:41:50 at
> org.apache.maven.project.MavenProject.(MavenProject.java:197)
> 16:41:50 at
> org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:501)
> 16:41:50 at
> org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:226)
> 16:41:50 ... 14 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-762) Add support for test compile and test runtime separation
[ https://jira.codehaus.org/browse/SUREFIRE-762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360606#comment-360606 ] Aslak Knutsen commented on SUREFIRE-762: Yes, this is still relevant. Different dependencies in a profile serves a different purpose and require re-execution of the maven process. Allowing Surefire to resolve multiple classpaths in different surefire executions opens for the option to test multiple different API implementations in one Maven execution. Currently to test multiple different classpaths resolved in one maven execution you would need to use multiple modules, e.g. core, core-test-junit4, core-test-junit4.2, core-test-junit4.3 etc...When all you really need is to swap the junit version and run all tests multiple times. This patch/issue opens up for a test-runtime 'scope' per surefire execution, a scope that is currently missing in Maven. > Add support for test compile and test runtime separation > > > Key: SUREFIRE-762 > URL: https://jira.codehaus.org/browse/SUREFIRE-762 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Surefire Plugin >Affects Versions: 2.9 >Reporter: Aslak Knutsen >Assignee: Tibor Digana > Attachments: SUREFIRE-762 > > > In some cases it is interesting to bind surefire to multiple execution > targets but have it operate on different classpaths. > e.g: > - Have the same test suite run against multiple JPA providers; EclipseLink > and Hibernate > - Arquillian test suite run against Tomcat and Jetty > In these cases you would have the TestCompile scope defined in your normal > dependency chain scoped as "test", while you can tell surefire to activate > another profile during test. > TestCompile = JPA API > TestRuntime = Hibernate | EclipseLink > Example: > https://gist.github.com/1155271 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-247) "Comparison method violates its general contract!" while generating site
[
https://jira.codehaus.org/browse/MPIR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360607#comment-360607
]
Herve Boutemy commented on MPIR-247:
that's the code I expected
I only wonder if we should only write a warning instead of failing the build:
that report isn't that important that it requires a Maven update
notice I had a new look at creating an IT: found the artifact in central that
Milos used to give us an example: {{org.mortbay.jetty:jetty-util}}
http://repo.maven.apache.org/maven2/org/mortbay/jetty/jetty-util/ , with the
6.1H.5-beta, 6.0.1 and 6.1.0rc3 versions given in MNG-5568
I tried once again to do an IT, but couldn't manage to do it: even when I
manage to have problematic versions in the range, it doesn't cause any failure
since the retrieved list is already sorted
I'll attach the current IT I managed to do...
this work made me wonder why we were sorting the list: we don't really need to!
then I propose following change:
{code:java}// select latest, assuming pom information will be
the most accurate
if ( versions.size() > 0 )
{
// list is already sorted: no need to sort it once again
(and cause MPIR-247)
// Collections.sort( versions );
// and if not perfectly sorted, not a big issue: version
just used to get license info and url
// of the artifact
artifact.setVersion( versions.get( versions.size() - 1
).toString() );
log.debug( "DependencyManagement resolved: " +
artifact.getId() );
}{code}
it seems the most simple fix: no need to sort
> "Comparison method violates its general contract!" while generating site
>
>
> Key: MPIR-247
> URL: https://jira.codehaus.org/browse/MPIR-247
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.4
> Environment: java version "1.7.0_04"
> Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
> maven 3.0.4
>Reporter: Mirek Hankus
>Assignee: Michael Osipov
> Fix For: 2.8
>
>
> While generating site, I'm getting exception as follows.
> {code}
> message : Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on project
> netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> cause : Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> Stack trace :
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on
> project netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at
> org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
> at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
> at hudson.maven.Maven3Bui
[jira] (MPIR-247) "Comparison method violates its general contract!" while generating site
[
https://jira.codehaus.org/browse/MPIR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MPIR-247:
---
Attachment: MPIR-247.zip
here is the IT I prepared: I had to add a repo since metadata in central don't
contain every versions available
it seems central publication got hit by the sorting bug :)
> "Comparison method violates its general contract!" while generating site
>
>
> Key: MPIR-247
> URL: https://jira.codehaus.org/browse/MPIR-247
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.4
> Environment: java version "1.7.0_04"
> Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
> maven 3.0.4
>Reporter: Mirek Hankus
>Assignee: Michael Osipov
> Fix For: 2.8
>
> Attachments: MPIR-247.zip
>
>
> While generating site, I'm getting exception as follows.
> {code}
> message : Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on project
> netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> cause : Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> Stack trace :
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on
> project netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at
> org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
> at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Request.java:326)
> at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.1:site
> failed: Comparison method violates its general contract!
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 27 more
> Caused by: java.lang.IllegalArgumentException: Comparison method violates its
> general contract!
> at java.util.ComparableTimSort.mergeHi(ComparableTimSort.java:835)
> at java.util.ComparableTimSort.mer
[jira] (MPIR-327) Changes in r1643577 have removed Site Plugin version requirement
[
https://jira.codehaus.org/browse/MPIR-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360609#comment-360609
]
Herve Boutemy commented on MPIR-327:
ok, wrong report :)
+1 to close the issue as "won't fix"
thank you for reporting an inadvertant change, since I really overlooked it
> Changes in r1643577 have removed Site Plugin version requirement
>
>
> Key: MPIR-327
> URL: https://jira.codehaus.org/browse/MPIR-327
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 2.8
>
>
> Revision [1643577|http://svn.apache.org/r1643577] claims to remove
> configuration already inherited from the parent but the parent does not
> contain Site Plugin version requirement.
> {code}
>
>
>
> org.apache.maven.plugins
> maven-plugin-plugin
>
>
> 1.5
>
>
> Maven Site Plugin
> 3.0
>
>
>
>
>
>
>
> {code}
> That information needs to be restored.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-327) Changes in r1643577 have removed Site Plugin version requirement
[
https://jira.codehaus.org/browse/MPIR-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MPIR-327:
Fix Version/s: (was: 2.8)
> Changes in r1643577 have removed Site Plugin version requirement
>
>
> Key: MPIR-327
> URL: https://jira.codehaus.org/browse/MPIR-327
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>
> Revision [1643577|http://svn.apache.org/r1643577] claims to remove
> configuration already inherited from the parent but the parent does not
> contain Site Plugin version requirement.
> {code}
>
>
>
> org.apache.maven.plugins
> maven-plugin-plugin
>
>
> 1.5
>
>
> Maven Site Plugin
> 3.0
>
>
>
>
>
>
>
> {code}
> That information needs to be restored.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-327) Changes in r1643577 have removed Site Plugin version requirement
[
https://jira.codehaus.org/browse/MPIR-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPIR-327.
---
Resolution: Not A Bug
Closing as per discussion: neither can a Site Plugin version be enforced nor do
the reports explicitly require the Site Plugin.
> Changes in r1643577 have removed Site Plugin version requirement
>
>
> Key: MPIR-327
> URL: https://jira.codehaus.org/browse/MPIR-327
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>
> Revision [1643577|http://svn.apache.org/r1643577] claims to remove
> configuration already inherited from the parent but the parent does not
> contain Site Plugin version requirement.
> {code}
>
>
>
> org.apache.maven.plugins
> maven-plugin-plugin
>
>
> 1.5
>
>
> Maven Site Plugin
> 3.0
>
>
>
>
>
>
>
> {code}
> That information needs to be restored.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-762) Add support for test compile and test runtime separation
[ https://jira.codehaus.org/browse/SUREFIRE-762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360611#comment-360611 ] Tibor Digana commented on SUREFIRE-762: --- These params did not help? dependenciesToScan classpathDependencyExcludes If still not satisfied, then I would assign this issue to 3.0. > Add support for test compile and test runtime separation > > > Key: SUREFIRE-762 > URL: https://jira.codehaus.org/browse/SUREFIRE-762 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Surefire Plugin >Affects Versions: 2.9 >Reporter: Aslak Knutsen >Assignee: Tibor Digana > Attachments: SUREFIRE-762 > > > In some cases it is interesting to bind surefire to multiple execution > targets but have it operate on different classpaths. > e.g: > - Have the same test suite run against multiple JPA providers; EclipseLink > and Hibernate > - Arquillian test suite run against Tomcat and Jetty > In these cases you would have the TestCompile scope defined in your normal > dependency chain scoped as "test", while you can tell surefire to activate > another profile during test. > TestCompile = JPA API > TestRuntime = Hibernate | EclipseLink > Example: > https://gist.github.com/1155271 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-764) java.io.tmpdir from MAVEN_OPTS should be inherited when forking
[ https://jira.codehaus.org/browse/SUREFIRE-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360612#comment-360612 ] Tibor Digana commented on SUREFIRE-764: --- @Anders I guess this won't be possible in 2.x. You can use argLine, however there's no connection in argLine syntax to link MAVEN_OPTS with argLine. We don't want to add new configuration parameter right before the EO surefire 2.x. I guess in surefire 3.0 you should have a chance to do this via SPI or so, without asking us to do it. Do you agree with me to assign this issue to 3.0? > java.io.tmpdir from MAVEN_OPTS should be inherited when forking > --- > > Key: SUREFIRE-764 > URL: https://jira.codehaus.org/browse/SUREFIRE-764 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin, process > forking >Affects Versions: 2.9 > Environment: n/a >Reporter: Anders Hammar > > For Maven 3 freestyle jobs in Hudson you can select "Private temporary > directory". This will set "MAVEN_OPTS=-Djava.io.tmpdir=..." for the Maven > execution. > However, surefire/failsafe plugin forks by default and the forked process > will then not be using this temp directory as the new JVM settings are not > inherited from MAVEN_OPTS. > I'm suggesting that java.io.tmpdir should be inherited from MAVEN_OPTS, if > specified. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-764) java.io.tmpdir from MAVEN_OPTS should be inherited when forking
[
https://jira.codehaus.org/browse/SUREFIRE-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360612#comment-360612
]
Tibor Digana edited comment on SUREFIRE-764 at 1/4/15 9:12 AM:
---
@Anders
I guess this won't be possible in 2.x. You can use argLine=${env.MAVEN_OPTS}.
We don't want to add new configuration parameter right before the EO surefire
2.x.
I guess in surefire 3.0 you should have a chance to hack via SPI, Java 8 extra
module, maybe Bash Shell if JavaScript or so, without asking us to do it.
Do you agree with me to assign this issue to 3.0?
was (Author: tibor17):
@Anders
I guess this won't be possible in 2.x. You can use argLine, however there's no
connection in argLine syntax to link MAVEN_OPTS with argLine.
We don't want to add new configuration parameter right before the EO surefire
2.x.
I guess in surefire 3.0 you should have a chance to do this via SPI or so,
without asking us to do it.
Do you agree with me to assign this issue to 3.0?
> java.io.tmpdir from MAVEN_OPTS should be inherited when forking
> ---
>
> Key: SUREFIRE-764
> URL: https://jira.codehaus.org/browse/SUREFIRE-764
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Affects Versions: 2.9
> Environment: n/a
>Reporter: Anders Hammar
>
> For Maven 3 freestyle jobs in Hudson you can select "Private temporary
> directory". This will set "MAVEN_OPTS=-Djava.io.tmpdir=..." for the Maven
> execution.
> However, surefire/failsafe plugin forks by default and the forked process
> will then not be using this temp directory as the new JVM settings are not
> inherited from MAVEN_OPTS.
> I'm suggesting that java.io.tmpdir should be inherited from MAVEN_OPTS, if
> specified.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-764) java.io.tmpdir from MAVEN_OPTS should be inherited when forking
[
https://jira.codehaus.org/browse/SUREFIRE-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360612#comment-360612
]
Tibor Digana edited comment on SUREFIRE-764 at 1/4/15 9:13 AM:
---
@Anders
I guess this won't be possible in 2.x.
You can use
{code}
${env.MAVEN_OPTS}
{code}
We don't want to add new configuration parameter right before the EO surefire
2.x.
I guess in surefire 3.0 you should have a chance to hack surefire and failsafe
via SPI, Java 8 extra module, maybe Bash Shell if JavaScript or so, without
asking us to do it.
Do you agree with me to assign this issue to 3.0?
was (Author: tibor17):
@Anders
I guess this won't be possible in 2.x.
You can use
{code}
${env.MAVEN_OPTS}
{code}
We don't want to add new configuration parameter right before the EO surefire
2.x.
I guess in surefire 3.0 you should have a chance to hack via SPI, Java 8 extra
module, maybe Bash Shell if JavaScript or so, without asking us to do it.
Do you agree with me to assign this issue to 3.0?
> java.io.tmpdir from MAVEN_OPTS should be inherited when forking
> ---
>
> Key: SUREFIRE-764
> URL: https://jira.codehaus.org/browse/SUREFIRE-764
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Affects Versions: 2.9
> Environment: n/a
>Reporter: Anders Hammar
>
> For Maven 3 freestyle jobs in Hudson you can select "Private temporary
> directory". This will set "MAVEN_OPTS=-Djava.io.tmpdir=..." for the Maven
> execution.
> However, surefire/failsafe plugin forks by default and the forked process
> will then not be using this temp directory as the new JVM settings are not
> inherited from MAVEN_OPTS.
> I'm suggesting that java.io.tmpdir should be inherited from MAVEN_OPTS, if
> specified.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-764) java.io.tmpdir from MAVEN_OPTS should be inherited when forking
[
https://jira.codehaus.org/browse/SUREFIRE-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360612#comment-360612
]
Tibor Digana edited comment on SUREFIRE-764 at 1/4/15 9:13 AM:
---
@Anders
I guess this won't be possible in 2.x.
You can use
{code}
${env.MAVEN_OPTS}
{code}
We don't want to add new configuration parameter right before the EO surefire
2.x.
I guess in surefire 3.0 you should have a chance to hack via SPI, Java 8 extra
module, maybe Bash Shell if JavaScript or so, without asking us to do it.
Do you agree with me to assign this issue to 3.0?
was (Author: tibor17):
@Anders
I guess this won't be possible in 2.x. You can use argLine=${env.MAVEN_OPTS}.
We don't want to add new configuration parameter right before the EO surefire
2.x.
I guess in surefire 3.0 you should have a chance to hack via SPI, Java 8 extra
module, maybe Bash Shell if JavaScript or so, without asking us to do it.
Do you agree with me to assign this issue to 3.0?
> java.io.tmpdir from MAVEN_OPTS should be inherited when forking
> ---
>
> Key: SUREFIRE-764
> URL: https://jira.codehaus.org/browse/SUREFIRE-764
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Affects Versions: 2.9
> Environment: n/a
>Reporter: Anders Hammar
>
> For Maven 3 freestyle jobs in Hudson you can select "Private temporary
> directory". This will set "MAVEN_OPTS=-Djava.io.tmpdir=..." for the Maven
> execution.
> However, surefire/failsafe plugin forks by default and the forked process
> will then not be using this temp directory as the new JVM settings are not
> inherited from MAVEN_OPTS.
> I'm suggesting that java.io.tmpdir should be inherited from MAVEN_OPTS, if
> specified.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-764) java.io.tmpdir from MAVEN_OPTS should be inherited when forking
[
https://jira.codehaus.org/browse/SUREFIRE-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360612#comment-360612
]
Tibor Digana edited comment on SUREFIRE-764 at 1/4/15 9:14 AM:
---
@Anders
I guess this won't be possible in 2.x.
You can use
{code}
${env.MAVEN_OPTS}
{code}
We don't want to add new configuration parameter right before the EO surefire
2.x.
I guess in surefire 3.0 you should have a chance to hack surefire and failsafe
via SPI, Java 8 extra module, maybe Bash Shell, JavaScript or so, without
asking us to do it.
Do you agree with me to assign this issue to 3.0?
was (Author: tibor17):
@Anders
I guess this won't be possible in 2.x.
You can use
{code}
${env.MAVEN_OPTS}
{code}
We don't want to add new configuration parameter right before the EO surefire
2.x.
I guess in surefire 3.0 you should have a chance to hack surefire and failsafe
via SPI, Java 8 extra module, maybe Bash Shell if JavaScript or so, without
asking us to do it.
Do you agree with me to assign this issue to 3.0?
> java.io.tmpdir from MAVEN_OPTS should be inherited when forking
> ---
>
> Key: SUREFIRE-764
> URL: https://jira.codehaus.org/browse/SUREFIRE-764
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Affects Versions: 2.9
> Environment: n/a
>Reporter: Anders Hammar
>
> For Maven 3 freestyle jobs in Hudson you can select "Private temporary
> directory". This will set "MAVEN_OPTS=-Djava.io.tmpdir=..." for the Maven
> execution.
> However, surefire/failsafe plugin forks by default and the forked process
> will then not be using this temp directory as the new JVM settings are not
> inherited from MAVEN_OPTS.
> I'm suggesting that java.io.tmpdir should be inherited from MAVEN_OPTS, if
> specified.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-247) "Comparison method violates its general contract!" while generating site
[
https://jira.codehaus.org/browse/MPIR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360614#comment-360614
]
Michael Osipov commented on MPIR-247:
-
The metadata file is far from being complete. Are you sure that it is already
sorted? I presumed the file contains versions as they are added. Not
necessarily sorted. E.g., 6.1.2, 6.2, 6.1.3, 6.2.1. Can this happen? Have a
[look|http://repo.maven.apache.org/maven2/net/fckeditor/java-core/maven-metadata.xml]
at this example.
If this is negligible, I would throw away my branch and take your fix or turn
my exception into a {{log.error}}.
> "Comparison method violates its general contract!" while generating site
>
>
> Key: MPIR-247
> URL: https://jira.codehaus.org/browse/MPIR-247
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.4
> Environment: java version "1.7.0_04"
> Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
> maven 3.0.4
>Reporter: Mirek Hankus
>Assignee: Michael Osipov
> Fix For: 2.8
>
> Attachments: MPIR-247.zip
>
>
> While generating site, I'm getting exception as follows.
> {code}
> message : Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on project
> netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> cause : Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> Stack trace :
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on
> project netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at
> org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
> at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Request.java:326)
> at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.1:site
> failed: Comparison method violates its general contract!
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lif
[jira] (SUREFIRE-764) java.io.tmpdir from MAVEN_OPTS should be inherited when forking
[ https://jira.codehaus.org/browse/SUREFIRE-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360613#comment-360613 ] Anders Hammar commented on SUREFIRE-764: Sure, that's ok. > java.io.tmpdir from MAVEN_OPTS should be inherited when forking > --- > > Key: SUREFIRE-764 > URL: https://jira.codehaus.org/browse/SUREFIRE-764 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin, process > forking >Affects Versions: 2.9 > Environment: n/a >Reporter: Anders Hammar > > For Maven 3 freestyle jobs in Hudson you can select "Private temporary > directory". This will set "MAVEN_OPTS=-Djava.io.tmpdir=..." for the Maven > execution. > However, surefire/failsafe plugin forks by default and the forked process > will then not be using this temp directory as the new JVM settings are not > inherited from MAVEN_OPTS. > I'm suggesting that java.io.tmpdir should be inherited from MAVEN_OPTS, if > specified. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-247) "Comparison method violates its general contract!" while generating site
[
https://jira.codehaus.org/browse/MPIR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360614#comment-360614
]
Michael Osipov edited comment on MPIR-247 at 1/4/15 9:17 AM:
-
The metadata file is far from being complete. Are you sure that it is already
sorted? I presumed the file contains versions as they are added. Not
necessarily sorted. E.g., 6.1.2, 6.2, 6.1.3, 6.2.1. Can this happen? Have a
look at
[this|http://repo.maven.apache.org/maven2/net/fckeditor/java-core/maven-metadata.xml]
example.
If this is negligible, I would throw away my branch and take your fix or turn
my exception into a {{log.error}}.
was (Author: michael-o):
The metadata file is far from being complete. Are you sure that it is already
sorted? I presumed the file contains versions as they are added. Not
necessarily sorted. E.g., 6.1.2, 6.2, 6.1.3, 6.2.1. Can this happen? Have a
[look|http://repo.maven.apache.org/maven2/net/fckeditor/java-core/maven-metadata.xml]
at this example.
If this is negligible, I would throw away my branch and take your fix or turn
my exception into a {{log.error}}.
> "Comparison method violates its general contract!" while generating site
>
>
> Key: MPIR-247
> URL: https://jira.codehaus.org/browse/MPIR-247
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.4
> Environment: java version "1.7.0_04"
> Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
> maven 3.0.4
>Reporter: Mirek Hankus
>Assignee: Michael Osipov
> Fix For: 2.8
>
> Attachments: MPIR-247.zip
>
>
> While generating site, I'm getting exception as follows.
> {code}
> message : Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on project
> netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> cause : Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> Stack trace :
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on
> project netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at
> org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
> at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Request.java:326)
> at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadP
[jira] (SUREFIRE-764) java.io.tmpdir from MAVEN_OPTS should be inherited when forking
[
https://jira.codehaus.org/browse/SUREFIRE-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360615#comment-360615
]
Tibor Digana commented on SUREFIRE-764:
---
In my imagination the user of surefire 3.0 should be able to do this:
{code}
function onMojoParameter(mavenSession, mavenProject, property) {
var val = property.name == "argLine" : property.value + "-Djava.io.tmpdir=/tmp"
property.value;
return {name: property.name, value: val, default: property.default};
}
{code}
> java.io.tmpdir from MAVEN_OPTS should be inherited when forking
> ---
>
> Key: SUREFIRE-764
> URL: https://jira.codehaus.org/browse/SUREFIRE-764
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Affects Versions: 2.9
> Environment: n/a
>Reporter: Anders Hammar
>
> For Maven 3 freestyle jobs in Hudson you can select "Private temporary
> directory". This will set "MAVEN_OPTS=-Djava.io.tmpdir=..." for the Maven
> execution.
> However, surefire/failsafe plugin forks by default and the forked process
> will then not be using this temp directory as the new JVM settings are not
> inherited from MAVEN_OPTS.
> I'm suggesting that java.io.tmpdir should be inherited from MAVEN_OPTS, if
> specified.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-764) java.io.tmpdir from MAVEN_OPTS should be inherited when forking
[
https://jira.codehaus.org/browse/SUREFIRE-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360615#comment-360615
]
Tibor Digana edited comment on SUREFIRE-764 at 1/4/15 9:25 AM:
---
In my imagination the user of surefire 3.0 should be able to do this:
{code}
function onMojoParameter(mavenSession, mavenProject, property) {
var val = property.name == "argLine" ? property.value + "-Djava.io.tmpdir=/tmp"
: property.value;
return {name: property.name, value: val, default: property.default};
}
{code}
was (Author: tibor17):
In my imagination the user of surefire 3.0 should be able to do this:
{code}
function onMojoParameter(mavenSession, mavenProject, property) {
var val = property.name == "argLine" : property.value + "-Djava.io.tmpdir=/tmp"
property.value;
return {name: property.name, value: val, default: property.default};
}
{code}
> java.io.tmpdir from MAVEN_OPTS should be inherited when forking
> ---
>
> Key: SUREFIRE-764
> URL: https://jira.codehaus.org/browse/SUREFIRE-764
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Affects Versions: 2.9
> Environment: n/a
>Reporter: Anders Hammar
>
> For Maven 3 freestyle jobs in Hudson you can select "Private temporary
> directory". This will set "MAVEN_OPTS=-Djava.io.tmpdir=..." for the Maven
> execution.
> However, surefire/failsafe plugin forks by default and the forked process
> will then not be using this temp directory as the new JVM settings are not
> inherited from MAVEN_OPTS.
> I'm suggesting that java.io.tmpdir should be inherited from MAVEN_OPTS, if
> specified.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-764) java.io.tmpdir from MAVEN_OPTS should be inherited when forking
[
https://jira.codehaus.org/browse/SUREFIRE-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360615#comment-360615
]
Tibor Digana edited comment on SUREFIRE-764 at 1/4/15 9:25 AM:
---
In my imagination the user of surefire 3.0 should be able do this:
{code}
function onMojoParameter(mavenSession, mavenProject, property) {
var val = property.name == "argLine" ? property.value + "-Djava.io.tmpdir=/tmp"
: property.value;
return {name: property.name, value: val, default: property.default};
}
{code}
was (Author: tibor17):
In my imagination the user of surefire 3.0 should be able to do this:
{code}
function onMojoParameter(mavenSession, mavenProject, property) {
var val = property.name == "argLine" ? property.value + "-Djava.io.tmpdir=/tmp"
: property.value;
return {name: property.name, value: val, default: property.default};
}
{code}
> java.io.tmpdir from MAVEN_OPTS should be inherited when forking
> ---
>
> Key: SUREFIRE-764
> URL: https://jira.codehaus.org/browse/SUREFIRE-764
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Affects Versions: 2.9
> Environment: n/a
>Reporter: Anders Hammar
>
> For Maven 3 freestyle jobs in Hudson you can select "Private temporary
> directory". This will set "MAVEN_OPTS=-Djava.io.tmpdir=..." for the Maven
> execution.
> However, surefire/failsafe plugin forks by default and the forked process
> will then not be using this temp directory as the new JVM settings are not
> inherited from MAVEN_OPTS.
> I'm suggesting that java.io.tmpdir should be inherited from MAVEN_OPTS, if
> specified.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-764) java.io.tmpdir from MAVEN_OPTS should be inherited when forking
[
https://jira.codehaus.org/browse/SUREFIRE-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360615#comment-360615
]
Tibor Digana edited comment on SUREFIRE-764 at 1/4/15 9:26 AM:
---
In my imagination the user of surefire 3.0 should be able do this:
{code}
function onMojoParameter(mavenSession, mavenProject, property) {
var val = property.name == "argLine" ? property.value + "
-Djava.io.tmpdir=/tmp" : property.value;
return {name: property.name, value: val, default: property.default};
}
{code}
was (Author: tibor17):
In my imagination the user of surefire 3.0 should be able do this:
{code}
function onMojoParameter(mavenSession, mavenProject, property) {
var val = property.name == "argLine" ? property.value + "-Djava.io.tmpdir=/tmp"
: property.value;
return {name: property.name, value: val, default: property.default};
}
{code}
> java.io.tmpdir from MAVEN_OPTS should be inherited when forking
> ---
>
> Key: SUREFIRE-764
> URL: https://jira.codehaus.org/browse/SUREFIRE-764
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Affects Versions: 2.9
> Environment: n/a
>Reporter: Anders Hammar
>
> For Maven 3 freestyle jobs in Hudson you can select "Private temporary
> directory". This will set "MAVEN_OPTS=-Djava.io.tmpdir=..." for the Maven
> execution.
> However, surefire/failsafe plugin forks by default and the forked process
> will then not be using this temp directory as the new JVM settings are not
> inherited from MAVEN_OPTS.
> I'm suggesting that java.io.tmpdir should be inherited from MAVEN_OPTS, if
> specified.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-764) java.io.tmpdir from MAVEN_OPTS should be inherited when forking
[ https://jira.codehaus.org/browse/SUREFIRE-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-764: -- Fix Version/s: 3.0 > java.io.tmpdir from MAVEN_OPTS should be inherited when forking > --- > > Key: SUREFIRE-764 > URL: https://jira.codehaus.org/browse/SUREFIRE-764 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin, process > forking >Affects Versions: 2.9 > Environment: n/a >Reporter: Anders Hammar > Fix For: 3.0 > > > For Maven 3 freestyle jobs in Hudson you can select "Private temporary > directory". This will set "MAVEN_OPTS=-Djava.io.tmpdir=..." for the Maven > execution. > However, surefire/failsafe plugin forks by default and the forked process > will then not be using this temp directory as the new JVM settings are not > inherited from MAVEN_OPTS. > I'm suggesting that java.io.tmpdir should be inherited from MAVEN_OPTS, if > specified. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-762) Add support for test compile and test runtime separation
[ https://jira.codehaus.org/browse/SUREFIRE-762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360616#comment-360616 ] Aslak Knutsen commented on SUREFIRE-762: dependenciesToScan helps some, but different use case in my eyes. The intended use is to share a test suite between multiple implementors. For instance a TCK. As an example, a JPA TCK could provide a test artifact that the Hibernate team use dependenciesToScan in their test setup to include into their build. As a user, I'm not interested in the JPA TCK, I have my own tests I want to test against multiple implementations, Hibernate and EclipeLink (that's where this come in). Perhaps a good way to look at it would be; * I want my code to comply with a given test suite (dependenciesToScan) * I want my code to run on multiple implementations (additionalProfiles) I could create a common test suite in my project and create multiple test modules with individual dependency sets and import the test suite using dependenciesToScan, but that doesn't solve the multiple modules issue.. :) classpathDependencyExcludes works the opposite direction, you would have to include all test-runtime dependencies in test scope and exclude the ones you don't want in the surefire execution. e.g. runtime-a, runtime-b and runtime-c are test scoped, then in execution of runtime-a you need to exclude runtime-b and runtime-c. With only 3 dependencies that's not too hard, but confusing. Now if runtime-a has runtime-a-N dependencies in a group you're in trouble. Not to mention of course that when runtime-a|z are resolved on the same classpath maven will do dependency conflict resolution, meaning depending on just runtime-a might not resolve the same as depending on runtime-a and runtime-b at the same time. So in short, no :) > Add support for test compile and test runtime separation > > > Key: SUREFIRE-762 > URL: https://jira.codehaus.org/browse/SUREFIRE-762 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Surefire Plugin >Affects Versions: 2.9 >Reporter: Aslak Knutsen >Assignee: Tibor Digana > Attachments: SUREFIRE-762 > > > In some cases it is interesting to bind surefire to multiple execution > targets but have it operate on different classpaths. > e.g: > - Have the same test suite run against multiple JPA providers; EclipseLink > and Hibernate > - Arquillian test suite run against Tomcat and Jetty > In these cases you would have the TestCompile scope defined in your normal > dependency chain scoped as "test", while you can tell surefire to activate > another profile during test. > TestCompile = JPA API > TestRuntime = Hibernate | EclipseLink > Example: > https://gist.github.com/1155271 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-762) Add support for test compile and test runtime separation
[ https://jira.codehaus.org/browse/SUREFIRE-762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-762: -- Fix Version/s: 3.0 > Add support for test compile and test runtime separation > > > Key: SUREFIRE-762 > URL: https://jira.codehaus.org/browse/SUREFIRE-762 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Surefire Plugin >Affects Versions: 2.9 >Reporter: Aslak Knutsen >Assignee: Tibor Digana > Fix For: 3.0 > > Attachments: SUREFIRE-762 > > > In some cases it is interesting to bind surefire to multiple execution > targets but have it operate on different classpaths. > e.g: > - Have the same test suite run against multiple JPA providers; EclipseLink > and Hibernate > - Arquillian test suite run against Tomcat and Jetty > In these cases you would have the TestCompile scope defined in your normal > dependency chain scoped as "test", while you can tell surefire to activate > another profile during test. > TestCompile = JPA API > TestRuntime = Hibernate | EclipseLink > Example: > https://gist.github.com/1155271 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-762) Add support for test compile and test runtime separation
[ https://jira.codehaus.org/browse/SUREFIRE-762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360617#comment-360617 ] Tibor Digana commented on SUREFIRE-762: --- Assigned to 3.0. The user should be able to customize the classpath upon the project profile or plugin execution. > Add support for test compile and test runtime separation > > > Key: SUREFIRE-762 > URL: https://jira.codehaus.org/browse/SUREFIRE-762 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Surefire Plugin >Affects Versions: 2.9 >Reporter: Aslak Knutsen >Assignee: Tibor Digana > Fix For: 3.0 > > Attachments: SUREFIRE-762 > > > In some cases it is interesting to bind surefire to multiple execution > targets but have it operate on different classpaths. > e.g: > - Have the same test suite run against multiple JPA providers; EclipseLink > and Hibernate > - Arquillian test suite run against Tomcat and Jetty > In these cases you would have the TestCompile scope defined in your normal > dependency chain scoped as "test", while you can tell surefire to activate > another profile during test. > TestCompile = JPA API > TestRuntime = Hibernate | EclipseLink > Example: > https://gist.github.com/1155271 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-977) Failsafe ignores reportsDirectory property for failsafe-summary.xml
[
https://jira.codehaus.org/browse/SUREFIRE-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-977.
-
Resolution: Not A Bug
Once you specify reportsDirectory and you expect failsafe-summary.xml in the
same folder, you have to specify summaryFile as well.
We must not make any guess about summaryFile and break the configuratio, see
the param definition:
@Parameter( defaultValue =
"${project.build.directory}/failsafe-reports/failsafe-summary.xml", required =
true )
private File summaryFile;
> Failsafe ignores reportsDirectory property for failsafe-summary.xml
> ---
>
> Key: SUREFIRE-977
> URL: https://jira.codehaus.org/browse/SUREFIRE-977
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.14
>Reporter: Marcin Zajaczkowski
>Priority: Trivial
>
> Failsafe seems to ignore reportsDirectory property for failsafe-summary.xml
> and always put it in $\{project.build.directory}/failsafe-reports. It would
> be more consistent to keep it with other files.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-247) "Comparison method violates its general contract!" while generating site
[
https://jira.codehaus.org/browse/MPIR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360619#comment-360619
]
Herve Boutemy commented on MPIR-247:
in fact, order during execution is not strictly order of the repository, but as
done by Maven core, while merging multiple repos, for example
but even with that, I'm not not sure the API enforces order.
Since we only want the latest, we could simple avoid Collections.sort and
simply iterate over the collection and compare to keep the max.
And while writing this, we should simply use Collections.max() instead of
Collections.sort(): here it is, I try this is the right answer, better than any
previous!
> "Comparison method violates its general contract!" while generating site
>
>
> Key: MPIR-247
> URL: https://jira.codehaus.org/browse/MPIR-247
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.4
> Environment: java version "1.7.0_04"
> Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
> maven 3.0.4
>Reporter: Mirek Hankus
>Assignee: Michael Osipov
> Fix For: 2.8
>
> Attachments: MPIR-247.zip
>
>
> While generating site, I'm getting exception as follows.
> {code}
> message : Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on project
> netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> cause : Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> Stack trace :
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on
> project netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at
> org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
> at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Request.java:326)
> at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.1:site
> failed: Comparison method violates its general contract!
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Defaul
[jira] (MPIR-247) "Comparison method violates its general contract!" while generating site
[
https://jira.codehaus.org/browse/MPIR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360620#comment-360620
]
Michael Osipov commented on MPIR-247:
-
Way better, yes. According to the docs, {{max()}} iterates over the collection
without sorting it. I will create another branch shortly.
> "Comparison method violates its general contract!" while generating site
>
>
> Key: MPIR-247
> URL: https://jira.codehaus.org/browse/MPIR-247
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.4
> Environment: java version "1.7.0_04"
> Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
> maven 3.0.4
>Reporter: Mirek Hankus
>Assignee: Michael Osipov
> Fix For: 2.8
>
> Attachments: MPIR-247.zip
>
>
> While generating site, I'm getting exception as follows.
> {code}
> message : Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on project
> netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> cause : Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> Stack trace :
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on
> project netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at
> org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
> at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Request.java:326)
> at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.1:site
> failed: Comparison method violates its general contract!
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 27 more
> Caused by: java.lang.IllegalArgumentException: Comparison method violates its
> general contract!
> at java.util.ComparableTimSort.mergeHi(ComparableTimSort.java:835)
> at java.util.ComparableTimSort.mergeAt(Comp
[jira] (MPIR-247) "Comparison method violates its general contract!" while generating site
[
https://jira.codehaus.org/browse/MPIR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPIR-247.
---
Resolution: Fixed
Fixed with [r1649372|http://svn.apache.org/r1649372]. Hervé, thank you very
much for your help!
> "Comparison method violates its general contract!" while generating site
>
>
> Key: MPIR-247
> URL: https://jira.codehaus.org/browse/MPIR-247
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.4
> Environment: java version "1.7.0_04"
> Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
> maven 3.0.4
>Reporter: Mirek Hankus
>Assignee: Michael Osipov
> Fix For: 2.8
>
> Attachments: MPIR-247.zip
>
>
> While generating site, I'm getting exception as follows.
> {code}
> message : Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on project
> netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> cause : Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> Stack trace :
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on
> project netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at
> org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
> at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Request.java:326)
> at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.1:site
> failed: Comparison method violates its general contract!
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 27 more
> Caused by: java.lang.IllegalArgumentException: Comparison method violates its
> general contract!
> at java.util.ComparableTimSort.mergeHi(ComparableTimSort.java:835)
> at java.util.ComparableTimSort.mergeAt(ComparableTimSort.java:453)
> at java.util.ComparableTimSort.mergeColl
[jira] (MPIR-247) "Comparison method violates its general contract!" while generating site
[
https://jira.codehaus.org/browse/MPIR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MPIR-247:
Comment: was deleted
(was: Fixed with [r1649372|http://svn.apache.org/r1649372]. Hervé, thank you
very much for your help!)
> "Comparison method violates its general contract!" while generating site
>
>
> Key: MPIR-247
> URL: https://jira.codehaus.org/browse/MPIR-247
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.4
> Environment: java version "1.7.0_04"
> Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
> maven 3.0.4
>Reporter: Mirek Hankus
>Assignee: Michael Osipov
> Fix For: 2.8
>
> Attachments: MPIR-247.zip
>
>
> While generating site, I'm getting exception as follows.
> {code}
> message : Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on project
> netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> cause : Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> Stack trace :
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on
> project netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at
> org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
> at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Request.java:326)
> at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.1:site
> failed: Comparison method violates its general contract!
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 27 more
> Caused by: java.lang.IllegalArgumentException: Comparison method violates its
> general contract!
> at java.util.ComparableTimSort.mergeHi(ComparableTimSort.java:835)
> at java.util.ComparableTimSort.mergeAt(ComparableTimSort.java:453)
> at java.util.ComparableTimSo
[jira] (MPIR-247) "Comparison method violates its general contract!" while generating site
[
https://jira.codehaus.org/browse/MPIR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360622#comment-360622
]
Michael Osipov commented on MPIR-247:
-
Fixed with [r1649372|http://svn.apache.org/r1649372]. Hervé, thank you very
much for your help!
> "Comparison method violates its general contract!" while generating site
>
>
> Key: MPIR-247
> URL: https://jira.codehaus.org/browse/MPIR-247
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.4
> Environment: java version "1.7.0_04"
> Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
> maven 3.0.4
>Reporter: Mirek Hankus
>Assignee: Michael Osipov
> Fix For: 2.8
>
> Attachments: MPIR-247.zip
>
>
> While generating site, I'm getting exception as follows.
> {code}
> message : Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on project
> netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> cause : Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> Stack trace :
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on
> project netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at
> org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
> at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Request.java:326)
> at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.1:site
> failed: Comparison method violates its general contract!
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 27 more
> Caused by: java.lang.IllegalArgumentException: Comparison method violates its
> general contract!
> at java.util.ComparableTimSort.mergeHi(ComparableTimSort.java:835)
> at java.util.ComparableTimSort.mergeAt(ComparableTimSort.java:453)
> at java.u
[jira] (MPIR-225) Change 'developer access', optionally, to show trunk for Subversion, not tag URL
[ https://jira.codehaus.org/browse/MPIR-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360623#comment-360623 ] Michael Osipov commented on MPIR-225: - Benson, why don't you apply the proposed solution by Olivier? That should solve the issue. > Change 'developer access', optionally, to show trunk for Subversion, not tag > URL > > > Key: MPIR-225 > URL: https://jira.codehaus.org/browse/MPIR-225 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement > Components: scm >Affects Versions: 2.4 >Reporter: Benson Margulies > Labels: close-pending > > When I go to look at the scm report for the SVN url, I am getting ready to > prepare to fix something. In that case, I essentially never want the tagged > version of the release. I want the 'corresponding development branch'. This > is not a concept currently modelled in maven at all. > At very least, I'd like to add a config property to this plugin that > specifies that URL, and then add it as an additional clause in the output. > Obviously, it's would be slicker in some respects to add another something to > the pom, but that's a much bigger deal (though there might be other uses for > it). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-282) Allow customisation via a parent POM
[
https://jira.codehaus.org/browse/MPIR-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MPIR-282:
Labels: close-pending (was: )
> Allow customisation via a parent POM
>
>
> Key: MPIR-282
> URL: https://jira.codehaus.org/browse/MPIR-282
> Project: Maven Project Info Reports Plugin
> Issue Type: Improvement
>Reporter: SebbASF
> Labels: close-pending
>
> Individual projects can easily customise the PIR report text by providing
> replacement properties in a custom bundle at
> ${project.basedir}/src/site/custom/project-info-report.properties
> It would be useful for projects which share a common parent pom (e.g. Apache
> Commons) to be able to share a custom bundle.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-225) Change 'developer access', optionally, to show trunk for Subversion, not tag URL
[ https://jira.codehaus.org/browse/MPIR-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MPIR-225: Labels: close-pending (was: ) > Change 'developer access', optionally, to show trunk for Subversion, not tag > URL > > > Key: MPIR-225 > URL: https://jira.codehaus.org/browse/MPIR-225 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement > Components: scm >Affects Versions: 2.4 >Reporter: Benson Margulies > Labels: close-pending > > When I go to look at the scm report for the SVN url, I am getting ready to > prepare to fix something. In that case, I essentially never want the tagged > version of the release. I want the 'corresponding development branch'. This > is not a concept currently modelled in maven at all. > At very least, I'd like to add a config property to this plugin that > specifies that URL, and then add it as an additional clause in the output. > Obviously, it's would be slicker in some respects to add another something to > the pom, but that's a much bigger deal (though there might be other uses for > it). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-282) Allow customisation via a parent POM
[
https://jira.codehaus.org/browse/MPIR-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360624#comment-360624
]
Michael Osipov commented on MPIR-282:
-
Please provide a patch!
> Allow customisation via a parent POM
>
>
> Key: MPIR-282
> URL: https://jira.codehaus.org/browse/MPIR-282
> Project: Maven Project Info Reports Plugin
> Issue Type: Improvement
>Reporter: SebbASF
> Labels: close-pending
>
> Individual projects can easily customise the PIR report text by providing
> replacement properties in a custom bundle at
> ${project.basedir}/src/site/custom/project-info-report.properties
> It would be useful for projects which share a common parent pom (e.g. Apache
> Commons) to be able to share a custom bundle.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-225) Change 'developer access', optionally, to show trunk for Subversion, not tag URL
[ https://jira.codehaus.org/browse/MPIR-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MPIR-225: Summary: Change 'developer access', optionally, to show trunk for Subversion, not tag URL (was: Change 'developer access', optionally, to show trunk, not tag URL) > Change 'developer access', optionally, to show trunk for Subversion, not tag > URL > > > Key: MPIR-225 > URL: https://jira.codehaus.org/browse/MPIR-225 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement > Components: scm >Affects Versions: 2.4 >Reporter: Benson Margulies > Labels: close-pending > > When I go to look at the scm report for the SVN url, I am getting ready to > prepare to fix something. In that case, I essentially never want the tagged > version of the release. I want the 'corresponding development branch'. This > is not a concept currently modelled in maven at all. > At very least, I'd like to add a config property to this plugin that > specifies that URL, and then add it as an additional clause in the output. > Obviously, it's would be slicker in some respects to add another something to > the pom, but that's a much bigger deal (though there might be other uses for > it). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-300) Reporting plugins are reported with wrong version if version specified via pluginManagement
[ https://jira.codehaus.org/browse/MPIR-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MPIR-300: Description: My pom.xml specifies all plugin versions including the ones for plugins used in the reporting section via pluginManagement. Accoring to http://maven.apache.org/plugins/maven-site-plugin/maven-3.html#Version_Resolution and the ticket 443 this is fully supported by the maven-site-plugin. Unfortunately the maven-project-info-report-plugin does not seem to adhere this version resolution which results in a wrong version in the report. The attached example gives a pom.xml, the log file when generating the site, and the resulting plugins.html. The version to look at is from the maven-surefire-report-plugin, which has 2.16 specified in the pluginManagement section (and this version is actually used for generating the surefire report) but the plugins.html report says 2.17 (the latest version). was: My pom.xml specifies all plugin versions including the ones for plugins used in the reporting section via pluginManagement. Accoring to http://maven.apache.org/plugins/maven-site-plugin/maven-3.html#Version_Resolution and the ticket https://jira.codehaus.org/browse/MSITE-443 this is fully supported by the maven-site-plugin. Unfortunately the maven-project-info-report-plugin does not seem to adhere this version resolution which results in a wrong version in the report. The attached example gives a pom.xml, the log file when generating the site, and the resulting plugins.html. The version to look at is from the maven-surefire-report-plugin, which has 2.16 specified in the pluginManagement section (and this version is actually used for generating the surefire report) but the plugins.html report says 2.17 (the latest version). > Reporting plugins are reported with wrong version if version specified via > pluginManagement > --- > > Key: MPIR-300 > URL: https://jira.codehaus.org/browse/MPIR-300 > Project: Maven Project Info Reports Plugin > Issue Type: Bug > Components: plugin-management >Affects Versions: 2.7 > Environment: Apache Maven 3.2.1 > (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T18:37:52+01:00) > Maven home: <...>/maven-3.2.1 > Java version: 1.7.0_07, vendor: Oracle Corporation > Default locale: de_DE, platform encoding: UTF-8 > OS name: "linux", version: "3.13.0-34-generic", arch: "amd64", family: "unix" >Reporter: Thomas Reitmayr > Attachments: mvn.log, plugins.html, pom.xml > > > My pom.xml specifies all plugin versions including the ones for plugins used > in the reporting section via pluginManagement. Accoring to > http://maven.apache.org/plugins/maven-site-plugin/maven-3.html#Version_Resolution > and the ticket 443 this is fully supported by the maven-site-plugin. > Unfortunately the maven-project-info-report-plugin does not seem to adhere > this version resolution which results in a wrong version in the report. > The attached example gives a pom.xml, the log file when generating the site, > and the resulting plugins.html. The version to look at is from the > maven-surefire-report-plugin, which has 2.16 specified in the > pluginManagement section (and this version is actually used for generating > the surefire report) but the plugins.html report says 2.17 (the latest > version). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-247) "Comparison method violates its general contract!" while generating site
[
https://jira.codehaus.org/browse/MPIR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360625#comment-360625
]
Herve Boutemy commented on MPIR-247:
thank you for your patience: it was long, but the discussion was useful since
we found an idea that has taken so long to come to mind...
> "Comparison method violates its general contract!" while generating site
>
>
> Key: MPIR-247
> URL: https://jira.codehaus.org/browse/MPIR-247
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.4
> Environment: java version "1.7.0_04"
> Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
> maven 3.0.4
>Reporter: Mirek Hankus
>Assignee: Michael Osipov
> Fix For: 2.8
>
> Attachments: MPIR-247.zip
>
>
> While generating site, I'm getting exception as follows.
> {code}
> message : Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on project
> netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> cause : Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> Stack trace :
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on
> project netpr-aggregator: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
> violates its general contract!
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at
> org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
> at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Request.java:326)
> at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.1:site
> failed: Comparison method violates its general contract!
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 27 more
> Caused by: java.lang.IllegalArgumentException: Comparison method violates its
> general contract!
> at java.util.ComparableTimSort.mergeHi(ComparableTimSort.java:835)
> at java.util.ComparableTimSort.mergeAt(Compar
[jira] (MJAR-192) Sporadic NPE in maven-jar-plugin:2.5:jar
[
https://jira.codehaus.org/browse/MJAR-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated MJAR-192:
Labels: (was: close-pending)
> Sporadic NPE in maven-jar-plugin:2.5:jar
>
>
> Key: MJAR-192
> URL: https://jira.codehaus.org/browse/MJAR-192
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.5
> Environment: win 2008 server x64 java 8u25 maven 3.2.5
>Reporter: Alexander Ashitkin
>
> Strange npe at jar goal:
> {code}
> 16:41:50 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-jar-plugin:2.5:jar (default-jar) on project
> my-model: Error assembling JAR: NullPointerException -> [Help 1]
> 16:41:50 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-jar-plugin:2.5:jar (default-jar)
> on project my-model: Error assembling JAR
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:188)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:184)
> 16:41:50 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 16:41:50 at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 16:41:50 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 16:41:50 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 16:41:50 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 16:41:50 at java.lang.Thread.run(Thread.java:745)
> 16:41:50 Caused by: org.apache.maven.plugin.MojoExecutionException: Error
> assembling JAR
> 16:41:50 at
> org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:233)
> 16:41:50 at
> org.apache.maven.plugin.jar.AbstractJarMojo.execute(AbstractJarMojo.java:251)
> 16:41:50 at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 16:41:50 ... 11 more
> 16:41:50 Caused by: java.lang.NullPointerException
> 16:41:50 at
> org.apache.maven.project.MavenProject.getArtifacts(MavenProject.java:715)
> 16:41:50 at
> org.apache.maven.project.MavenProject.deepCopy(MavenProject.java:1218)
> 16:41:50 at
> org.apache.maven.project.MavenProject.(MavenProject.java:197)
> 16:41:50 at
> org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:501)
> 16:41:50 at
> org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:226)
> 16:41:50 ... 14 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-300) Reporting plugins are reported with wrong version if version specified via pluginManagement
[ https://jira.codehaus.org/browse/MPIR-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MPIR-300: Description: My pom.xml specifies all plugin versions including the ones for plugins used in the reporting section via pluginManagement. Accoring to http://maven.apache.org/plugins/maven-site-plugin/maven-3.html#Version_Resolution and the ticket MSITE-443 this is fully supported by the maven-site-plugin. Unfortunately the maven-project-info-report-plugin does not seem to adhere this version resolution which results in a wrong version in the report. The attached example gives a pom.xml, the log file when generating the site, and the resulting plugins.html. The version to look at is from the maven-surefire-report-plugin, which has 2.16 specified in the pluginManagement section (and this version is actually used for generating the surefire report) but the plugins.html report says 2.17 (the latest version). was: My pom.xml specifies all plugin versions including the ones for plugins used in the reporting section via pluginManagement. Accoring to http://maven.apache.org/plugins/maven-site-plugin/maven-3.html#Version_Resolution and the ticket 443 this is fully supported by the maven-site-plugin. Unfortunately the maven-project-info-report-plugin does not seem to adhere this version resolution which results in a wrong version in the report. The attached example gives a pom.xml, the log file when generating the site, and the resulting plugins.html. The version to look at is from the maven-surefire-report-plugin, which has 2.16 specified in the pluginManagement section (and this version is actually used for generating the surefire report) but the plugins.html report says 2.17 (the latest version). > Reporting plugins are reported with wrong version if version specified via > pluginManagement > --- > > Key: MPIR-300 > URL: https://jira.codehaus.org/browse/MPIR-300 > Project: Maven Project Info Reports Plugin > Issue Type: Bug > Components: plugin-management >Affects Versions: 2.7 > Environment: Apache Maven 3.2.1 > (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T18:37:52+01:00) > Maven home: <...>/maven-3.2.1 > Java version: 1.7.0_07, vendor: Oracle Corporation > Default locale: de_DE, platform encoding: UTF-8 > OS name: "linux", version: "3.13.0-34-generic", arch: "amd64", family: "unix" >Reporter: Thomas Reitmayr > Attachments: mvn.log, plugins.html, pom.xml > > > My pom.xml specifies all plugin versions including the ones for plugins used > in the reporting section via pluginManagement. Accoring to > http://maven.apache.org/plugins/maven-site-plugin/maven-3.html#Version_Resolution > and the ticket MSITE-443 this is fully supported by the maven-site-plugin. > Unfortunately the maven-project-info-report-plugin does not seem to adhere > this version resolution which results in a wrong version in the report. > The attached example gives a pom.xml, the log file when generating the site, > and the resulting plugins.html. The version to look at is from the > maven-surefire-report-plugin, which has 2.16 specified in the > pluginManagement section (and this version is actually used for generating > the surefire report) but the plugins.html report says 2.17 (the latest > version). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-300) Reporting plugins are reported with wrong version if version specified via pluginManagement
[ https://jira.codehaus.org/browse/MPIR-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360626#comment-360626 ] Michael Osipov commented on MPIR-300: - I can confirm that this still holds true with the most recent plugins. The reason is that in contrast to MSITE-516, the models are not merged and you get the latest RELEASE version if you do not provide one. > Reporting plugins are reported with wrong version if version specified via > pluginManagement > --- > > Key: MPIR-300 > URL: https://jira.codehaus.org/browse/MPIR-300 > Project: Maven Project Info Reports Plugin > Issue Type: Bug > Components: plugin-management >Affects Versions: 2.7 > Environment: Apache Maven 3.2.1 > (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T18:37:52+01:00) > Maven home: <...>/maven-3.2.1 > Java version: 1.7.0_07, vendor: Oracle Corporation > Default locale: de_DE, platform encoding: UTF-8 > OS name: "linux", version: "3.13.0-34-generic", arch: "amd64", family: "unix" >Reporter: Thomas Reitmayr > Attachments: mvn.log, plugins.html, pom.xml > > > My pom.xml specifies all plugin versions including the ones for plugins used > in the reporting section via pluginManagement. Accoring to > http://maven.apache.org/plugins/maven-site-plugin/maven-3.html#Version_Resolution > and the ticket MSITE-443 this is fully supported by the maven-site-plugin. > Unfortunately the maven-project-info-report-plugin does not seem to adhere > this version resolution which results in a wrong version in the report. > The attached example gives a pom.xml, the log file when generating the site, > and the resulting plugins.html. The version to look at is from the > maven-surefire-report-plugin, which has 2.16 specified in the > pluginManagement section (and this version is actually used for generating > the surefire report) but the plugins.html report says 2.17 (the latest > version). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-302) Allow usage of supplemental-model in reports (e.g. dependencies)
[ https://jira.codehaus.org/browse/MPIR-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360627#comment-360627 ] Michael Osipov commented on MPIR-302: - Can you provide a sample project which depicts the problem? > Allow usage of supplemental-model in reports (e.g. dependencies) > > > Key: MPIR-302 > URL: https://jira.codehaus.org/browse/MPIR-302 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement > Components: dependencies, dependency-management >Affects Versions: 2.7 >Reporter: Grégory Joseph > > The remote-resources plugin allows creating and sharing "supplemental > models", i.e pom snippets that allow overriding (read "fixing") those from > the repository. We use this to fix licensing info of some libraries that are > on central with wrong or inaccurate poms. > See > http://maven.apache.org/plugins/maven-remote-resources-plugin/supplemental-models.html > It would be great if the dependencies reports (and others maybe ?) could make > use of the same information, such that those generated reports are consistent > with the resources generated by remote-resources plugin. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAR-192) Sporadic NPE in maven-jar-plugin:2.5:jar
[
https://jira.codehaus.org/browse/MJAR-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360628#comment-360628
]
Alexander Ashitkin commented on MJAR-192:
-
Feel free to close if not helpfull. Doesnt make sense to waste time on this
approach.
thanks in advance
> Sporadic NPE in maven-jar-plugin:2.5:jar
>
>
> Key: MJAR-192
> URL: https://jira.codehaus.org/browse/MJAR-192
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.5
> Environment: win 2008 server x64 java 8u25 maven 3.2.5
>Reporter: Alexander Ashitkin
>
> Strange npe at jar goal:
> {code}
> 16:41:50 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-jar-plugin:2.5:jar (default-jar) on project
> my-model: Error assembling JAR: NullPointerException -> [Help 1]
> 16:41:50 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-jar-plugin:2.5:jar (default-jar)
> on project my-model: Error assembling JAR
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:188)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:184)
> 16:41:50 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 16:41:50 at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 16:41:50 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 16:41:50 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 16:41:50 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 16:41:50 at java.lang.Thread.run(Thread.java:745)
> 16:41:50 Caused by: org.apache.maven.plugin.MojoExecutionException: Error
> assembling JAR
> 16:41:50 at
> org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:233)
> 16:41:50 at
> org.apache.maven.plugin.jar.AbstractJarMojo.execute(AbstractJarMojo.java:251)
> 16:41:50 at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 16:41:50 ... 11 more
> 16:41:50 Caused by: java.lang.NullPointerException
> 16:41:50 at
> org.apache.maven.project.MavenProject.getArtifacts(MavenProject.java:715)
> 16:41:50 at
> org.apache.maven.project.MavenProject.deepCopy(MavenProject.java:1218)
> 16:41:50 at
> org.apache.maven.project.MavenProject.(MavenProject.java:197)
> 16:41:50 at
> org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:501)
> 16:41:50 at
> org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:226)
> 16:41:50 ... 14 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAR-192) Sporadic NPE in maven-jar-plugin:2.5:jar
[
https://jira.codehaus.org/browse/MJAR-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360628#comment-360628
]
Alexander Ashitkin edited comment on MJAR-192 at 1/4/15 1:42 PM:
-
Feel free to close if not helpfull. Doesnt make sense to waste my time with
such approach.
thank you
was (Author: alex_ashitkin):
Feel free to close if not helpfull. Doesnt make sense to waste my time with
such approach.
thanks you
> Sporadic NPE in maven-jar-plugin:2.5:jar
>
>
> Key: MJAR-192
> URL: https://jira.codehaus.org/browse/MJAR-192
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.5
> Environment: win 2008 server x64 java 8u25 maven 3.2.5
>Reporter: Alexander Ashitkin
>
> Strange npe at jar goal:
> {code}
> 16:41:50 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-jar-plugin:2.5:jar (default-jar) on project
> my-model: Error assembling JAR: NullPointerException -> [Help 1]
> 16:41:50 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-jar-plugin:2.5:jar (default-jar)
> on project my-model: Error assembling JAR
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:188)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:184)
> 16:41:50 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 16:41:50 at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 16:41:50 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 16:41:50 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 16:41:50 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 16:41:50 at java.lang.Thread.run(Thread.java:745)
> 16:41:50 Caused by: org.apache.maven.plugin.MojoExecutionException: Error
> assembling JAR
> 16:41:50 at
> org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:233)
> 16:41:50 at
> org.apache.maven.plugin.jar.AbstractJarMojo.execute(AbstractJarMojo.java:251)
> 16:41:50 at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 16:41:50 ... 11 more
> 16:41:50 Caused by: java.lang.NullPointerException
> 16:41:50 at
> org.apache.maven.project.MavenProject.getArtifacts(MavenProject.java:715)
> 16:41:50 at
> org.apache.maven.project.MavenProject.deepCopy(MavenProject.java:1218)
> 16:41:50 at
> org.apache.maven.project.MavenProject.(MavenProject.java:197)
> 16:41:50 at
> org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:501)
> 16:41:50 at
> org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:226)
> 16:41:50 ... 14 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAR-192) Sporadic NPE in maven-jar-plugin:2.5:jar
[
https://jira.codehaus.org/browse/MJAR-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360628#comment-360628
]
Alexander Ashitkin edited comment on MJAR-192 at 1/4/15 1:42 PM:
-
Feel free to close if not helpfull. Doesnt make sense to waste my time with
such approach.
thanks you
was (Author: alex_ashitkin):
Feel free to close if not helpfull. Doesnt make sense to waste time on this
approach.
thanks in advance
> Sporadic NPE in maven-jar-plugin:2.5:jar
>
>
> Key: MJAR-192
> URL: https://jira.codehaus.org/browse/MJAR-192
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.5
> Environment: win 2008 server x64 java 8u25 maven 3.2.5
>Reporter: Alexander Ashitkin
>
> Strange npe at jar goal:
> {code}
> 16:41:50 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-jar-plugin:2.5:jar (default-jar) on project
> my-model: Error assembling JAR: NullPointerException -> [Help 1]
> 16:41:50 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-jar-plugin:2.5:jar (default-jar)
> on project my-model: Error assembling JAR
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:188)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:184)
> 16:41:50 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 16:41:50 at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 16:41:50 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 16:41:50 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 16:41:50 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 16:41:50 at java.lang.Thread.run(Thread.java:745)
> 16:41:50 Caused by: org.apache.maven.plugin.MojoExecutionException: Error
> assembling JAR
> 16:41:50 at
> org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:233)
> 16:41:50 at
> org.apache.maven.plugin.jar.AbstractJarMojo.execute(AbstractJarMojo.java:251)
> 16:41:50 at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 16:41:50 ... 11 more
> 16:41:50 Caused by: java.lang.NullPointerException
> 16:41:50 at
> org.apache.maven.project.MavenProject.getArtifacts(MavenProject.java:715)
> 16:41:50 at
> org.apache.maven.project.MavenProject.deepCopy(MavenProject.java:1218)
> 16:41:50 at
> org.apache.maven.project.MavenProject.(MavenProject.java:197)
> 16:41:50 at
> org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:501)
> 16:41:50 at
> org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:226)
> 16:41:50 ... 14 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAR-192) Sporadic NPE in maven-jar-plugin:2.5:jar
[
https://jira.codehaus.org/browse/MJAR-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360629#comment-360629
]
Michael Osipov commented on MJAR-192:
-
Same here without a sample project.
> Sporadic NPE in maven-jar-plugin:2.5:jar
>
>
> Key: MJAR-192
> URL: https://jira.codehaus.org/browse/MJAR-192
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.5
> Environment: win 2008 server x64 java 8u25 maven 3.2.5
>Reporter: Alexander Ashitkin
>
> Strange npe at jar goal:
> {code}
> 16:41:50 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-jar-plugin:2.5:jar (default-jar) on project
> my-model: Error assembling JAR: NullPointerException -> [Help 1]
> 16:41:50 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-jar-plugin:2.5:jar (default-jar)
> on project my-model: Error assembling JAR
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:188)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:184)
> 16:41:50 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 16:41:50 at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 16:41:50 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 16:41:50 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 16:41:50 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 16:41:50 at java.lang.Thread.run(Thread.java:745)
> 16:41:50 Caused by: org.apache.maven.plugin.MojoExecutionException: Error
> assembling JAR
> 16:41:50 at
> org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:233)
> 16:41:50 at
> org.apache.maven.plugin.jar.AbstractJarMojo.execute(AbstractJarMojo.java:251)
> 16:41:50 at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> 16:41:50 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 16:41:50 ... 11 more
> 16:41:50 Caused by: java.lang.NullPointerException
> 16:41:50 at
> org.apache.maven.project.MavenProject.getArtifacts(MavenProject.java:715)
> 16:41:50 at
> org.apache.maven.project.MavenProject.deepCopy(MavenProject.java:1218)
> 16:41:50 at
> org.apache.maven.project.MavenProject.(MavenProject.java:197)
> 16:41:50 at
> org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:501)
> 16:41:50 at
> org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:226)
> 16:41:50 ... 14 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-897) support multiple release versions
Romain Manni-Bucau created MRELEASE-897: --- Summary: support multiple release versions Key: MRELEASE-897 URL: https://jira.codehaus.org/browse/MRELEASE-897 Project: Maven Release Plugin Issue Type: Improvement Reporter: Romain Manni-Bucau In some project multiple versions are used (tomee release = tomee + openejb releases for instance). It is not always possible to split the project in sub projects and then it is not possible to use maven release plugin. Idea would be to support a whitelist of artifacts (a list of patterns would be great). org.superbiz.component:*:1.0.1 org.superbiz.component:*:4.5.8 For instance or even: org.superbiz.component:*:@major.@minor.@patch org.superbiz.component:*:(@major + 3).@minor.@patch to avoid to change it for each release. This of course would imply the CLI to ask for the multiple versions and not only one even when autoSubModules is set to true (it would just group by versions) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-897) support multiple release versions
[
https://jira.codehaus.org/browse/MRELEASE-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated MRELEASE-897:
Description:
In some project multiple versions are used (tomee release = tomee + openejb
releases for instance). It is not always possible to split the project in sub
projects and then it is not possible to use maven release plugin. Idea would be
to support a whitelist of artifacts (a list of patterns would be great).
{code}
org.superbiz.component:*:1.0.1
org.superbiz.component:*:4.5.8
{code}
For instance or even:
{code}
org.superbiz.component:*:@major.@minor.@patch
org.superbiz.component:*:(@major +
3).@minor.@patch
{code}
to avoid to change it for each release.
This of course would imply the CLI to ask for the multiple versions and not
only one even when autoSubModules is set to true (it would just group by
versions)
was:
In some project multiple versions are used (tomee release = tomee + openejb
releases for instance). It is not always possible to split the project in sub
projects and then it is not possible to use maven release plugin. Idea would be
to support a whitelist of artifacts (a list of patterns would be great).
org.superbiz.component:*:1.0.1
org.superbiz.component:*:4.5.8
For instance or even:
org.superbiz.component:*:@major.@minor.@patch
org.superbiz.component:*:(@major +
3).@minor.@patch
to avoid to change it for each release.
This of course would imply the CLI to ask for the multiple versions and not
only one even when autoSubModules is set to true (it would just group by
versions)
> support multiple release versions
> -
>
> Key: MRELEASE-897
> URL: https://jira.codehaus.org/browse/MRELEASE-897
> Project: Maven Release Plugin
> Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>
> In some project multiple versions are used (tomee release = tomee + openejb
> releases for instance). It is not always possible to split the project in sub
> projects and then it is not possible to use maven release plugin. Idea would
> be to support a whitelist of artifacts (a list of patterns would be great).
> {code}
>
> org.superbiz.component:*:1.0.1
> org.superbiz.component:*:4.5.8
>
> {code}
> For instance or even:
> {code}
>
>
> org.superbiz.component:*:@major.@minor.@patch
> org.superbiz.component:*:(@major +
> 3).@minor.@patch
>
> {code}
> to avoid to change it for each release.
> This of course would imply the CLI to ask for the multiple versions and not
> only one even when autoSubModules is set to true (it would just group by
> versions)
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5741) maven version range not working as expected
[ https://jira.codehaus.org/browse/MNG-5741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roland Wiesemann closed MNG-5741. - Resolution: Not A Bug > maven version range not working as expected > --- > > Key: MNG-5741 > URL: https://jira.codehaus.org/browse/MNG-5741 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.5 > Environment: Windows / Java 7 >Reporter: Roland Wiesemann > Attachments: example.tgz > > > The example is attached to this issue. > - First, install the *test:artifact 1.0.0* into the local repository > - Second, install the *test:artifact 1.1.0-SNAPSHOT* to the local repository > - Thirdly, by the query of the list of the dependence within > test:use-artifact-range appears the artefact *test:artefact:1. 1. 0-SNAPSHOT*. > However, for the version range [1. 0. 0,1. 1) I have expected the *artefact > test:artefact:1. 0. 0*. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1132) Surefire: regular isolated classloader failures in parallelbuild
[
https://jira.codehaus.org/browse/SUREFIRE-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Ashitkin updated SUREFIRE-1132:
-
Environment:
SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux
windows server 2008 x64
Maven 3.2.2, 3.2.3, 3.2.5
Oracle HotSpot JDK 7u25/7u65/8u25
was:
SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux
windows server 2008 x64
Maven 3.2.2, 3.2.3, 3.2.5
Oracle HotSpot JDK 7u25
> Surefire: regular isolated classloader failures in parallelbuild
>
>
> Key: SUREFIRE-1132
> URL: https://jira.codehaus.org/browse/SUREFIRE-1132
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 2.17
> Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux
> windows server 2008 x64
> Maven 3.2.2, 3.2.3, 3.2.5
> Oracle HotSpot JDK 7u25/7u65/8u25
>Reporter: Alexander Ashitkin
> Attachments: consoleText-1.txt, consoleText-2.txt, consoleText-3.txt
>
>
> We have a large project of 300+ modules which regularly fails with different
> kind of classloading issues in different places in surefire plugin. The issue
> is reproduced only with parallel build and is not reproduced in single
> threaded. This is a main contributor in build instability for us. All the not
> loaded dependnecies are actually present in dependency tree. I attached 3
> different samples of how build fails.
> Surefire config:
> {code}
>
> 0
>
> false
> false
>
> {code}
> maven cmd is like install -T 10
> Please advise how to sort this out - ready to run any provided diagnostic
> and evaluate any options.
> Thanks in advance, Alexander
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1132) Surefire: regular isolated classloader failures in parallelbuild
[
https://jira.codehaus.org/browse/SUREFIRE-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360630#comment-360630
]
Alexander Ashitkin commented on SUREFIRE-1132:
--
Hi Tibor.
atm i created own surefire assembly with debug logging and will try to capture
something usefull.looking forward to trace the problem down.
thank you
> Surefire: regular isolated classloader failures in parallelbuild
>
>
> Key: SUREFIRE-1132
> URL: https://jira.codehaus.org/browse/SUREFIRE-1132
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 2.17
> Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux
> windows server 2008 x64
> Maven 3.2.2, 3.2.3, 3.2.5
> Oracle HotSpot JDK 7u25/7u65/8u25
>Reporter: Alexander Ashitkin
> Attachments: consoleText-1.txt, consoleText-2.txt, consoleText-3.txt
>
>
> We have a large project of 300+ modules which regularly fails with different
> kind of classloading issues in different places in surefire plugin. The issue
> is reproduced only with parallel build and is not reproduced in single
> threaded. This is a main contributor in build instability for us. All the not
> loaded dependnecies are actually present in dependency tree. I attached 3
> different samples of how build fails.
> Surefire config:
> {code}
>
> 0
>
> false
> false
>
> {code}
> maven cmd is like install -T 10
> Please advise how to sort this out - ready to run any provided diagnostic
> and evaluate any options.
> Thanks in advance, Alexander
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5749) Support installation of Maven via GVM (Groovy Versions Manager)
[ https://jira.codehaus.org/browse/MNG-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360631#comment-360631 ] Marco Vermeulen commented on MNG-5749: -- Hi all, I am Marco, the guy behind GVM. Unfortunately I won't be supporting Maven on GVM, as like I said elsewhere it's not a tool that is widely used by the Groovy community. If that every changes, I would be more than happy to include it. @Sean, I recommended you simply use brew to install maven for now. As far as I'm concerned, this jira can be closed. > Support installation of Maven via GVM (Groovy Versions Manager) > --- > > Key: MNG-5749 > URL: https://jira.codehaus.org/browse/MNG-5749 > Project: Maven > Issue Type: Improvement > Components: Deployment >Affects Versions: 3.2.5 > Environment: Mac OS & *NIX >Reporter: Sean Gilligan > > Installing and managing Maven versions could be made much easier with GVM. > GVM works great for managing Groovy, Grails, and Gradle versions. As far as I > know there is no technical reason it couldn't install and manage Maven as > well. > The GVM developers have no plans to add support for 'maven', but they may > accept a contribution. In the meantime I'm using Homebrew on Mac OS X, but > GVM would be much nicer. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPLUGIN-288) refactoring: change plugin-tools' model package to org.apache.maven.tools.plugin.extractor.model
Herve Boutemy created MPLUGIN-288:
-
Summary: refactoring: change plugin-tools' model package to
org.apache.maven.tools.plugin.extractor.model
Key: MPLUGIN-288
URL: https://jira.codehaus.org/browse/MPLUGIN-288
Project: Maven Plugin Tools
Issue Type: Task
Components: Metadata Model
Affects Versions: 3.4
Reporter: Herve Boutemy
currently {{org.apache.maven.plugin.tools.model}}
would be more consistent to have
{{org.apache.maven.tools.plugin.extractor.model}} since this desxcriptor is
used to configure extractor (Ant and any other that could require it)
and since it's internal, it won't change anything for end-users
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1132) Surefire: regular isolated classloader failures in parallelbuild
[
https://jira.codehaus.org/browse/SUREFIRE-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Ashitkin updated SUREFIRE-1132:
-
Affects Version/s: 2.18.1
> Surefire: regular isolated classloader failures in parallelbuild
>
>
> Key: SUREFIRE-1132
> URL: https://jira.codehaus.org/browse/SUREFIRE-1132
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 2.17, 2.18.1
> Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux
> windows server 2008 x64
> Maven 3.2.2, 3.2.3, 3.2.5
> Oracle HotSpot JDK 7u25/7u65/8u25
>Reporter: Alexander Ashitkin
> Attachments: consoleText-1.txt, consoleText-2.txt, consoleText-3.txt
>
>
> We have a large project of 300+ modules which regularly fails with different
> kind of classloading issues in different places in surefire plugin. The issue
> is reproduced only with parallel build and is not reproduced in single
> threaded. This is a main contributor in build instability for us. All the not
> loaded dependnecies are actually present in dependency tree. I attached 3
> different samples of how build fails.
> Surefire config:
> {code}
>
> 0
>
> false
> false
>
> {code}
> maven cmd is like install -T 10
> Please advise how to sort this out - ready to run any provided diagnostic
> and evaluate any options.
> Thanks in advance, Alexander
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5749) Support installation of Maven via GVM (Groovy Versions Manager)
[ https://jira.codehaus.org/browse/MNG-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360633#comment-360633 ] Sean Gilligan commented on MNG-5749: Yeah, I'm using Brew for now. I do think there's a void that could be filled with a GVM install for Maven or creating a similar tool for Java/Maven, and I thought an "Improvement request" would be the way to do it. You can go ahead an close this issue. Or, if you request, I can create a new issue with a more general description of the problem. I think there should be something in the ecosystem that manages versions of JVM command line tools. I didn't realize how strongly GVM was intended to be "Groovy only". Let me know if you want me to open a new (more generally stated issue) otherwise it is OK with me if you close it. > Support installation of Maven via GVM (Groovy Versions Manager) > --- > > Key: MNG-5749 > URL: https://jira.codehaus.org/browse/MNG-5749 > Project: Maven > Issue Type: Improvement > Components: Deployment >Affects Versions: 3.2.5 > Environment: Mac OS & *NIX >Reporter: Sean Gilligan > > Installing and managing Maven versions could be made much easier with GVM. > GVM works great for managing Groovy, Grails, and Gradle versions. As far as I > know there is no technical reason it couldn't install and manage Maven as > well. > The GVM developers have no plans to add support for 'maven', but they may > accept a contribution. In the meantime I'm using Homebrew on Mac OS X, but > GVM would be much nicer. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEP-476) add the ability to ignore dependencies in the analyze-* goals
[ https://jira.codehaus.org/browse/MDEP-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360634#comment-360634 ] Henning Schmiedehausen commented on MDEP-476: - Commited as r1649454. > add the ability to ignore dependencies in the analyze-* goals > - > > Key: MDEP-476 > URL: https://jira.codehaus.org/browse/MDEP-476 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: analyze >Affects Versions: 2.9 >Reporter: Henning Schmiedehausen > > The dependency plugin is an essential tool to keep any build sane and from > going off the rails with stale and bad dependencies. However, there are the > few very odd corner cases where a dependency must be on the class path to > ensure compilation but it is not detectable from byte code. > The most prominent example for this are the > com.google.code.findbugs:annotations and com.google.code.findbugs:jsr305 > jars, which only contain annotations but very often lead to unresolvable > compilation problems with both jars present on the classpath. > The analyze goals should have facilities to > - list dependencies that should be ignored if they are declared but unused > - list dependencies that should be ignored if they are undeclared but used > - list dependencies that should be ignored in either case. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
