[jira] (MPIR-249) new dependency-info report not added to goals index page
Herve Boutemy created MPIR-249: -- Summary: new dependency-info report not added to goals index page Key: MPIR-249 URL: https://jira.codehaus.org/browse/MPIR-249 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Components: dependency-info Affects Versions: 2.5 Reporter: Herve Boutemy Priority: Minor -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPIR-249) new dependency-info report not added to goals index page
[ https://jira.codehaus.org/browse/MPIR-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MPIR-249. -- Resolution: Fixed Fix Version/s: 2.6 Assignee: Herve Boutemy done in [r1371103|http://svn.apache.org/viewvc?rev=1371103&view=rev] > new dependency-info report not added to goals index page > > > Key: MPIR-249 > URL: https://jira.codehaus.org/browse/MPIR-249 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Bug > Components: dependency-info >Affects Versions: 2.5 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Minor > Fix For: 2.6 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPIR-250) dependency-info packaging information broken: displays "${project.packaging"
Herve Boutemy created MPIR-250:
--
Summary: dependency-info packaging information broken: displays
"${project.packaging"
Key: MPIR-250
URL: https://jira.codehaus.org/browse/MPIR-250
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Bug
Components: dependency-info
Affects Versions: 2.5
Reporter: Herve Boutemy
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPIR-250) dependency-info packaging information broken: displays "${project.packaging"
[
https://jira.codehaus.org/browse/MPIR-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MPIR-250.
--
Resolution: Fixed
Fix Version/s: 2.6
Assignee: Simone Tripodi
fixed in [r1369732|https://svn.apache.org/viewvc?view=revision&revision=1369732]
> dependency-info packaging information broken: displays "${project.packaging"
>
>
> Key: MPIR-250
> URL: https://jira.codehaus.org/browse/MPIR-250
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-info
>Affects Versions: 2.5
>Reporter: Herve Boutemy
>Assignee: Simone Tripodi
> Fix For: 2.6
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPIR-147) Dependencies report hangs while accessing SSL site. Connection never closes
[
https://jira.codehaus.org/browse/MPIR-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MPIR-147:
---
Description:
mvn site hangs while generating the reports (dump below). This is 100%
reproducible.
This happens while contacting maven-repository.dev.java.net. The connection is
opened and never closed. The connection to this external repository was done
successfully several time in the same build.
Notes:
* a timeout would be useful:
at
org.apache.maven.wagon.providers.http.LightweightHttpWagon.resourceExists(LightweightHttpWagon.java:312)
at
org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.dependencyExistsInRepo(RepositoryUtils.java:219)
* for some reason, the site report bypass our corporate repository (nexus). Cf
MPIR-137
* workaround is to enable
false
false
as done in MPIR-137
{noformat}
Full thread dump Java HotSpot(TM) Client VM (1.5.0_16-133 mixed mode):
"AWT-AppKit" daemon prio=5 tid=0x01038530 nid=0xa0110fa0 runnable
[0x..0xbfffe818]
"Low Memory Detector" daemon prio=5 tid=0x01009030 nid=0x805800 runnable
[0x..0x]
"CompilerThread0" daemon prio=9 tid=0x01008580 nid=0x812c00 waiting on
condition [0x..0xb0b077d8]
"Signal Dispatcher" daemon prio=9 tid=0x01008130 nid=0x811e00 waiting on
condition [0x..0x]
"Finalizer" daemon prio=8 tid=0x01007860 nid=0x819200 in Object.wait()
[0xb0a05000..0xb0a05d90]
at java.lang.Object.wait(Native Method)
- waiting on <0x0a440228> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:120)
- locked <0x0a440228> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:136)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
"Reference Handler" daemon prio=10 tid=0x01007480 nid=0x817800 in Object.wait()
[0xb0984000..0xb0984d90]
at java.lang.Object.wait(Native Method)
- waiting on <0x0a4402b0> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:474)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
- locked <0x0a4402b0> (a java.lang.ref.Reference$Lock)
"main" prio=5 tid=0x01001570 nid=0xb0801000 runnable [0xb07fe000..0xb0800148]
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at
com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:723)
- locked <0x05a4ba78> (a java.lang.Object)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:680)
at
com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
- locked <0x05a4bb28> (a com.sun.net.ssl.internal.ssl.AppInputStream)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
- locked <0x06b58100> (a java.io.BufferedInputStream)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:681)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:626)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:957)
- locked <0x06b56708> (a
sun.net.www.protocol.https.DelegateHttpsURLConnection)
at
java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:367)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:318)
at
org.apache.maven.wagon.providers.http.LightweightHttpWagon.resourceExists(LightweightHttpWagon.java:312)
at
org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.dependencyExistsInRepo(RepositoryUtils.java:219)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printArtifactsLocations(DependenciesRenderer.java:1122)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyRepositoryLocations(DependenciesRenderer.java:641)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:274)
at
org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65)
at
org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:239)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90)
at
org.apache.maven.plugins.site.Repo
[jira] (MPIR-147) Dependencies report hangs while accessing SSL site. Connection never closes
[
https://jira.codehaus.org/browse/MPIR-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MPIR-147.
--
Resolution: Fixed
Fix Version/s: 2.2
Assignee: Vincent Siveton
> Dependencies report hangs while accessing SSL site. Connection never closes
> ---
>
> Key: MPIR-147
> URL: https://jira.codehaus.org/browse/MPIR-147
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 2.1
>Reporter: Jerome Lacoste
>Assignee: Vincent Siveton
> Fix For: 2.2
>
>
> mvn site hangs while generating the reports (dump below). This is 100%
> reproducible.
> This happens while contacting maven-repository.dev.java.net. The connection
> is opened and never closed. The connection to this external repository was
> done successfully several time in the same build.
> Notes:
> * a timeout would be useful:
> at
> org.apache.maven.wagon.providers.http.LightweightHttpWagon.resourceExists(LightweightHttpWagon.java:312)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.dependencyExistsInRepo(RepositoryUtils.java:219)
> * for some reason, the site report bypass our corporate repository (nexus).
> Cf MPIR-137
> * workaround is to enable
> false
> false
> as done in MPIR-137
> {noformat}
> Full thread dump Java HotSpot(TM) Client VM (1.5.0_16-133 mixed mode):
> "AWT-AppKit" daemon prio=5 tid=0x01038530 nid=0xa0110fa0 runnable
> [0x..0xbfffe818]
> "Low Memory Detector" daemon prio=5 tid=0x01009030 nid=0x805800 runnable
> [0x..0x]
> "CompilerThread0" daemon prio=9 tid=0x01008580 nid=0x812c00 waiting on
> condition [0x..0xb0b077d8]
> "Signal Dispatcher" daemon prio=9 tid=0x01008130 nid=0x811e00 waiting on
> condition [0x..0x]
> "Finalizer" daemon prio=8 tid=0x01007860 nid=0x819200 in Object.wait()
> [0xb0a05000..0xb0a05d90]
> at java.lang.Object.wait(Native Method)
> - waiting on <0x0a440228> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:120)
> - locked <0x0a440228> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:136)
> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
> "Reference Handler" daemon prio=10 tid=0x01007480 nid=0x817800 in
> Object.wait() [0xb0984000..0xb0984d90]
> at java.lang.Object.wait(Native Method)
> - waiting on <0x0a4402b0> (a java.lang.ref.Reference$Lock)
> at java.lang.Object.wait(Object.java:474)
> at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
> - locked <0x0a4402b0> (a java.lang.ref.Reference$Lock)
> "main" prio=5 tid=0x01001570 nid=0xb0801000 runnable [0xb07fe000..0xb0800148]
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:129)
> at
> com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
> at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:723)
> - locked <0x05a4ba78> (a java.lang.Object)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:680)
> at
> com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
> - locked <0x05a4bb28> (a com.sun.net.ssl.internal.ssl.AppInputStream)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
> - locked <0x06b58100> (a java.io.BufferedInputStream)
> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:681)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:626)
> at
> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:957)
> - locked <0x06b56708> (a
> sun.net.www.protocol.https.DelegateHttpsURLConnection)
> at
> java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:367)
> at
> sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:318)
> at
> org.apache.maven.wagon.providers.http.LightweightHttpWagon.resourceExists(LightweightHttpWagon.java:312)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.dependencyExistsInRepo(RepositoryUtils.java:219)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.
[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=305884#comment-305884
]
Herve Boutemy commented on MPIR-247:
can you provide a sample project showing the problem?
> "Comparison method violates its general contract!" while generating site
>
>
> Key: MPIR-247
> URL: https://jira.codehaus.org/browse/MPIR-247
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Bug
>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
>
> 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.mergeCollapse(ComparableTimSort.java:376)
> at java.util.ComparableTimSort.sort(ComparableTimSort.java:182)
> at java.util.ComparableTimSort.
[jira] (MPIR-143) Wrong scope/phase requirement documented on project-info-reports:dependencies page
[ https://jira.codehaus.org/browse/MPIR-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MPIR-143. -- Resolution: Incomplete > Wrong scope/phase requirement documented on project-info-reports:dependencies > page > -- > > Key: MPIR-143 > URL: https://jira.codehaus.org/browse/MPIR-143 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Task >Affects Versions: 2.1 > Environment: maven 2.0.9 >Reporter: Stevo Slavic >Priority: Minor > > After discussion on maven user mailing list (see > http://markmail.org/search/?q=sslavic%20list%3Aorg.apache.maven.users#query:sslavic%20list%3Aorg.apache.maven.users+page:2+mid:kkzcdmruemiwpeei+state:results > ) conclusion was that wrong scope is documented on following page: > http://maven.apache.org/plugins/maven-project-info-reports-plugin/dependencies-mojo.html > in Attributes section where instead of "test" in "Requires dependency > resolution of artifacts in scope: test." it should stand "package". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPIR-239) Brazillian Portuguese translation
[ https://jira.codehaus.org/browse/MPIR-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MPIR-239. -- Resolution: Fixed Fix Version/s: 2.5.1 Assignee: Herve Boutemy applied in [r1371124|http://svn.apache.org/viewvc?rev=1371124&view=rev] > Brazillian Portuguese translation > - > > Key: MPIR-239 > URL: https://jira.codehaus.org/browse/MPIR-239 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Improvement >Reporter: Daniel Teleginski Camargo >Assignee: Herve Boutemy >Priority: Minor > Fix For: 2.5.1 > > Attachments: project-info-report_pt_BR.properties > > > Missing parts for the new version. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-900) System.err seems to be ignored
[ https://jira.codehaus.org/browse/SUREFIRE-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305890#comment-305890 ] Kristian Rosenvold commented on SUREFIRE-900: - Well we might be able to fix that ;) I just said we capture it and then play it back. Of course we can (and should) play back to stderr. > System.err seems to be ignored > -- > > Key: SUREFIRE-900 > URL: https://jira.codehaus.org/browse/SUREFIRE-900 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.7.2 > Environment: OS/X 10.7.4 >Reporter: Marco Brandizi >Assignee: Kristian Rosenvold >Priority: Minor > Attachments: testSureFireStdErr.zip > > > See the attached project. If I send something to System.err from a JUnit test > and then I try 'mvn test 2>/dev/null', I can still see the output on the > console, surefire (or Maven?!) seems to ignore this. I've tried with > -Dsurefire.forkMode=false too. Is it possible to redirect the standard error? > I'd like to do that because I have a few tests that tests a line command (ie, > main()). Since the command is supposed to return XML to the invoker (which, > for example, might pipe it to another command), I've implemented this command > line by sending all the logging output to System.err (that's possible in > Logback via the 'Target' option in the Console appender). When I invoke this > line command outside Maven/Surefire it works as I want. In Maven, instead, I > cannot what I described. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2971) Variables are not replaced into installed pom file
[
https://jira.codehaus.org/browse/MNG-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305891#comment-305891
]
Mike Gould commented on MNG-2971:
-
We need this for a multi-module build. We want to specify that some sibling
module dependencies have the same version as the parent or current project. If
we do this:
com.example
common
${project.version}
compile
then the varible appears in the installed pom and then can't be used by
anything.
Currently - like most people - we have a pre-build step which sets all versions
accross the whole tree.
Putting this functionality into the release plugin would be completely useless
as the release plugin simply doesn't do the right thing for CI style builds
where the version is set from the build number/scm revision etc.
> Variables are not replaced into installed pom file
> --
>
> Key: MNG-2971
> URL: https://jira.codehaus.org/browse/MNG-2971
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Deployment, Inheritance and Interpolation
> Environment: Windows, Solaris
> Maven version 2.0.4
>Reporter: Laurent Dauvilaire
>Assignee: Ralph Goers
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: pom.xml
>
>
> Variables are not replaced into installed pom file.
> Here is a sample pom file
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> com.xxx.root
> root
> pom
> ${prop.version}
> My Project
> ...
>
> 3.0.20
>
>
> The installed pom is into
> ${localRepository}/com/xxx/root/root/3.0.20/root-3.0.20.pom
> is the same as the project pom file but the version referenced into the
> installed pom file is ${prop.version} instead of 3.0.20
> which creates problem to artifacts depending of this one.
> Thanks in advance
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-622) Unable to create "TAR" artifacts
Ahmed El-Madhoun created MASSEMBLY-622: -- Summary: Unable to create "TAR" artifacts Key: MASSEMBLY-622 URL: https://jira.codehaus.org/browse/MASSEMBLY-622 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.3 Environment: [aelmadho@aelmadho-laptop Kernel]$ mvn -version Apache Maven 3.0.4 (rNON-CANONICAL_2012-07-25_12-05_mockbuild; 2012-07-25 08:05:49-0400) Maven home: /usr/share/maven Java version: 1.7.0_05-icedtea, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.5.x86_64/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "3.5.0-2.fc17.x86_64", arch: "amd64", family: "unix" Reporter: Ahmed El-Madhoun Priority: Critical Attachments: assembly.xml, maven-assembly-error.txt, pom.xml To reproduce the case, you may need to just re-point the POM to the assembly descriptor attached. I am simply able to do the same if I specify a type of "jar" or "zip", but not when using any sort of "tar" based type. We are using this as a primary basis of our build, which is primarily in C, and I would greatly appreciate any help or feedback on this item. Alot of thanks on the great work already! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-622) Unable to create "TAR" artifacts
[ https://jira.codehaus.org/browse/MASSEMBLY-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305895#comment-305895 ] Ahmed El-Madhoun commented on MASSEMBLY-622: I was able to get passed this issue by changing the amount of artifacts that I am including in the "include" subfolder, so I changed my assembly descriptor to have this include instead: stblinux-2.6.37/.config stblinux-2.6.37/Module.symvers stblinux-2.6.37/include/**/*.h stblinux-2.6.37/arch/mips/** stblinux-2.6.37/scripts/** stblinux-2.6.37/Makefile uclinux-rootfs/images/** uclinux-rootfs/images/vmlinuz-* Note stblinux-2.6.37/include/**/*.h is only including header files. I can provide you with full list of files if that would help, but at least, we only need the headers to get passed this, but it would be nice to know if there is an issue and perhaps have it fixed. Thanks in advance for your help! > Unable to create "TAR" artifacts > > > Key: MASSEMBLY-622 > URL: https://jira.codehaus.org/browse/MASSEMBLY-622 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: [aelmadho@aelmadho-laptop Kernel]$ mvn -version > Apache Maven 3.0.4 (rNON-CANONICAL_2012-07-25_12-05_mockbuild; 2012-07-25 > 08:05:49-0400) > Maven home: /usr/share/maven > Java version: 1.7.0_05-icedtea, vendor: Oracle Corporation > Java home: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.5.x86_64/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "3.5.0-2.fc17.x86_64", arch: "amd64", family: > "unix" >Reporter: Ahmed El-Madhoun >Priority: Critical > Attachments: assembly.xml, maven-assembly-error.txt, pom.xml > > > To reproduce the case, you may need to just re-point the POM to the assembly > descriptor attached. I am simply able to do the same if I specify a type of > "jar" or "zip", but not when using any sort of "tar" based type. > We are using this as a primary basis of our build, which is primarily in C, > and I would greatly appreciate any help or feedback on this item. > Alot of thanks on the great work already! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305897#comment-305897 ] Merlijn commented on MNG-3092: -- It may be that I'm overlooking something so please point out obvious drawbacks/errors. However; would it not be desirable to: - IF the project version is a -SNAPSHOT version also resolve dependency ranges to -SNAPSHOT versions - otherwise ( project is a release version) do not. > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson > Attachments: MNG-3092.patch > > > Contrary to the 2.0 design docs: > "Resolution of dependency ranges should not resolve to a snapshot > (development version) unless it is included as an explicit boundary." > -- from > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification > The following is equates to true: > VersionRange.createFromVersionSpec( "[1.0,1.1]" ).containsVersion( new > DefaultArtifactVersion( "1.1-SNAPSHOT" ) ) > The attached patch only allows snapshot versions to be contained in a range > if they are equal to one of the boundaries. Note that this is a strict > equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305897#comment-305897 ] Merlijn edited comment on MNG-3092 at 8/9/12 7:42 AM: -- It may be that I'm overlooking something so please point out obvious drawbacks/errors. However; would it not be desirable to: - IF the project version is a -SNAPSHOT version also resolve dependency ranges to -SNAPSHOT versions - otherwise ( project is a release version) do not. edit; I realise that this would make version resolution context dependent which may be (very?) undesireable was (Author: merlijn): It may be that I'm overlooking something so please point out obvious drawbacks/errors. However; would it not be desirable to: - IF the project version is a -SNAPSHOT version also resolve dependency ranges to -SNAPSHOT versions - otherwise ( project is a release version) do not. > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson > Attachments: MNG-3092.patch > > > Contrary to the 2.0 design docs: > "Resolution of dependency ranges should not resolve to a snapshot > (development version) unless it is included as an explicit boundary." > -- from > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification > The following is equates to true: > VersionRange.createFromVersionSpec( "[1.0,1.1]" ).containsVersion( new > DefaultArtifactVersion( "1.1-SNAPSHOT" ) ) > The attached patch only allows snapshot versions to be contained in a range > if they are equal to one of the boundaries. Note that this is a strict > equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5324) Incorrect parsing of metadata by Maven: Cannot find snapshot artifact with older timestamp
Anton Smeenk created MNG-5324: - Summary: Incorrect parsing of metadata by Maven: Cannot find snapshot artifact with older timestamp Key: MNG-5324 URL: https://jira.codehaus.org/browse/MNG-5324 Project: Maven 2 & 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.0.4 Reporter: Anton Smeenk Maven can only retrieve an artifact from Nexus with a classifier with latest timestamp. Artifacts with classifiers with an older timestamp cannot be resolved. For example. If I deploy an artifact Apple with classifier A and a bit later deploy the same artifact with classifier B. Next I want to retrieve the artifacts from Nexus: For a module Banana, which needs Apple with classifier A the Artifact resolver will fail. For a module Strawberry, which needs Apple with classifier B the Artifact resolver will succesfully resolve the artifact. I found the cause for this behaviour: With an proxy between Maven and Nexus I could see the behavour of Maven, at the moment that I want to fetch an artifact: First the metadata.xml is fetched from Nexus. This file does contain the timestamp of the latest artifact in nexus and all timestamps of older artifacts, with different classifier. >From this metdata file Maven figures out what the correct name is for the >artifact. But Maven can resolve the name of classifierb, but not the name of classifierB. The metadata is not correctly parsed! All information is there, but still Maven can only find the artifact with the latest timestamp. Here is an example of an metadata file: com.ccv.systems.modules.gen_modem modem 07.20.3-SNAPSHOT 20120809.112920 97 20120809112920 classsifierA jar 07.20.3-20120809.112124-88 20120809112124 classsifierB jar 07.20.3-20120809.112920-97 20120809112920 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-131) DependencyConvergence log statement should be debug instead of info
[
https://jira.codehaus.org/browse/MENFORCER-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305912#comment-305912
]
Sergei Ivanov commented on MENFORCER-131:
-
Yes, please demote the logging to DEBUG. I was going to create a ticket for it,
but it appears it's already been reported.
In some of our projects with lots of dependencies, the plugin dumps hundreds of
lines like below:
{noformat}
[INFO] org.slf4j:slf4j-api 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-api 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-api 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-api 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-log4j12 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-log4j12 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-log4j12 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-log4j12 1.6.2 1.6.2
[INFO] log4j:log4j 1.2.16 1.2.16
[INFO] log4j:log4j 1.2.16 1.2.16
[INFO] log4j:log4j 1.2.16 1.2.16
[INFO] org.slf4j:slf4j-api 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-api 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-api 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-api 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-api 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-log4j12 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-log4j12 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-log4j12 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-log4j12 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-log4j12 1.6.2 1.6.2
[INFO] log4j:log4j 1.2.16 1.2.16
[INFO] log4j:log4j 1.2.16 1.2.16
[INFO] log4j:log4j 1.2.16 1.2.16
[INFO] log4j:log4j 1.2.16 1.2.16
{noformat}
> DependencyConvergence log statement should be debug instead of info
> ---
>
> Key: MENFORCER-131
> URL: https://jira.codehaus.org/browse/MENFORCER-131
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Andrew Ruch
>Priority: Minor
> Attachments: MENFORCER-131-enforcer-rules.patch
>
>
> In the DependencyVersionMap on line 87, an log prints every dependency and
> its version information. This seems unnecessary as an info level log.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
doxia-book-maven-plugin 1.3
I want to use doxia-book-maven-plugin to create documentation by converting Markdown files to PDF(s). The Markdown module only seems to be available for Doxia 1.3, but I can't find version 1.3 of the corresponding doxia-book-maven-plugin on Maven Central. Is it still in development? Is it only available as a snapshot and if so how would I integrate the snapshot into my build? Best regards Oliver Schrenk
[jira] (MEAR-146) Expose parameter to not write library-directory element in application.xml
[ https://jira.codehaus.org/browse/MEAR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Halovanic updated MEAR-146: Attachment: ear-remove-librarydirectory-IT.patch ear-remove-librarydirectory.patch Updated to be inside "webLogic" section > Expose parameter to not write library-directory element in application.xml > -- > > Key: MEAR-146 > URL: https://jira.codehaus.org/browse/MEAR-146 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.7 > Environment: Oracle WebLogic >Reporter: Alex Halovanic >Priority: Minor > Attachments: ear-remove-librarydirectory-IT.patch, > ear-remove-librarydirectory-IT.patch, ear-remove-librarydirectory.patch, > ear-remove-librarydirectory.patch > > > The current handling of defaultLibBundleDir leads to some issues on Oracle > Weblogic 10+. The Ear plugin currently sets library-directory to the value > of defaultLibBundleDir in the application.xml for EARs v5+. Some of Oracle's > classloading features break (specifically "Generic File Loading") when this > element is set. defaultLibBundleDir has to be set to APP-INF/lib since this > is the magic library folder for WebLogic. > The patch adds a parameter to prevent setting library-directory for cases > like this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-786) -Darguments doesn't allow -T to be passed to forked builds for multi threading
Tom Clark created MRELEASE-786:
--
Summary: -Darguments doesn't allow -T to be passed to forked
builds for multi threading
Key: MRELEASE-786
URL: https://jira.codehaus.org/browse/MRELEASE-786
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.3.2
Reporter: Tom Clark
I would like to be able to use -T with the release plugin for the compiling
phase, as the plugin is thread safe, which would allow for about half the
release time.
I've tried:
{code}
-Darguments='-T 3'
{code}
which doesn't throw an error but doesn't actually trigger multi threading.
also:
{code}
-Darguments='-T3'
-Darguments='"-T 3"'
{code}
Both throws an error saying that -T isn't parsable
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on
project parent: Failed to re-parse additional arguments for Maven invocation.
Unrecognized option: -T -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on
project parent: Failed to re-parse additional arguments for Maven invocation.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
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:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to re-parse
additional arguments for Maven invocation.
at
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:295)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:247)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: org.apache.maven.shared.release.ReleaseExecutionException: Failed to
re-parse additional arguments for Maven invocation.
at
org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase.java:89)
at
org.apache.maven.shared.release.phase.RunPrepareGoalsPhase.execute(RunPrepareGoalsPhase.java:44)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:234)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:169)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:146)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:107)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:291)
... 22 more
Caused by: org.apache.maven.shared.release.exec.MavenExecutorException: Failed
to re-parse additional arguments for Maven invocation.
at
org.apache.maven.shared.release.exec.InvokerMavenExecutor.setupRequest(InvokerMavenExecutor.java:335)
at
org.apache.maven.shared.release.exec.InvokerMavenExecutor.executeGoals(InvokerMavenExecutor.java:394)
at
org.apache.maven.shared.release.exec.AbstractMavenExecutor.executeGoals(AbstractMavenExecutor.java:85)
at
org.apache.maven.shared.r
[jira] (MEAR-156) defaultLibBundleDir setting producing odd behavior in Oracle's oepe version of eclipse Galileo
robert stettler created MEAR-156: Summary: defaultLibBundleDir setting producing odd behavior in Oracle's oepe version of eclipse Galileo Key: MEAR-156 URL: https://jira.codehaus.org/browse/MEAR-156 Project: Maven 2.x Ear Plugin Issue Type: Bug Affects Versions: 2.7 Environment: Windows 7, Eclipse Galileo (Oracle bundled oepe), 2.9 maven-eclipse-plugin, 2.7 maven-ear-plugin and 2.0 wtp Reporter: robert stettler Attachments: epf-refapp-federated-producer4.zip When I set defaultLibBundle dir as APP-INF/lib my maven dependency libraries are dropped into the APP-INF/lib/APP-INF. When I look at the eclipse project settings under JEE Dependencies I see jars listed as APP-INF/lib/../myjar.jar. In the org.eclipse.wst.common.component file that was generated the archiveName for each jar has ../myjar.jar and the deploy-path is set as APP-INF/lib. If I manually remove the .. from the entries the EAR builds as expected. Not sure what is driving the .. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-786) -Darguments doesn't allow -T to be passed to forked builds for multi threading
[
https://jira.codehaus.org/browse/MRELEASE-786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-786:
Component/s: prepare
> -Darguments doesn't allow -T to be passed to forked builds for multi threading
> --
>
> Key: MRELEASE-786
> URL: https://jira.codehaus.org/browse/MRELEASE-786
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.3.2
>Reporter: Tom Clark
>
> I would like to be able to use -T with the release plugin for the compiling
> phase, as the plugin is thread safe, which would allow for about half the
> release time.
> I've tried:
> {code}
> -Darguments='-T 3'
> {code}
> which doesn't throw an error but doesn't actually trigger multi threading.
> also:
> {code}
> -Darguments='-T3'
> -Darguments='"-T 3"'
> {code}
> Both throws an error saying that -T isn't parsable
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on
> project parent: Failed to re-parse additional arguments for Maven invocation.
> Unrecognized option: -T -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare
> (default-cli) on project parent: Failed to re-parse additional arguments for
> Maven invocation.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
> 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:319)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to re-parse
> additional arguments for Maven invocation.
> at
> org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:295)
> at
> org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:247)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: org.apache.maven.shared.release.ReleaseExecutionException: Failed
> to re-parse additional arguments for Maven invocation.
> at
> org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase.java:89)
> at
> org.apache.maven.shared.release.phase.RunPrepareGoalsPhase.execute(RunPrepareGoalsPhase.java:44)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:234)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:169)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:146)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:107)
> at
> org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:291)
> ... 22 more
> Caused by: org.apache.maven.shared.release.exec.MavenExecutorException:
> Failed to re-parse additional arguments for Maven invocation.
> at
>
[jira] (MRELEASE-755) When passing arguments to underlying maven executions not all maven options are accepted
[
https://jira.codehaus.org/browse/MRELEASE-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-755:
Summary: When passing arguments to underlying maven executions not all
maven options are accepted (was: When passing aruments to undelying maven
executions not all maven options are accepted)
> When passing arguments to underlying maven executions not all maven options
> are accepted
>
>
> Key: MRELEASE-755
> URL: https://jira.codehaus.org/browse/MRELEASE-755
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.2.2
>Reporter: Sandy McPherson
>
> The command
> {code}
> + /opt/imc/maven3/bin/mvn -B -PStaged-distribution --settings
> ../corrie/settings-build-release.xml -gs ../corrie/settings-global.xml
> '-Darguments=-PStaged-distribution -s ../corrie/settings-build-release.xml
> -gs ../corrie/settings-global.xml' release:prepare -DreleaseVersion=10.3765
> {code}
> Produces the following error:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.2.2:prepare (default-cli) on
> project corrie: Failed to re-parse additional arguments for Maven invocation.
> Unrecognized option: -g -> [Help 1]
> [ERROR]
> {code}
> Also tried with --global-settings and this also failed with an anrecocgnized
> option --global-settings
> Would seem pointless for the plugin to do any additional parsing, just pass
> it to maven and let the underlying execution complain.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-872) use maven-plugin-tools' java 5 annotations
[ https://jira.codehaus.org/browse/SUREFIRE-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-872. --- Resolution: Fixed Fix Version/s: 2.12.1 > use maven-plugin-tools' java 5 annotations > -- > > Key: SUREFIRE-872 > URL: https://jira.codehaus.org/browse/SUREFIRE-872 > Project: Maven Surefire > Issue Type: Task >Affects Versions: 2.12 >Reporter: Herve Boutemy > Fix For: 2.12.1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-853) test
[ https://jira.codehaus.org/browse/SUREFIRE-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-853. --- Resolution: Incomplete Assignee: Kristian Rosenvold > test > > > Key: SUREFIRE-853 > URL: https://jira.codehaus.org/browse/SUREFIRE-853 > Project: Maven Surefire > Issue Type: Bug >Reporter: 宋雪峰 >Assignee: Kristian Rosenvold > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-156) defaultLibBundleDir setting producing odd behavior in Oracle's oepe version of eclipse Galileo
[ https://jira.codehaus.org/browse/MEAR-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305947#comment-305947 ] Stéphane Nicoll commented on MEAR-156: -- I am not sure I get this. Do you have an issue with the ear plugin or in Gelileo? If that's an issue in Galileo, you reported this at the wrong place. Does this work when you invoke maven on the command line? > defaultLibBundleDir setting producing odd behavior in Oracle's oepe version > of eclipse Galileo > -- > > Key: MEAR-156 > URL: https://jira.codehaus.org/browse/MEAR-156 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.7 > Environment: Windows 7, Eclipse Galileo (Oracle bundled oepe), 2.9 > maven-eclipse-plugin, 2.7 maven-ear-plugin and 2.0 wtp >Reporter: robert stettler > Attachments: epf-refapp-federated-producer4.zip > > > When I set defaultLibBundle dir as APP-INF/lib my maven dependency libraries > are dropped into the APP-INF/lib/APP-INF. When I look at the eclipse project > settings under JEE Dependencies I see jars listed as > APP-INF/lib/../myjar.jar. > In the org.eclipse.wst.common.component file that was generated the > archiveName for each jar has ../myjar.jar and the deploy-path is set as > APP-INF/lib. If I manually remove the .. from the entries the EAR builds as > expected. Not sure what is driving the .. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-473) when branching the minor-version-number should be increased not the incremental version
[ https://jira.codehaus.org/browse/MRELEASE-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305950#comment-305950 ] Sergio Weigel commented on MRELEASE-473: I just can't believe that this had been reported such a long time ago and no one replied to it. This is a serious drawback and actually a show stopper for the release plugin. If I cannot make fixes on my releases branch after the first tag and deliver without getting into conflict with version numbers, it is quite useless, innit? Why have a plugin to automate the release process, if I have to manually enter the version number in the first place?` Did you find a way to solve this, Michael? I think a patch is in order... > when branching the minor-version-number should be increased not the > incremental version > --- > > Key: MRELEASE-473 > URL: https://jira.codehaus.org/browse/MRELEASE-473 > Project: Maven 2.x Release Plugin > Issue Type: Wish > Components: branch >Affects Versions: 2.0-beta-9 >Reporter: Michael Wenig > > When you are using the branches the follwowing method is normally used (at > least at the sites I am working): > trunk: > major.minor.1-SNAPSHOT > releases are only made out of a branch, so the branch name is normally > Release_major_minor and the incremental number denotes the release. > Now a problem occurs in the trunk as per default just the incremental version > is increased (as -SNAPSHOT) > Example: > Version on trunk: 0.0.1-SNAPSHOT > create a branch Release_0_0 > Now on branch there is 0.0.1-SNAPSHOT (correct) > On trunk is 0.0.2-SNAPSHOT per default which will conflict when doing a > release on the branch (as there will be also a 0.0.2-SNAPSHOT per default) > On trunk it would make more sense to have either 0.1.0-SNAPSHOT oder > 1.0.0-SNAPSHOT > So the normal case is to have someone decide on branching if the major or > minor-version should be increased on the trunk. Currently everytime someone > has to manually redefine the new development version. Increasing the > minor-number and resetting the incremental to '0' would be a more useful > default as it is the way 99% of the numbers are made. > Another way I saw is to have on trunk only 2-numbered-versions (as > 0.1-SNAPSHOT) and then directly after branching changing the version on the > branch to 0.1.0-SNAPSHOT. This also makes sense especially if you only want > to branch if you have to make some hotfixes. > I would suggest to add a parameter to the branch goal which is able to switch > between the three possibilities: > - the 'old way' (even if from my sight the current scheme could be > completely dropped as I do not know any project which is able to use this) > - increasing the minor number on trunk and resetting the incremental to > 0-SNAPSHOT > - using two-number-scheme on trunk and three number-scheme on branch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
