[jira] Commented: (DOXIA-434) Warning about old link format fails to note location of bad link
[ https://jira.codehaus.org/browse/DOXIA-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=271987#comment-271987 ] Lukas Theussl commented on DOXIA-434: - Indicating the source file name is currently not possible because doxia parsers don't get the source document passed in, see DOXIA-224. However, if you run with -X you should see the file that is being processed when the warning is emitted. > Warning about old link format fails to note location of bad link > > > Key: DOXIA-434 > URL: https://jira.codehaus.org/browse/DOXIA-434 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Apt >Affects Versions: 1.2 >Reporter: Benson Margulies > > Consider: > [INFO] Skipped "About" report, file "index.html" already exists for the > English version. > [WARNING] [APT Parser] Modified invalid link: '#Resources' to '#aResources' > Ok, well, what file? What line of the file? > you can repro this with rev r1141511 of the maven-assembly-plugin. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-738) Fail on not existing run order.
[ https://jira.codehaus.org/browse/SUREFIRE-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-738. --- Resolution: Fixed Assignee: Kristian Rosenvold Thanks, Nice patch! Applied unmodified in r1141846 > Fail on not existing run order. > --- > > Key: SUREFIRE-738 > URL: https://jira.codehaus.org/browse/SUREFIRE-738 > Project: Maven Surefire > Issue Type: Improvement >Reporter: Stefan Birkner >Assignee: Kristian Rosenvold >Priority: Minor > Attachments: surefire-738.patch > > > I want surefire to fail, if I start surefire with a run order, which is not > in the set alphabetical, reversealphabetical, random, hourly and fileset. > Today I don't get any information, when I start surefire with a wrong run > order like alphapetical. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-738) Fail on not existing run order.
[ https://jira.codehaus.org/browse/SUREFIRE-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-738: Fix Version/s: 2.10 > Fail on not existing run order. > --- > > Key: SUREFIRE-738 > URL: https://jira.codehaus.org/browse/SUREFIRE-738 > Project: Maven Surefire > Issue Type: Improvement >Reporter: Stefan Birkner >Assignee: Kristian Rosenvold >Priority: Minor > Fix For: 2.10 > > Attachments: surefire-738.patch > > > I want surefire to fail, if I start surefire with a run order, which is not > in the set alphabetical, reversealphabetical, random, hourly and fileset. > Today I don't get any information, when I start surefire with a wrong run > order like alphapetical. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-754) unbounded memory use when capturing logs
[ https://jira.codehaus.org/browse/SUREFIRE-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-754: Fix Version/s: 2.10 > unbounded memory use when capturing logs > > > Key: SUREFIRE-754 > URL: https://jira.codehaus.org/browse/SUREFIRE-754 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.9 >Reporter: Andrew Gaul > Fix For: 2.10 > > > Surefire should dump logs directly to a file instead of buffering in-memory. > Exception in thread "ThreadedStreamConsumer" java.lang.OutOfMemoryError: Java > heap space > at java.util.Arrays.copyOf(Arrays.java:2894) > at > java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:117) > at > java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:407) > at java.lang.StringBuffer.append(StringBuffer.java:241) > at > org.apache.maven.surefire.report.ConsoleOutputFileReporter.writeMessage(ConsoleOutputFileReporter.java:115) > at > org.apache.maven.surefire.report.MulticastingReporter.writeMessage(MulticastingReporter.java:101) > at > org.apache.maven.surefire.report.TestSetRunListener.writeTestOutput(TestSetRunListener.java:99) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:132) > at > org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67) > at java.lang.Thread.run(Thread.java:679) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-754) unbounded memory use when capturing logs
[ https://jira.codehaus.org/browse/SUREFIRE-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=271994#comment-271994 ] Kristian Rosenvold commented on SUREFIRE-754: - The interesting thing about this issue is that is has switched VM in 2.9. In previous versions you'd be tweaking argLine on the forked jvm to allocate more memory, whereas now the buffer usage is within the surefire plugin itself, meaning you have to tweak MAVEN_OPTS to get more memory. I will try to fix the underlying problem, just figured you'd like to know this workaround as of now. > unbounded memory use when capturing logs > > > Key: SUREFIRE-754 > URL: https://jira.codehaus.org/browse/SUREFIRE-754 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.9 >Reporter: Andrew Gaul > Fix For: 2.10 > > > Surefire should dump logs directly to a file instead of buffering in-memory. > Exception in thread "ThreadedStreamConsumer" java.lang.OutOfMemoryError: Java > heap space > at java.util.Arrays.copyOf(Arrays.java:2894) > at > java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:117) > at > java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:407) > at java.lang.StringBuffer.append(StringBuffer.java:241) > at > org.apache.maven.surefire.report.ConsoleOutputFileReporter.writeMessage(ConsoleOutputFileReporter.java:115) > at > org.apache.maven.surefire.report.MulticastingReporter.writeMessage(MulticastingReporter.java:101) > at > org.apache.maven.surefire.report.TestSetRunListener.writeTestOutput(TestSetRunListener.java:99) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:132) > at > org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67) > at java.lang.Thread.run(Thread.java:679) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-754) unbounded memory use when capturing logs
[ https://jira.codehaus.org/browse/SUREFIRE-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-754. --- Resolution: Fixed Assignee: Kristian Rosenvold Fixed in r1141846, this was probably introduced in 2.9 Existing test cases should cover the functional part. > unbounded memory use when capturing logs > > > Key: SUREFIRE-754 > URL: https://jira.codehaus.org/browse/SUREFIRE-754 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.9 >Reporter: Andrew Gaul >Assignee: Kristian Rosenvold > Fix For: 2.10 > > > Surefire should dump logs directly to a file instead of buffering in-memory. > Exception in thread "ThreadedStreamConsumer" java.lang.OutOfMemoryError: Java > heap space > at java.util.Arrays.copyOf(Arrays.java:2894) > at > java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:117) > at > java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:407) > at java.lang.StringBuffer.append(StringBuffer.java:241) > at > org.apache.maven.surefire.report.ConsoleOutputFileReporter.writeMessage(ConsoleOutputFileReporter.java:115) > at > org.apache.maven.surefire.report.MulticastingReporter.writeMessage(MulticastingReporter.java:101) > at > org.apache.maven.surefire.report.TestSetRunListener.writeTestOutput(TestSetRunListener.java:99) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:132) > at > org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67) > at java.lang.Thread.run(Thread.java:679) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-594) release:stage does not properly compute new distroManagement.site.URL or project.URLs for projects
[
https://jira.codehaus.org/browse/MSITE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272002#comment-272002
]
Stephen Connolly commented on MSITE-594:
Not an issue with release plugin as release plugin just plain delegates to
site:stage-deploy
> release:stage does not properly compute new distroManagement.site.URL or
> project.URLs for projects
> --
>
> Key: MSITE-594
> URL: https://jira.codehaus.org/browse/MSITE-594
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:stage(-deploy)
>Reporter: John Allen
>Priority: Blocker
>
> In the case where you have a multi-module project and each module has its own
> distributionManagement.site.url which is common with projects that like their
> sites to be version numbered (see example beolw) the release:stage plugin
> fails to get the project's site properly deployed. From a brief look it seems
> release:sxtage is only computing a new URL for the owning project and not all
> the child projects. What's more it looks like its changing the site
> deployment URL and not the project's corresponding project URL. This results
> in the site deployment for children going to their original pom.xml specific
> locations regardless of them being 'staged' (i.e. they're not staged, they've
> just gone live!). Nearly as bad is that all the relative links for connecting
> modules and parents and banners together are broken too, as they are based
> upoin the project.URL which hasnt been touched by the release:stage mojo.
> site:stage makes a better fist of this, basically you need to remap the
> entire URL domain (site distro and project url) to be under some other parent
> space for you to successfully stage sites (see site:stage)
> This kind of mistake has come up in the past, simply put a project can define
> all its own settings for everything so anything that makes assumptions based
> on inheritence or 'defaults' is just gonna break the system.
> Example of how sub-project's defining their own site deployemtn and project
> URL information:
> {noformat}
>
>
> dav:https://example.com/maven/sites/${mvn.repoName}/${project.groupId}/${project.artifactId}/${project.version}
>
> http://example.com/maven/sites/${mvn.repoName}/${project.groupId}/${project.artifactId}/${project.version}/
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MSITE-594) release:stage does not properly compute new distroManagement.site.URL or project.URLs for projects
[
https://jira.codehaus.org/browse/MSITE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly moved MRELEASE-395 to MSITE-594:
-
Component/s: (was: stage)
site:stage(-deploy)
Affects Version/s: (was: 2.0-beta-8)
Key: MSITE-594 (was: MRELEASE-395)
Project: Maven 2.x and 3.x Site Plugin (was: Maven 2.x Release
Plugin)
> release:stage does not properly compute new distroManagement.site.URL or
> project.URLs for projects
> --
>
> Key: MSITE-594
> URL: https://jira.codehaus.org/browse/MSITE-594
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:stage(-deploy)
>Reporter: John Allen
>Priority: Blocker
>
> In the case where you have a multi-module project and each module has its own
> distributionManagement.site.url which is common with projects that like their
> sites to be version numbered (see example beolw) the release:stage plugin
> fails to get the project's site properly deployed. From a brief look it seems
> release:sxtage is only computing a new URL for the owning project and not all
> the child projects. What's more it looks like its changing the site
> deployment URL and not the project's corresponding project URL. This results
> in the site deployment for children going to their original pom.xml specific
> locations regardless of them being 'staged' (i.e. they're not staged, they've
> just gone live!). Nearly as bad is that all the relative links for connecting
> modules and parents and banners together are broken too, as they are based
> upoin the project.URL which hasnt been touched by the release:stage mojo.
> site:stage makes a better fist of this, basically you need to remap the
> entire URL domain (site distro and project url) to be under some other parent
> space for you to successfully stage sites (see site:stage)
> This kind of mistake has come up in the past, simply put a project can define
> all its own settings for everything so anything that makes assumptions based
> on inheritence or 'defaults' is just gonna break the system.
> Example of how sub-project's defining their own site deployemtn and project
> URL information:
> {noformat}
>
>
> dav:https://example.com/maven/sites/${mvn.repoName}/${project.groupId}/${project.artifactId}/${project.version}
>
> http://example.com/maven/sites/${mvn.repoName}/${project.groupId}/${project.artifactId}/${project.version}/
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-331) SCM urls are broken for all modules, except the parent
[ https://jira.codehaus.org/browse/MRELEASE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272003#comment-272003 ] Stephen Connolly commented on MRELEASE-331: --- Is this still an issue? > SCM urls are broken for all modules, except the parent > --- > > Key: MRELEASE-331 > URL: https://jira.codehaus.org/browse/MRELEASE-331 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: scm >Affects Versions: 2.0-beta-7 >Reporter: Vincent Siveton >Priority: Blocker > > This comes from the parent pom, which is missing a / at the end of the scm > urls. > See: > http://www.nabble.com/Re%3A-svn-commit%3A-r635240---in--maven-plugin-tools-trunk%3A-.--maven-plugin-plugin--maven-plugin-tools-ant--maven-plugin-tools-api--maven-plugin-tools-beanshell--maven-plugin-tools-java--maven-plugin-tools-javadoc--maven-plugin-tools-model--tt15929761s177.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-331) SCM urls are broken for all modules, except the parent
[ https://jira.codehaus.org/browse/MRELEASE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MRELEASE-331: -- Labels: scrub-review-started (was: ) > SCM urls are broken for all modules, except the parent > --- > > Key: MRELEASE-331 > URL: https://jira.codehaus.org/browse/MRELEASE-331 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: scm >Affects Versions: 2.0-beta-7 >Reporter: Vincent Siveton >Priority: Blocker > Labels: scrub-review-started > > This comes from the parent pom, which is missing a / at the end of the scm > urls. > See: > http://www.nabble.com/Re%3A-svn-commit%3A-r635240---in--maven-plugin-tools-trunk%3A-.--maven-plugin-plugin--maven-plugin-tools-ant--maven-plugin-tools-api--maven-plugin-tools-beanshell--maven-plugin-tools-java--maven-plugin-tools-javadoc--maven-plugin-tools-model--tt15929761s177.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-655) Maven Release Plugin Fails to perform the Release when using TFS scm
[ https://jira.codehaus.org/browse/MRELEASE-655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MRELEASE-655: -- Labels: scrub-review-started (was: ) I cannot make sense of what the issue is... It would help if you gave the command sequence that is being used and the command sequence which should be used, and not as an attachment but as a simple numbered list in a comment. Better still would be a test case, but as most of us don't have TFS, it will really take somebody who has TFS to create a patch... also I suspect this is an issue with maven-scm not the release plugin. > Maven Release Plugin Fails to perform the Release when using TFS scm > > > Key: MRELEASE-655 > URL: https://jira.codehaus.org/browse/MRELEASE-655 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: perform >Affects Versions: 2.1 > Environment: Windows 7 64 bit, Maven 3.0.1, Java 1.6_23, TFS 2010 >Reporter: Nikhil Jain >Priority: Blocker > Labels: scrub-review-started > Attachments: keymanager-release.log, Release_Command.txt > > > We are able to prepare a build successfully using Prepare release but while > performing release the release plugin is not able to perform release using > TFS 2010. It errors due to incorrect sequence of SCM commands for TFS. The > output of perform release is attached. > For performing release we are issuing a command while specifies to use edit > mode, Provides anew TFS workspace to map and a working directory to checkout > code to perform a release. > We are using the release plugin with TFS as suggested on Teamprise site > http://kb.teamprise.com/article/view/95 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-323) Release plugin (prepare goal) doesn't update more than one snapshot dependencies
[
https://jira.codehaus.org/browse/MRELEASE-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly closed MRELEASE-323.
-
Resolution: Duplicate
Fix Version/s: 2.1
Duplicate of MRELEASE-589
> Release plugin (prepare goal) doesn't update more than one snapshot
> dependencies
>
>
> Key: MRELEASE-323
> URL: https://jira.codehaus.org/browse/MRELEASE-323
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-7
> Environment: Any
>Reporter: Alessandro Zucchi
>Priority: Blocker
> Fix For: 2.1
>
> Attachments: patch.txt, test.zip
>
>
> I have a project so structured:
> au au-business
> |
> | au-sistema
> Dependencies in au are:
> ...
>
>
>
> com.zucchetti.qweb.au
> au-business
> ${project.version}
>
>
>
>
> com.zucchetti.qweb.framework
> sistema
> 03.00.02-SNAPSHOT
>
>
> com.zucchetti.qweb.framework
> business
> 03.00.02-SNAPSHOT
>
>
>
> ...
> Dependencies in au-business are:
> ...
>
>
> com.zucchetti.qweb.framework
> business
>
>
> ...
> Dependencies in au-sistema are:
> ...
>
>
> com.zucchetti.qweb.au
> au-business
>
>
> com.zucchetti.qweb.framework
> sistema
>
>
> ...
> When I make a mvn release:clean release:prepare of au project the plugin,
> correctly, ask me to resolve SNAPSHOTs dependencies. (framework-business &&
> framework-sistema)
> Unfortunatly at the end of the process only framework-sistema dependency (in
> au project) has been modified, while framework-business no.
> I've debuged the problem and I found that if I force the two dependencies
> (framework-sistema, framework-business) in the parent pom (pom of "au") all
> run fine (also if the process to resolve SNAPSHOT dependencies get prompted
> tree times ... too much I say ...).But I can't do this change in production.
> So, I tryed to resolve the problem.
> I've attached a patch.
> Best regards
> Alex
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-412) release:prepare does not update properties during rewrite-poms-for-development phase.
[
https://jira.codehaus.org/browse/MRELEASE-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MRELEASE-412:
--
Fix Version/s: 2.3
This looks like it could be applied for 2.3
> release:prepare does not update properties during
> rewrite-poms-for-development phase.
> -
>
> Key: MRELEASE-412
> URL: https://jira.codehaus.org/browse/MRELEASE-412
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-8
> Environment: Maven version: 2.0.10-RC8
> Java version: 1.5.0_14
> OS name: "linux" version: "2.6.28.4" arch: "i386" Family: "unix"
>Reporter: Christian Schulte
>Priority: Blocker
> Labels: maven-patch-available, properties
> Fix For: 2.3
>
> Attachments: MRELEASE-412.patch
>
>
> When a dependency version is specified using a property like
> ${someExpression} that property is correctly updated during the
> rewrite-poms-for-release phase but not during the
> rewrite-poms-for-development phase. The attached patch solves this for me.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-657) Unable to release multi-module project with pom module referencing a property coming from the parent&aggregator root pom as a dependency version : "The version could not
[
https://jira.codehaus.org/browse/MRELEASE-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MRELEASE-657:
--
Labels: scrub-review-started (was: )
If they are using a version which is == ${project.version} can you not just use
the actual version number. The release plugin should update those versions as
long as the dependencies are in the reactor of the parent release... if they
are not in the reactor of the parent release then you are likely asking for
trouble trying to tie an independently released dependency to the project
version.
> Unable to release multi-module project with pom module referencing a property
> coming from the parent&aggregator root pom as a dependency version : "The
> version could not be updated: ${...}"
> -
>
> Key: MRELEASE-657
> URL: https://jira.codehaus.org/browse/MRELEASE-657
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.1
>Reporter: Baptiste MATHUS
>Priority: Critical
> Labels: scrub-review-started
> Attachments: mreleasebug.zip, output.txt
>
>
> Hi,
> In our multi-modules project (same version for all modules, using
> autoVersionSubmodules=true), we have added a bunch of poms that are designed
> to be parent poms from other projects when using our corporate archetypes.
> Those poms reference artifacts from the reactor with the same version.
> To do that, we have a manually set property inside the aggregator root pom.
> This version is always equal to the project version.
> (We do that because we can't use ${project.version} : if we do, when someone
> will use this parent pom, and they define their version, this version will be
> used for the dependencies defined in the parent pom using ${project.version}).
> As I'm aware this is not really simple to explain&understand, I attached a
> testcase to show the problem.
> I'm also attaching the resulting output.
> This problem is present with both maven 3.0.2 and 2.2.1.
> Cheers
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4195) mvn clean install site doesn't work on multi-modules projects
[ https://jira.codehaus.org/browse/MNG-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272012#comment-272012 ] Florian Kirchmeir commented on MNG-4195: I'm having the same issue with Maven 3.0.3. In our case, the build fails because some of the sub-modules don't compile properly without doing a clean before. In my opinion, the execution order suggested above is not the (only) correct way, and is not entriely in line with the way maven usually work. I would expect the following execution order: Clean ParentModule Install ParentModule Site ParentModule Clean Module1 Install Module1 Site Module1 Clean Module2 Install Module2 Site Module2 The actual problem is that maven tries to run "site" (and implicitly "compile") on modules 1 and 2 without having done a "clean" before, which is clearly not what it was instructed to do. > mvn clean install site doesn't work on multi-modules projects > - > > Key: MNG-4195 > URL: https://jira.codehaus.org/browse/MNG-4195 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.2.0 >Reporter: Tiago Bruno Pires Gomes > Fix For: Issues to be reviewed for 3.x > > Attachments: maven.diff, mng-2979-testcase.tar.gz > > > I open a new issue because the MNG-2979 is "closed and fixed" but the issue > remains with the 2.2.0 (http://jira.codehaus.org/browse/MNG-2979). I > reattached the same testcase archive. > For the recall, the issue is quite simple : on the multi-modules projects, > the execution of mvn clean install site fails. > Our project has this components : a ParentModule, a Module1 and a Module2 > which depends on Module1 jar file. > According to the backtrace, the execution of maven follows this steps : > Clean the ParentProject > Install the ParentProject > "Site" the ParentProject > and site want to compile the entire project so it compiles the Module and the > Module2. The Module2 needs the jar of Module1 to compile so the build fails. > In my opinion, the maven core should run successively clean, install and site > on the entire project like : > Clean ParentModule > Clean Module1 > Clean Module2 > Install ParentModule > Install Module1 > Install Module2 > Site ParentModule > Site Module1 > Site Module2 > So, I attached a maven.diff file too, which makes this succession. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-120) Username is completely ignored
[ https://jira.codehaus.org/browse/MRELEASE-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MRELEASE-120: -- Labels: scrub-review-started (was: ) Could somebody please explain exactly what this bug is... seems like a documentation bug... in which case what page should we document and what text should we put in? > Username is completely ignored > -- > > Key: MRELEASE-120 > URL: https://jira.codehaus.org/browse/MRELEASE-120 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: scm >Affects Versions: 2.0-beta-4 >Reporter: Matthew Beermann >Priority: Critical > Labels: scrub-review-started > > When I run something like "mvn release:prepare -DdryRun=true > -Dusername=mb011000", the resulting contents of release.properties suggest > that the username is being completely ignored when forming the scm.url: > scm.username=mb011000 > scm.url=scm\:cvs\:pserver\:anonymous\:@prdwebdev17\:/projects\:system-core > Note that the "anonymous" has stuck around for some reason. This may be > related to MRELEASE-83 and/or MRELEASE-107, but I don't think it's a > duplicate. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-4195) mvn clean install site doesn't work on multi-modules projects
[ https://jira.codehaus.org/browse/MNG-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272012#comment-272012 ] Florian Kirchmeir edited comment on MNG-4195 at 7/1/11 4:18 AM: I'm having the same issue with Maven 3.0.3. In our case, the build fails because some of the sub-modules don't compile properly without doing a clean before. In my opinion, the execution order suggested above is not the (only) correct way, and is not entriely in line with the way maven usually works. I would expect the following execution order: Clean ParentModule Install ParentModule Site ParentModule Clean Module1 Install Module1 Site Module1 Clean Module2 Install Module2 Site Module2 The actual problem is that maven tries to run "site" (and implicitly "compile") on modules 1 and 2 without having done a "clean" before, which is clearly not what it was instructed to do. was (Author: kflorian): I'm having the same issue with Maven 3.0.3. In our case, the build fails because some of the sub-modules don't compile properly without doing a clean before. In my opinion, the execution order suggested above is not the (only) correct way, and is not entriely in line with the way maven usually work. I would expect the following execution order: Clean ParentModule Install ParentModule Site ParentModule Clean Module1 Install Module1 Site Module1 Clean Module2 Install Module2 Site Module2 The actual problem is that maven tries to run "site" (and implicitly "compile") on modules 1 and 2 without having done a "clean" before, which is clearly not what it was instructed to do. > mvn clean install site doesn't work on multi-modules projects > - > > Key: MNG-4195 > URL: https://jira.codehaus.org/browse/MNG-4195 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.2.0 >Reporter: Tiago Bruno Pires Gomes > Fix For: Issues to be reviewed for 3.x > > Attachments: maven.diff, mng-2979-testcase.tar.gz > > > I open a new issue because the MNG-2979 is "closed and fixed" but the issue > remains with the 2.2.0 (http://jira.codehaus.org/browse/MNG-2979). I > reattached the same testcase archive. > For the recall, the issue is quite simple : on the multi-modules projects, > the execution of mvn clean install site fails. > Our project has this components : a ParentModule, a Module1 and a Module2 > which depends on Module1 jar file. > According to the backtrace, the execution of maven follows this steps : > Clean the ParentProject > Install the ParentProject > "Site" the ParentProject > and site want to compile the entire project so it compiles the Module and the > Module2. The Module2 needs the jar of Module1 to compile so the build fails. > In my opinion, the maven core should run successively clean, install and site > on the entire project like : > Clean ParentModule > Clean Module1 > Clean Module2 > Install ParentModule > Install Module1 > Install Module2 > Site ParentModule > Site Module1 > Site Module2 > So, I attached a maven.diff file too, which makes this succession. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-166) release:prepare should always check for local modifications
[ https://jira.codehaus.org/browse/MRELEASE-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MRELEASE-166: -- Fix Version/s: 2.3 targetting for 2.3 as seems like something that needs doing > release:prepare should always check for local modifications > --- > > Key: MRELEASE-166 > URL: https://jira.codehaus.org/browse/MRELEASE-166 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-4 >Reporter: Joerg Schaible >Priority: Critical > Fix For: 2.3 > > > If the first call to release:prepare fails, it does not check again for local > modifications. This is quite likely though, since the release manager might > have cleared the erroneous condition. If he forgets to check, the labe is set > to the wrong version of the files and release:perform fails. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-441) Bad pom generation when trying to prepare release for a multimodule project with some timestamp snapshot dependencies even using the parameter -DallowTimestampedSnapshot
[ https://jira.codehaus.org/browse/MRELEASE-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MRELEASE-441: -- Labels: scrub-review-started (was: ) Do you think you could please provide a test case as it will help making developing a fix easier. > Bad pom generation when trying to prepare release for a multimodule project > with some timestamp snapshot dependencies even using the parameter > -DallowTimestampedSnapshots=true > --- > > Key: MRELEASE-441 > URL: https://jira.codehaus.org/browse/MRELEASE-441 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-9 > Environment: jdk 1.6 > maven 2.1.0 >Reporter: Angel Ruiz >Priority: Critical > Labels: scrub-review-started > > I have a Maven2 multi-module project with 3 modules. There is one with a > time-stamp snapshot dependency and other two that both have the same snapshot > repository. > I execute the following command: mvn release:prepare > -DallowTimestampedSnapshots=true -DdryRun=true and everything seems to be > fine, but when I have a look to the pom.xml.tag file, I see that the first > module still maintains the time-stamp snapshot dependencies, but the plugin > has elminated the time-stamp from the dependency in the other two modules. I > reckon that this must be a bug, so maybe the DallowTimestampedSnapshots > parameter works for the first dependency and then it is lost or ignored when > generating the new pom file for the other two modules with time-stamp > dependencies. > Cheers. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-594) release:stage does not properly compute new distroManagement.site.URL or project.URLs for projects
[
https://jira.codehaus.org/browse/MSITE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272022#comment-272022
]
John Allen commented on MSITE-594:
--
Although it has been a while a quick re-reading of my original description
would indicate that the issue does lie with the release:deploy mojo as it is
directly manipulating the various URLS of the project it is trying to deploy
before calling upon another plugins to carry out their function. It is thus the
responsibility of the deploy mojo to do this properly for all required fields
for the delegated plugins to work properly
I.e. when considering if this is or isnt in the realm of the deploy plugin to
address, consider:
It works fine and as designed when not being called by release:deploy
It doesnt work when being called by release:deploy
> release:stage does not properly compute new distroManagement.site.URL or
> project.URLs for projects
> --
>
> Key: MSITE-594
> URL: https://jira.codehaus.org/browse/MSITE-594
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:stage(-deploy)
>Reporter: John Allen
>Priority: Blocker
>
> In the case where you have a multi-module project and each module has its own
> distributionManagement.site.url which is common with projects that like their
> sites to be version numbered (see example beolw) the release:stage plugin
> fails to get the project's site properly deployed. From a brief look it seems
> release:sxtage is only computing a new URL for the owning project and not all
> the child projects. What's more it looks like its changing the site
> deployment URL and not the project's corresponding project URL. This results
> in the site deployment for children going to their original pom.xml specific
> locations regardless of them being 'staged' (i.e. they're not staged, they've
> just gone live!). Nearly as bad is that all the relative links for connecting
> modules and parents and banners together are broken too, as they are based
> upoin the project.URL which hasnt been touched by the release:stage mojo.
> site:stage makes a better fist of this, basically you need to remap the
> entire URL domain (site distro and project url) to be under some other parent
> space for you to successfully stage sites (see site:stage)
> This kind of mistake has come up in the past, simply put a project can define
> all its own settings for everything so anything that makes assumptions based
> on inheritence or 'defaults' is just gonna break the system.
> Example of how sub-project's defining their own site deployemtn and project
> URL information:
> {noformat}
>
>
> dav:https://example.com/maven/sites/${mvn.repoName}/${project.groupId}/${project.artifactId}/${project.version}
>
> http://example.com/maven/sites/${mvn.repoName}/${project.groupId}/${project.artifactId}/${project.version}/
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-750) Add custom name suffix for surefire-reports (xml and txt)
[ https://jira.codehaus.org/browse/SUREFIRE-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rostislav Svoboda updated SUREFIRE-750: --- Attachment: reportNameSuffix-remake.patch Changed code, all integration tests passed. Paul, thanks for comments. > Add custom name suffix for surefire-reports (xml and txt) > - > > Key: SUREFIRE-750 > URL: https://jira.codehaus.org/browse/SUREFIRE-750 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin, xml > generation >Reporter: Rostislav Svoboda >Priority: Critical > Attachments: reportNameSuffix.patch, reportNameSuffix-remake.patch, > reportNameSuffix-tests.patch > > > Hi. > I'd to add support in surefire for custom name suffix for tests in > surefire-reports. > Motivation 1): > I have more modules, some modules are sharing tests from another using > org.codehaus.mojo:build-helper-maven-plugin. > I'd like to have txt and xml files with some differentiator to determine in > which module tests were executed. > Motivation 2): > I have defined several executions where I use different parameters and > execute the same tests in each execution. > Again, I'd like to have txt and xml files with some differentiator. > Solution: > Introduce new configuration property reportNameSuffix. > Patch for this improvement is included. > Tested: > Yes, customText added into surefire > plugin configuration and received these files: > org.xyz.test.componentA.ComponentAUnitTest-customText-output.txt > org.xyz.test.componentA.ComponentAUnitTest-customText.txt > org.xyz.test.componentB.ComponentBUnitTest-customText-output.txt > org.xyz.test.componentB.ComponentBUnitTest-customText.txt > TEST-org.xyz.test.componentA.ComponentAUnitTest-customText.xml > TEST-org.xyz.test.componentB.ComponentBUnitTest-customText.xml > Tested without defined too, original file names and > content generated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-577) release:prepare does not pass argument "--settings" with current settings.xml to inner maven
[
https://jira.codehaus.org/browse/MRELEASE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272027#comment-272027
]
Stephen Connolly commented on MRELEASE-577:
---
It is not possible to get the location of the settings.xml from within a Maven
plugin.
Embedding maven may result in there actually being no settings.xml at all, with
all the required information being provided by the embedder.
If somebody wants to take a stab at a patch for this, you would do something
like:
Add a boolean parameter to prepare and stage goals that enables the following:
* Use MavenSettingsXpp3Writer to write the ${settings} to release.settings.xml
When forking maven, if there is a release.settings.xml file have the fork use
that settings.xml
The patch will need tests.
w.r.t. password encryption, the ${settings} stores the password encrypted in
memory so serialization will still write out the encrypted password.
w.r.t. other gotcha's... you will need to ensure that release.settings.xml is
ignored in the check for modified files
> release:prepare does not pass argument "--settings" with current settings.xml
> to inner maven
>
>
> Key: MRELEASE-577
> URL: https://jira.codehaus.org/browse/MRELEASE-577
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-9, 2.0
>Reporter: Petr Kozelka
>Priority: Critical
>
> The impact is that release:prepare tries to use $HOME/.m2/settings.xml
> instead of the one supplied by --settings cmdline option, which leads to
> unexpected behavior
> Of course if it does not exist, the inhouse repository is avoided and release
> often fails due to a ResourceDoesNotExistException when an inhouse artifact
> is requested by the pom.
> To reproduce this problem, just rename your ~/.m2/settings.xml to ~/.m2/s.xml
> and run this:
> mvn --settings=$HOME/.m2/s.xml release:prepare .
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRELEASE-577) release:prepare does not pass argument "--settings" with current settings.xml to inner maven
[
https://jira.codehaus.org/browse/MRELEASE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272027#comment-272027
]
Stephen Connolly edited comment on MRELEASE-577 at 7/1/11 6:23 AM:
---
It is not possible to get the location of the settings.xml from within a Maven
plugin.
Embedding maven may result in there actually being no settings.xml at all, with
all the required information being provided by the embedder.
If somebody wants to take a stab at a patch for this, you would do something
like:
* Add a boolean parameter to prepare and stage goals that enables the following:
** Use MavenSettingsXpp3Writer to write the ${settings} to release.settings.xml
* When forking maven, if there is a release.settings.xml file have the fork use
that settings.xml
* The patch will need tests.
* w.r.t. password encryption, the ${settings} stores the password encrypted in
memory so serialization will still write out the encrypted password.
* w.r.t. other gotcha's... you will need to ensure that release.settings.xml is
ignored in the check for modified files
was (Author: stephenconnolly):
It is not possible to get the location of the settings.xml from within a
Maven plugin.
Embedding maven may result in there actually being no settings.xml at all, with
all the required information being provided by the embedder.
If somebody wants to take a stab at a patch for this, you would do something
like:
* Add a boolean parameter to prepare and stage goals that enables the
following:
** Use MavenSettingsXpp3Writer to write the ${settings} to release.settings.xml
* When forking maven, if there is a release.settings.xml file have the fork
use that settings.xml
* The patch will need tests.
* w.r.t. password encryption, the ${settings} stores the password encrypted in
memory so serialization will still write out the encrypted password.
* w.r.t. other gotcha's... you will need to ensure that release.settings.xml
is ignored in the check for modified files
> release:prepare does not pass argument "--settings" with current settings.xml
> to inner maven
>
>
> Key: MRELEASE-577
> URL: https://jira.codehaus.org/browse/MRELEASE-577
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-9, 2.0
>Reporter: Petr Kozelka
>Priority: Critical
>
> The impact is that release:prepare tries to use $HOME/.m2/settings.xml
> instead of the one supplied by --settings cmdline option, which leads to
> unexpected behavior
> Of course if it does not exist, the inhouse repository is avoided and release
> often fails due to a ResourceDoesNotExistException when an inhouse artifact
> is requested by the pom.
> To reproduce this problem, just rename your ~/.m2/settings.xml to ~/.m2/s.xml
> and run this:
> mvn --settings=$HOME/.m2/s.xml release:prepare .
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRELEASE-577) release:prepare does not pass argument "--settings" with current settings.xml to inner maven
[
https://jira.codehaus.org/browse/MRELEASE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272027#comment-272027
]
Stephen Connolly edited comment on MRELEASE-577 at 7/1/11 6:23 AM:
---
It is not possible to get the location of the settings.xml from within a Maven
plugin.
Embedding maven may result in there actually being no settings.xml at all, with
all the required information being provided by the embedder.
If somebody wants to take a stab at a patch for this, you would do something
like:
* Add a boolean parameter to prepare and stage goals that enables the
following:
** Use MavenSettingsXpp3Writer to write the ${settings} to release.settings.xml
* When forking maven, if there is a release.settings.xml file have the fork
use that settings.xml
* The patch will need tests.
* w.r.t. password encryption, the ${settings} stores the password encrypted in
memory so serialization will still write out the encrypted password.
* w.r.t. other gotcha's... you will need to ensure that release.settings.xml
is ignored in the check for modified files
was (Author: stephenconnolly):
It is not possible to get the location of the settings.xml from within a
Maven plugin.
Embedding maven may result in there actually being no settings.xml at all, with
all the required information being provided by the embedder.
If somebody wants to take a stab at a patch for this, you would do something
like:
Add a boolean parameter to prepare and stage goals that enables the following:
* Use MavenSettingsXpp3Writer to write the ${settings} to release.settings.xml
[]
When forking maven, if there is a release.settings.xml file have the fork use
that settings.xml
The patch will need tests.
w.r.t. password encryption, the ${settings} stores the password encrypted in
memory so serialization will still write out the encrypted password.
w.r.t. other gotcha's... you will need to ensure that release.settings.xml is
ignored in the check for modified files
> release:prepare does not pass argument "--settings" with current settings.xml
> to inner maven
>
>
> Key: MRELEASE-577
> URL: https://jira.codehaus.org/browse/MRELEASE-577
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-9, 2.0
>Reporter: Petr Kozelka
>Priority: Critical
>
> The impact is that release:prepare tries to use $HOME/.m2/settings.xml
> instead of the one supplied by --settings cmdline option, which leads to
> unexpected behavior
> Of course if it does not exist, the inhouse repository is avoided and release
> often fails due to a ResourceDoesNotExistException when an inhouse artifact
> is requested by the pom.
> To reproduce this problem, just rename your ~/.m2/settings.xml to ~/.m2/s.xml
> and run this:
> mvn --settings=$HOME/.m2/s.xml release:prepare .
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRELEASE-577) release:prepare does not pass argument "--settings" with current settings.xml to inner maven
[
https://jira.codehaus.org/browse/MRELEASE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272027#comment-272027
]
Stephen Connolly edited comment on MRELEASE-577 at 7/1/11 6:21 AM:
---
It is not possible to get the location of the settings.xml from within a Maven
plugin.
Embedding maven may result in there actually being no settings.xml at all, with
all the required information being provided by the embedder.
If somebody wants to take a stab at a patch for this, you would do something
like:
Add a boolean parameter to prepare and stage goals that enables the following:
* Use MavenSettingsXpp3Writer to write the ${settings} to release.settings.xml
[]
When forking maven, if there is a release.settings.xml file have the fork use
that settings.xml
The patch will need tests.
w.r.t. password encryption, the ${settings} stores the password encrypted in
memory so serialization will still write out the encrypted password.
w.r.t. other gotcha's... you will need to ensure that release.settings.xml is
ignored in the check for modified files
was (Author: stephenconnolly):
It is not possible to get the location of the settings.xml from within a
Maven plugin.
Embedding maven may result in there actually being no settings.xml at all, with
all the required information being provided by the embedder.
If somebody wants to take a stab at a patch for this, you would do something
like:
Add a boolean parameter to prepare and stage goals that enables the following:
* Use MavenSettingsXpp3Writer to write the ${settings} to release.settings.xml
When forking maven, if there is a release.settings.xml file have the fork use
that settings.xml
The patch will need tests.
w.r.t. password encryption, the ${settings} stores the password encrypted in
memory so serialization will still write out the encrypted password.
w.r.t. other gotcha's... you will need to ensure that release.settings.xml is
ignored in the check for modified files
> release:prepare does not pass argument "--settings" with current settings.xml
> to inner maven
>
>
> Key: MRELEASE-577
> URL: https://jira.codehaus.org/browse/MRELEASE-577
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-9, 2.0
>Reporter: Petr Kozelka
>Priority: Critical
>
> The impact is that release:prepare tries to use $HOME/.m2/settings.xml
> instead of the one supplied by --settings cmdline option, which leads to
> unexpected behavior
> Of course if it does not exist, the inhouse repository is avoided and release
> often fails due to a ResourceDoesNotExistException when an inhouse artifact
> is requested by the pom.
> To reproduce this problem, just rename your ~/.m2/settings.xml to ~/.m2/s.xml
> and run this:
> mvn --settings=$HOME/.m2/s.xml release:prepare .
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-577) release:prepare does not pass argument "--settings" with current settings.xml to inner maven
[ https://jira.codehaus.org/browse/MRELEASE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MRELEASE-577: -- Labels: contributers-welcome (was: ) > release:prepare does not pass argument "--settings" with current settings.xml > to inner maven > > > Key: MRELEASE-577 > URL: https://jira.codehaus.org/browse/MRELEASE-577 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-9, 2.0 >Reporter: Petr Kozelka >Priority: Critical > Labels: contributers-welcome > > The impact is that release:prepare tries to use $HOME/.m2/settings.xml > instead of the one supplied by --settings cmdline option, which leads to > unexpected behavior > Of course if it does not exist, the inhouse repository is avoided and release > often fails due to a ResourceDoesNotExistException when an inhouse artifact > is requested by the pom. > To reproduce this problem, just rename your ~/.m2/settings.xml to ~/.m2/s.xml > and run this: > mvn --settings=$HOME/.m2/s.xml release:prepare . -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRELEASE-577) release:prepare does not pass argument "--settings" with current settings.xml to inner maven
[
https://jira.codehaus.org/browse/MRELEASE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272027#comment-272027
]
Stephen Connolly edited comment on MRELEASE-577 at 7/1/11 6:31 AM:
---
It is not possible to get the location of the settings.xml from within a Maven
plugin.
Embedding maven may result in there actually being no settings.xml at all, with
all the required information being provided by the embedder.
If somebody wants to take a stab at a patch for this, you would do something
like:
* Add a boolean parameter to prepare and stage goals that enables the
following:
** Use {{MavenSettingsXpp3Writer}} to write the {{$\{settings}}} to
{{release.settings.xml}}.
* When forking maven, if there is a {{release.settings.xml}} file have the fork
use that {{settings.xml}}.
* The patch will need tests.
* w.r.t. password encryption, the {{$\{settings}}} stores the password
encrypted in memory so serialization will still write out the encrypted
password.
- w.r.t. other gotcha's... you will need to ensure that
{{release.settings.xml}} is ignored in the check for modified files.
was (Author: stephenconnolly):
It is not possible to get the location of the settings.xml from within a
Maven plugin.
Embedding maven may result in there actually being no settings.xml at all, with
all the required information being provided by the embedder.
If somebody wants to take a stab at a patch for this, you would do something
like:
* Add a boolean parameter to prepare and stage goals that enables the following:
** Use MavenSettingsXpp3Writer to write the ${settings} to release.settings.xml
* When forking maven, if there is a release.settings.xml file have the fork use
that settings.xml
* The patch will need tests.
* w.r.t. password encryption, the ${settings} stores the password encrypted in
memory so serialization will still write out the encrypted password.
* w.r.t. other gotcha's... you will need to ensure that release.settings.xml is
ignored in the check for modified files
> release:prepare does not pass argument "--settings" with current settings.xml
> to inner maven
>
>
> Key: MRELEASE-577
> URL: https://jira.codehaus.org/browse/MRELEASE-577
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-9, 2.0
>Reporter: Petr Kozelka
>Priority: Critical
> Labels: contributers-welcome
>
> The impact is that release:prepare tries to use $HOME/.m2/settings.xml
> instead of the one supplied by --settings cmdline option, which leads to
> unexpected behavior
> Of course if it does not exist, the inhouse repository is avoided and release
> often fails due to a ResourceDoesNotExistException when an inhouse artifact
> is requested by the pom.
> To reproduce this problem, just rename your ~/.m2/settings.xml to ~/.m2/s.xml
> and run this:
> mvn --settings=$HOME/.m2/s.xml release:prepare .
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-545) When Using a Custom Settings XML File (with the -s option) release:prepare Does Not Read Proper Credentials
[ https://jira.codehaus.org/browse/MRELEASE-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MRELEASE-545. - Resolution: Duplicate Closing this in favour of MRELEASE-577 as that has the suggestions for how to patch > When Using a Custom Settings XML File (with the -s option) release:prepare > Does Not Read Proper Credentials > --- > > Key: MRELEASE-545 > URL: https://jira.codehaus.org/browse/MRELEASE-545 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: perform >Affects Versions: 2.0 >Reporter: Tim O'Brien > > Here's the "situation": > 1. You have multiple Maven Settings files because you are dealing with > different environments. Assume you have: >~/.m2/envA-settings.xml >~/.m2/envB-settings.xml > 2. Your build deploys to a repository manager with a server id of "nexus". > > 3. ~/m2/envA-settings.xml contains the server credentials for the server with > an id of "nexus" > Problem: > Running the following command: >mvn -s ~/.m2/envA-settings.xml release:perform > After a successful prepare, gets a 401 error because the release:perform goal > is not picking up the credentials from ~/.m2/envA-settings.xml. > The work-around to this problem is to move ~/.m2/envA-settings.xml to > ~/.m2/settings.xml.For some reason the perform goal only works for me > when I am using the default location for Maven Settings XML. It seems > like the release:perform should honor the custom location of a Maven Settings > file. > This quirk ate my day. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-521) release:perform does not take the settings specified by the -s option
[ https://jira.codehaus.org/browse/MRELEASE-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MRELEASE-521. - Resolution: Duplicate Closing this in favour of MRELEASE-577 as that has the suggestions for how to fix > release:perform does not take the settings specified by the -s option > -- > > Key: MRELEASE-521 > URL: https://jira.codehaus.org/browse/MRELEASE-521 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: perform >Affects Versions: 2.0-beta-7 >Reporter: Kay Kay > > # mvn -s release:perform > does not take the settings. > If we copy the same to - ~/.m2/settings.xml > # mvn release:perform > works fine. > Something does not add up. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-577) release:prepare does not pass argument "--settings" with current settings.xml to inner maven
[ https://jira.codehaus.org/browse/MRELEASE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MRELEASE-577: -- Fix Version/s: Backlog > release:prepare does not pass argument "--settings" with current settings.xml > to inner maven > > > Key: MRELEASE-577 > URL: https://jira.codehaus.org/browse/MRELEASE-577 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-9, 2.0 >Reporter: Petr Kozelka >Priority: Critical > Labels: contributers-welcome > Fix For: Backlog > > > The impact is that release:prepare tries to use $HOME/.m2/settings.xml > instead of the one supplied by --settings cmdline option, which leads to > unexpected behavior > Of course if it does not exist, the inhouse repository is avoided and release > often fails due to a ResourceDoesNotExistException when an inhouse artifact > is requested by the pom. > To reproduce this problem, just rename your ~/.m2/settings.xml to ~/.m2/s.xml > and run this: > mvn --settings=$HOME/.m2/s.xml release:prepare . -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-499) Add to FAQ: prepare fails because of inheriting parent scm
[
https://jira.codehaus.org/browse/MRELEASE-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly closed MRELEASE-499.
-
Resolution: Fixed
Fix Version/s: 2.3
Assignee: Stephen Connolly
r1141907
> Add to FAQ: prepare fails because of inheriting parent scm
> --
>
> Key: MRELEASE-499
> URL: https://jira.codehaus.org/browse/MRELEASE-499
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: documentation, prepare
>Reporter: Robert Scholte
>Assignee: Stephen Connolly
> Fix For: 2.3
>
>
> If the pom.xml has no scm-section but his parent does, the prepare will fail
> when trying to tag.
> The message will be something like:
> {quote}svn: Path
> 'https://svn.codehaus.org/mojo/tags/mojo-parent-22/my-maven-plugin' does not
> exist in revision 12345{quote}
> To fix it, add the scm-section to the pom, restore the version (-SNAPSHOT)
> and execute {{mvn release:clean}}
> Than we're ready to run another {{mvn:prepare}}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-123) release plugin does not take commandline parameters into account
[ https://jira.codehaus.org/browse/MRELEASE-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272033#comment-272033 ] Stephen Connolly commented on MRELEASE-123: --- One could also argue that with Maven 3.0.x's reactor mode any -pl should be passed through also > release plugin does not take commandline parameters into account > > > Key: MRELEASE-123 > URL: https://jira.codehaus.org/browse/MRELEASE-123 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-4 >Reporter: Jorg Heymans > > i would like to do a release of a top-level pom only : intuitively i do "mvn > -N release:prepare". During release preparation the -N parameter is left out > however and maven does a full integration on all child modules and > subsequently includes them in the release process. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRELEASE-123) release plugin does not take commandline parameters into account
[
https://jira.codehaus.org/browse/MRELEASE-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272033#comment-272033
]
Stephen Connolly edited comment on MRELEASE-123 at 7/1/11 6:52 AM:
---
One could also argue that with Maven 3.0.x's reactor mode any -pl should be
passed through also. In which case the desire is to release the
{{$\{reactorProjects}}}... that might make the fix for 3.0.x+ easier but not
sure how you'd implement for 2.x
was (Author: stephenconnolly):
One could also argue that with Maven 3.0.x's reactor mode any -pl should be
passed through also
> release plugin does not take commandline parameters into account
>
>
> Key: MRELEASE-123
> URL: https://jira.codehaus.org/browse/MRELEASE-123
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-4
>Reporter: Jorg Heymans
>
> i would like to do a release of a top-level pom only : intuitively i do "mvn
> -N release:prepare". During release preparation the -N parameter is left out
> however and maven does a full integration on all child modules and
> subsequently includes them in the release process.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-328) Goal descriptions don't give enough information
[ https://jira.codehaus.org/browse/MRELEASE-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MRELEASE-328. - Resolution: Fixed http://maven.apache.org/plugins/maven-release-plugin/plugin-info.html seems fairly detailed to me > Goal descriptions don't give enough information > --- > > Key: MRELEASE-328 > URL: https://jira.codehaus.org/browse/MRELEASE-328 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-7 > Environment: > http://maven.apache.org/plugins/maven-release-plugin/plugin-info.html >Reporter: SebbASF > > The goal descriptions mostly don't give enough information on what the goal > actually does. > For example, what do release:perform and release:prepare actually do? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-170) Create a branch during prepare
[ https://jira.codehaus.org/browse/MRELEASE-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MRELEASE-170. - Resolution: Fixed Fix Version/s: 2.2 I am going to claim that this is fixed in 2.2 Please re-open if it is not actually fixed ;-) Here is my claim: Use http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#completionGoals to run release:branch with http://maven.apache.org/plugins/maven-release-plugin/branch-mojo.html#updateWorkingCopyVersions=false and http://maven.apache.org/plugins/maven-release-plugin/branch-mojo.html#updateBranchVersions=true configured in your pom. > Create a branch during prepare > -- > > Key: MRELEASE-170 > URL: https://jira.codehaus.org/browse/MRELEASE-170 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Components: scm >Reporter: Jonathan Komorek >Priority: Minor > Fix For: 2.2 > > > It is typical with some of my projects that as I'm cutting the release I am > already thinking about the next patch. In other words, creating a branch to > allow patching of a release is a part of my release process. > I would like a way to create a branch during the prepare goal of a release. > For instance, if I'm releasing 4.0-SNAPSHOT I would like to create a 4.0 tag > as is currently done, but also a 4.0.1-SNAPSHOT branch. > Please note that I have recently migrated from CVS / ANT to SVN / Maven so > I'm open to alternatives from someone with more experience on these > platforms. Although I have not written any code for a Maven plugin > previously, I would be willing to make these additions myself if nobody minds > and I can get someone to review my code - the experience would help me better > understand Maven and this plugin in particular. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-315) Prepare goal - set default values
[ https://jira.codehaus.org/browse/MRELEASE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MRELEASE-315. - Resolution: Fixed Should be able to use http://mojo.codehaus.org/versions-maven-plugin/use-releases-mojo.html in the preparationGoals or else just run versions:use-releases scm:commit (you need to commit to not have prepare complain about modified files, and you need a separate execution as maven does not re-read the pom during an execution) > Prepare goal - set default values > --- > > Key: MRELEASE-315 > URL: https://jira.codehaus.org/browse/MRELEASE-315 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare >Affects Versions: 2.0-beta-8 >Reporter: Alessandro Zucchi > > Hi all, > I'm trying to simplify the release process of my project. > I run the following command: > call mvn -DpreparationGoals=clean,install -DautoVersionSubmodules=true > release:clean release:prepare > Since my project have dependences against other projects (SNAPSHOT > dependeces) I get the following question: > "There are still some remaining snapshot dependencies.: Do you want to > resolve them now? (yes/no) no:" > I have to answer yes to change the default and from this point over > accept all defaults prompted. > The question is: > can I change, in same way, the above default so I can use --batch-mode ??? > Consider that I can't change manuallly the dependences before to start the > release prepare process. > Best regards. > Alex -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-106) Remember the Dry Run Status
[ https://jira.codehaus.org/browse/MRELEASE-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MRELEASE-106: -- Fix Version/s: Backlog Labels: contributers-welcome (was: ) Seems like a good idea. If somebody wants to contribute a patch to add dryRun to the release descriptor > Remember the Dry Run Status > --- > > Key: MRELEASE-106 > URL: https://jira.codehaus.org/browse/MRELEASE-106 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare >Affects Versions: 2.0-beta-4 > Environment: Release plugin snapshot 20060509.101136-3, Subversion >Reporter: Bob Allison >Priority: Minor > Labels: contributers-welcome > Fix For: Backlog > > > When doing a dry run of a release, make note of that in the > release.properties file so that a reasonable "failure" can occur if the user > tries to perform the release. Also, this flag might be used to allow a > non-dry-run prepare to occur without needing to do a clean in between (maybe > also not need to prompt but reuse the same answers as in the dry run). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-269) Check that 'new development version' is a SNAPSHOT version
[ https://jira.codehaus.org/browse/MRELEASE-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MRELEASE-269: -- Fix Version/s: Backlog Labels: contributers-welcome (was: ) Anyone want to take a stab at a patch? > Check that 'new development version' is a SNAPSHOT version > --- > > Key: MRELEASE-269 > URL: https://jira.codehaus.org/browse/MRELEASE-269 > Project: Maven 2.x Release Plugin > Issue Type: Wish > Components: prepare >Affects Versions: 2.0-beta-6 >Reporter: Michael Meyer >Priority: Trivial > Labels: contributers-welcome > Fix For: Backlog > > > While executing 'mvn release:prepare' one gets asked for the new development > version like this: > What is the new development version for "foo"? (com.bar:foo) 1.12-SNAPSHOT: > Say I want the new development version to be 2.0-SNAPSHOT (and not like > suggested 1.12-SNAPSHOT) but by accident I only enter 2.0. This will work > just fine until I want to execute 'mvn release:prepare' again at some later > point. Then I will get the error message that the current version is not a > SNAPSHOT version. > It would be really nice if release:prepare could check if I have entered a > valid SNAPSHOT version. If not release:prepare should fail or even nicer ask > me to enter a proper SNAPSHOT version. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-373) Unable to do a release with release plug-in
[ https://jira.codehaus.org/browse/MRELEASE-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MRELEASE-373: -- Labels: scrub-review-started (was: ) Is this still unresolved? > Unable to do a release with release plug-in > --- > > Key: MRELEASE-373 > URL: https://jira.codehaus.org/browse/MRELEASE-373 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare > Environment: Windows XP SP2, Maven 2.0.7, JDK 1.5.0_10 >Reporter: Pascal ST LAURENT > Labels: scrub-review-started > > When I try to do a release, I call the following statement : mvn > release:prepare. I received this exception, maybe caused by path too long in > the project... > [ERROR] FATAL ERROR > [INFO] > > [INFO] 60 > [INFO] > > [INFO] Trace > java.lang.ArrayIndexOutOfBoundsException: 60 > at > org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.translateUrlPath(RewritePomsForReleasePhase.java:249) > at > org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.translateScm(RewritePomsForReleasePhase.java:124) > at > org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.transformScm(RewritePomsForReleasePhase.java:61) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformDocument(AbstractRewritePomsPhase.java:271) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:180) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:116) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execute(AbstractRewritePomsPhase.java:99) > at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) > at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131) > at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94) > at > org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:127) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) > 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:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-206) its not possible to pass MAVEN_OPTS to the forked release build
[ https://jira.codehaus.org/browse/MRELEASE-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MRELEASE-206: -- Fix Version/s: Backlog Labels: contributers-welcome (was: ) Before running off and writing a patch, check back with dev@m.a.o on how you would plan to write a patch for this > its not possible to pass MAVEN_OPTS to the forked release build > --- > > Key: MRELEASE-206 > URL: https://jira.codehaus.org/browse/MRELEASE-206 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-3, 2.0-beta-4 >Reporter: Brian Fox > Labels: contributers-welcome > Fix For: Backlog > > > I need to increase my jvm size for my build. The forked release doesn't get > the maven_opts. I tried the -Darguments: > mvn release:prepare -DdryRun=true -Darguments=-Xmx1024m > gets me this: >[INFO] Invalid task 'mx1024m': you must specify a valid lifecycle phase, > or > a goal in the format plugin:goal or > pluginGroupId:pluginArtifactId:pluginVersion > :goal -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-239) release:perform and release:prepare should accept multi-line goals/preparationGoals configurations
[ https://jira.codehaus.org/browse/MRELEASE-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MRELEASE-239. - Resolution: Fixed Fix Version/s: 2.3 r1141912 > release:perform and release:prepare should accept multi-line > goals/preparationGoals configurations > -- > > Key: MRELEASE-239 > URL: https://jira.codehaus.org/browse/MRELEASE-239 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare >Affects Versions: 2.0-beta-6 >Reporter: Steve Rowe >Priority: Minor > Fix For: 2.3 > > Attachments: ForkedMavenExecutor.patch > > > When I specify a list of goals in my POM that span multiple lines (see an > example below), only those goals before the newline are executed when I run > "mvn release:perform". > I have only noticed this for release:perform, but given what the code looks > like, I assume it's an issue for release:prepare too. > This is a minor problem, but an irritating one, because release:peform claims > to successfully complete without actually executing all specified goals. > I attach a patch to ForkedMavenExecutor.java that splits the goals list on > newlines and carriage returns, in addition to the comma and space split > characters that were there already. > Here's an example configuration that will trigger the problem: > > maven-release-plugin > > ... > > package group:first-goal group:second-goal group:third-goal > site-deploy changes:announcement-generate > changes:announcement-mail > > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSHADE-88) Pom type dependencies are incorrectly included in dependency reduced pom
[ https://jira.codehaus.org/browse/MSHADE-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272051#comment-272051 ] ant elder commented on MSHADE-88: - No, i didn't know about the run-its profile. Ok the reason the dep-reduced-pom test fails is because its not testing with promoteTransitiveDependencies set to true. Adding the line true to the its shade plugin configuration gets the test working. I'm not familiar enough with the integration tests to know if its ok to make that change to the dep-reduced-pom or if there needs to be a new test created for this. > Pom type dependencies are incorrectly included in dependency reduced pom > > > Key: MSHADE-88 > URL: https://jira.codehaus.org/browse/MSHADE-88 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 1.4 >Reporter: ant elder >Assignee: Benson Margulies > Attachments: drpFix.txt, MSHADE-88-2.patch > > > When shading with promoteTransitiveDependencies and > createDependencyReducedPom set to true and using dependencies with a type of > pom then the dependency reduced pom still includes the pom type dependencies, > this is incorrect because the dependencies of the pom type dependency have > already been included in the shaded artifact. > The attached patch (based on trunk) fixes this by not including pom type > dependencies to the dependency reduced pom. There are no existing tests for > dependency reduced pom's or with pom type dependencies but this patch code > does match what is already done for pom type dependencies in the ShadeMojo > execute method at line 409. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-656) JUnit 4.8 @Category support
[
https://jira.codehaus.org/browse/SUREFIRE-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272054#comment-272054
]
KP commented on SUREFIRE-656:
-
@Kristian Rosenvold: At least basic support would be really nice, so thank you!
> JUnit 4.8 @Category support
> ---
>
> Key: SUREFIRE-656
> URL: https://jira.codehaus.org/browse/SUREFIRE-656
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Junit 4.x support
>Affects Versions: 2.7
> Environment: any
>Reporter: KP
>
> I am interested in adding JUnit's {{@Category}} support. TestNG already has
> group support in Surefire, so this would be a nice addition.
> I'm wondering if someone could point me in the right direction.
> Unfortunately, I'm not familiar with the Surefire source code.
> 1. Do I need to add another provider or something?
> 1. Should I just subclass {{SurefireTestSuite}} in the same manner as
> {{JUnitCoreDirectoryTestSuite}}?
> 1. Should I model
> Any help would be greatly appreciated. I have some free time and I'd love to
> submit a patch this week.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSHADE-88) Pom type dependencies are incorrectly included in dependency reduced pom
[ https://jira.codehaus.org/browse/MSHADE-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272055#comment-272055 ] Benson Margulies commented on MSHADE-88: OK, now we're even. I'll add that, it's fine for this test. > Pom type dependencies are incorrectly included in dependency reduced pom > > > Key: MSHADE-88 > URL: https://jira.codehaus.org/browse/MSHADE-88 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 1.4 >Reporter: ant elder >Assignee: Benson Margulies > Attachments: drpFix.txt, MSHADE-88-2.patch > > > When shading with promoteTransitiveDependencies and > createDependencyReducedPom set to true and using dependencies with a type of > pom then the dependency reduced pom still includes the pom type dependencies, > this is incorrect because the dependencies of the pom type dependency have > already been included in the shaded artifact. > The attached patch (based on trunk) fixes this by not including pom type > dependencies to the dependency reduced pom. There are no existing tests for > dependency reduced pom's or with pom type dependencies but this patch code > does match what is already done for pom type dependencies in the ShadeMojo > execute method at line 409. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSHADE-88) Pom type dependencies are incorrectly included in dependency reduced pom
[ https://jira.codehaus.org/browse/MSHADE-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MSHADE-88. -- Resolution: Fixed Fix Version/s: 1.5 r1141937 | bimargulies | 2011-07-01 09:50:47 -0400 (Fri, 01 Jul 2011) | 3 lines [MSHADE-88]: antelder: fix an interaction between 'createDependencyReducedPom' and 'promoteTransitiveDependencies'. also integration test. Also update to current parent. /Users/benson/asf/mvn/plugins/maven-shade-plugin > Pom type dependencies are incorrectly included in dependency reduced pom > > > Key: MSHADE-88 > URL: https://jira.codehaus.org/browse/MSHADE-88 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 1.4 >Reporter: ant elder >Assignee: Benson Margulies > Fix For: 1.5 > > Attachments: drpFix.txt, MSHADE-88-2.patch > > > When shading with promoteTransitiveDependencies and > createDependencyReducedPom set to true and using dependencies with a type of > pom then the dependency reduced pom still includes the pom type dependencies, > this is incorrect because the dependencies of the pom type dependency have > already been included in the shaded artifact. > The attached patch (based on trunk) fixes this by not including pom type > dependencies to the dependency reduced pom. There are no existing tests for > dependency reduced pom's or with pom type dependencies but this patch code > does match what is already done for pom type dependencies in the ShadeMojo > execute method at line 409. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSHADE-100) [DOCS] Describe Available Resource Transformers
[DOCS] Describe Available Resource Transformers --- Key: MSHADE-100 URL: https://jira.codehaus.org/browse/MSHADE-100 Project: Maven 2.x Shade Plugin Issue Type: Improvement Affects Versions: 1.5 Reporter: Robert Burrell Donkin Attachments: describe-resource-descriptors.patch maven-shade-plugin includes many useful ResourceTransformer implementations. This patch add descriptions for everyone that worked well for me (expect patches with test cases later). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-295) Provide more debug information in wagon (http request/response/headers)
[ https://jira.codehaus.org/browse/WAGON-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272075#comment-272075 ] Chris Dolan commented on WAGON-295: --- In my opinion, the biggest bang-for-buck would be to enhance LightweightHttpWagon.finishPutTransfer() to append the getErrorStream() body to the thrown TransferFailedException in some manner and also to make sure that the TransferListener implementation pulls that message out in debug mode. That would allow the Wagon to remain ignorant of the debug on/off setting. But it would either require 1) an unwieldy exception message, 2) an API change for TransferFailedException or 3) a change/extension to the TransferListener API > Provide more debug information in wagon (http request/response/headers) > --- > > Key: WAGON-295 > URL: https://jira.codehaus.org/browse/WAGON-295 > Project: Maven Wagon > Issue Type: Improvement >Reporter: Olivier Lamy > Fix For: 1.0-beta-8 > > > Is there any way to have more debug information concerning wagon with the > option -e -X ? > Like commons-httpclient does : > - http requests > - http response > - http headers > Thanks, > - Olivier -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSHADE-100) [DOCS] Describe Available Resource Transformers
[ https://jira.codehaus.org/browse/MSHADE-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MSHADE-100. --- Resolution: Fixed Fix Version/s: 1.5 r1142008 | bimargulies | 2011-07-01 13:49:31 -0400 (Fri, 01 Jul 2011) | 2 lines [MSHADE-100]: (Robert Burrell Donkin): add documentation on the provided transformer classes. > [DOCS] Describe Available Resource Transformers > --- > > Key: MSHADE-100 > URL: https://jira.codehaus.org/browse/MSHADE-100 > Project: Maven 2.x Shade Plugin > Issue Type: Improvement >Affects Versions: 1.5 >Reporter: Robert Burrell Donkin >Assignee: Benson Margulies > Fix For: 1.5 > > Attachments: describe-resource-descriptors.patch > > > maven-shade-plugin includes many useful ResourceTransformer implementations. > This patch add descriptions for everyone that worked well for me (expect > patches with test cases later). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DOXIA-435) Linking in generated PDF (pdflatex) does not work correctly
Linking in generated PDF (pdflatex) does not work correctly
---
Key: DOXIA-435
URL: https://jira.codehaus.org/browse/DOXIA-435
Project: Maven Doxia
Issue Type: Bug
Components: Module - Latex
Reporter: Karl Heinz Marbaise
I have serveral .apt documentation files from which i can create a site which
is perfectly linked.
I use code like the following to link to other areas of the site:
{code}
{{{./it-example.html}Integration test example}}
{code}
The problem i found is that if i compile the generated .tex files via pdflatex
into a PDF file the links in the PDF don't work. They links like the above
always link to the first page of the PDF.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-435) Linking in generated PDF (pdflatex) does not work correctly
[
https://jira.codehaus.org/browse/DOXIA-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272085#comment-272085
]
Karl Heinz Marbaise commented on DOXIA-435:
---
What i missed that i got warnings during the pdflatex generation:
{code}
Underfull \vbox (badness 1) has occurred while \output is active [25]
[26]) (./mp-it-example.tex [27] [28] [29]) [30] (./maui-guide.aux) )
(see the transcript file for additional information)pdfTeX warning (dest): name
{./mp-it-source-example.html} has been referenced but does not exist, replaced
by a fixed one
pdfTeX warning (dest): name{./mp-it-example.html} has been referenced but does
not exist, replaced by a fixed one
pdfTeX warning (dest): name{./it-example-1.html} has been referenced but does n
ot exist, replaced by a fixed one
pdfTeX warning (dest): name{./it-example.html} has been referenced but does not
exist, replaced by a fixed one
pdfTeX warning (dest): name{./examples.html} has been referenced but does not e
xist, replaced by a fixed one
pdfTeX warning (dest): name{./ut-example-mu.html} has been referenced but does
not exist, replaced by a fixed one
pdfTeX warning (dest): name{./ut-example.html} has been referenced but does not
exist, replaced by a fixed one
pdfTeX warning (dest): name{./overview-mp-it.html} has been referenced but does
not exist, replaced by a fixed one
pdfTeX warning (dest): name{./overview-integration-test.html} has been referenc
ed but does not exist, replaced by a fixed one
pdfTeX warning (dest): name{./overview-unit-test.html} has been referenced but
does not exist, replaced by a fixed one
{/usr/share/texmf-texlive/fonts/enc/dvips/base/8r.enc}
Output written on maui-guide.pdf (30 pages, 157369 bytes).
{code}
> Linking in generated PDF (pdflatex) does not work correctly
> ---
>
> Key: DOXIA-435
> URL: https://jira.codehaus.org/browse/DOXIA-435
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Latex
>Reporter: Karl Heinz Marbaise
>
> I have serveral .apt documentation files from which i can create a site which
> is perfectly linked.
> I use code like the following to link to other areas of the site:
> {code}
> {{{./it-example.html}Integration test example}}
> {code}
> The problem i found is that if i compile the generated .tex files via
> pdflatex into a PDF file the links in the PDF don't work. They links like the
> above always link to the first page of the PDF.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-656) JUnit 4.8 @Category support
[
https://jira.codehaus.org/browse/SUREFIRE-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272088#comment-272088
]
Kristian Rosenvold commented on SUREFIRE-656:
-
@KP Trust me, I want this too ;) I spent a few days of coding sessions trying
to get this fixed. I generally find that when I'm not happy after that amount
of time, I need to /think/ more. But I don't want a solution that just leads to
30 new issues being filed here.
> JUnit 4.8 @Category support
> ---
>
> Key: SUREFIRE-656
> URL: https://jira.codehaus.org/browse/SUREFIRE-656
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Junit 4.x support
>Affects Versions: 2.7
> Environment: any
>Reporter: KP
>
> I am interested in adding JUnit's {{@Category}} support. TestNG already has
> group support in Surefire, so this would be a nice addition.
> I'm wondering if someone could point me in the right direction.
> Unfortunately, I'm not familiar with the Surefire source code.
> 1. Do I need to add another provider or something?
> 1. Should I just subclass {{SurefireTestSuite}} in the same manner as
> {{JUnitCoreDirectoryTestSuite}}?
> 1. Should I model
> Any help would be greatly appreciated. I have some free time and I'd love to
> submit a patch this week.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-571) When collecting active profiles, the active profiles from parent poms are not considered
[ https://jira.codehaus.org/browse/MRELEASE-571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272101#comment-272101 ] Eugen Paraschiv commented on MRELEASE-571: -- Does this account for: http://stackoverflow.com/questions/3987983/maven-release-plugin-with-profile-dependent-submodules ? Thanks. > When collecting active profiles, the active profiles from parent poms are not > considered > > > Key: MRELEASE-571 > URL: https://jira.codehaus.org/browse/MRELEASE-571 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: perform, prepare >Affects Versions: 2.0 >Reporter: Lars Corneliussen > Fix For: 2.3 > > Attachments: 89d9799a56d46d7435d08c94ca538845d7145c9b[1].patch, > MRELEASE-571-collect-profiles.patch, profile-ignored-with-module.zip > > > MavenProject.getActiveProfiles() does not return all profiles that are > currently run, but instead only those that are run AND defined on the current > project. > This leads to preparation-builds of modules without the specified active > profiles derived from their parents. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRELEASE-571) When collecting active profiles, the active profiles from parent poms are not considered
[ https://jira.codehaus.org/browse/MRELEASE-571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272101#comment-272101 ] Eugen Paraschiv edited comment on MRELEASE-571 at 7/1/11 5:19 PM: -- Does this account for: http://stackoverflow.com/questions/3987983/maven-release-plugin-with-profile-dependent-submodules ? If it does not, then I can file a bug for that problem. Thanks. was (Author: eugenparaschiv): Does this account for: http://stackoverflow.com/questions/3987983/maven-release-plugin-with-profile-dependent-submodules ? Thanks. > When collecting active profiles, the active profiles from parent poms are not > considered > > > Key: MRELEASE-571 > URL: https://jira.codehaus.org/browse/MRELEASE-571 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: perform, prepare >Affects Versions: 2.0 >Reporter: Lars Corneliussen > Fix For: 2.3 > > Attachments: 89d9799a56d46d7435d08c94ca538845d7145c9b[1].patch, > MRELEASE-571-collect-profiles.patch, profile-ignored-with-module.zip > > > MavenProject.getActiveProfiles() does not return all profiles that are > currently run, but instead only those that are run AND defined on the current > project. > This leads to preparation-builds of modules without the specified active > profiles derived from their parents. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
