[jira] Created: (MSITE-458) Fixing the order of items in "Modules" menu
Fixing the order of items in "Modules" menu
---
Key: MSITE-458
URL: http://jira.codehaus.org/browse/MSITE-458
Project: Maven 2.x Site Plugin
Issue Type: New Feature
Components: multi module
Affects Versions: 2.1
Reporter: Andreas Sewe
Currently, it is impossible to influence the order in which the "Modules" show
up in a generated site's menu when including them like this in the site
descriptor:
bq.
As far as I can tell, the order of items in the menu depends on the order in
which Maven builds the modules -- and this does not always put the most
important module at the top of the list. In fact, the top of the list is in all
likelihood occupied by various low-level infrastructure modules; the
high-level, user-visible modules typically come much later. :-(
This also means that the order of menu items depends on the module's
dependencies; thus, this can result in unforeseen changes to the *site* when
one module's *build* changes. Why doesn't Maven simply use the order of the
{{module}} elements? That would be simple and predictable.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-251) Artifacts qualifier are taken into accounts correctly
Artifacts qualifier are taken into accounts correctly
-
Key: MDEP-251
URL: http://jira.codehaus.org/browse/MDEP-251
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Affects Versions: 2.1
Environment: OSX 10.6.2, java 1.6.0_17
Reporter: Jean Seurin
Assignee: Brian Fox
Priority: Critical
I just introduced some qualifier for some libs that require to be compiled in
java5.
I've been very confused when realizing that when packaging a webapp depending
on those qualified artifacts, the non qualified versions are included instead.
It seems to come from dependency plugin.
Here is what happens:
When I do a dependency:tree on an artifact that depends directly on qualified
libs, I get something regular:
[INFO] [dependency:tree {execution: default-cli}]
[INFO] org.company.project:stageof:jar:1.4-SNAPSHOT
[INFO] +- org.company.project:jar:jdk1.5:1.5-SNAPSHOT:compile
[INFO] +- org.company.commons:commons-xml:jar:jdk1.5:1.4-SNAPSHOT:compile
The stageof lib depends on the jdk1.5 qualified commons and commons-xml libs.
When I do a dependency:tree on an upper level webapp that depends on this
stageof lib:
[INFO] org.company.project:webapp:war:1.13-SNAPSHOT
[INFO] +- org.company.project:stageof:jar:jdk1.5:1.4-SNAPSHOT:compile
[INFO] | +- org.company.commons:jar:1.4.0:compile
[INFO] | \- org.company.commons:commons-xml:jar:1.4-SNAPSHOT:compile
[INFO] +- org.company.commons:jar:jdk1.5:1.5-SNAPSHOT:compile
...
it finds correctly the qualified version of stageof, but include non qualified
commons and commons-xml.
These unqualified versions are the dependencies of the also non qualified
stageof-1.4-SNAPSHOT.
>From this behavior, I presume dependency plugin makes a mistake in looking
>from the wrong pom, probably not using the qualifier of the included
>dependency:
org.company.project
stageof
1.4-SNAPSHOT
compile
jdk1.5
Hope this is clear.
I could provide an example if you can't reproduce easily.
Actually, just adding a qualifier to the jar-plugin to produce the artifact and
to the section should do the job.
rgds,
jean
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-251) Artifacts qualifier are taken into accounts correctly
[
http://jira.codehaus.org/browse/MDEP-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207424#action_207424
]
Jean Seurin commented on MDEP-251:
--
Sorry, made a mistake on the issue name itself. It should be:
Artifacts qualifier are NOT taken into accounts correctly
There don't seem to be a way to edit this Issue name.
> Artifacts qualifier are taken into accounts correctly
> -
>
> Key: MDEP-251
> URL: http://jira.codehaus.org/browse/MDEP-251
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: OSX 10.6.2, java 1.6.0_17
>Reporter: Jean Seurin
>Assignee: Brian Fox
>Priority: Critical
>
> I just introduced some qualifier for some libs that require to be compiled in
> java5.
> I've been very confused when realizing that when packaging a webapp depending
> on those qualified artifacts, the non qualified versions are included instead.
> It seems to come from dependency plugin.
> Here is what happens:
> When I do a dependency:tree on an artifact that depends directly on qualified
> libs, I get something regular:
> [INFO] [dependency:tree {execution: default-cli}]
> [INFO] org.company.project:stageof:jar:1.4-SNAPSHOT
> [INFO] +- org.company.project:jar:jdk1.5:1.5-SNAPSHOT:compile
>
> [INFO] +- org.company.commons:commons-xml:jar:jdk1.5:1.4-SNAPSHOT:compile
> The stageof lib depends on the jdk1.5 qualified commons and commons-xml libs.
> When I do a dependency:tree on an upper level webapp that depends on this
> stageof lib:
> [INFO] org.company.project:webapp:war:1.13-SNAPSHOT
> [INFO] +- org.company.project:stageof:jar:jdk1.5:1.4-SNAPSHOT:compile
> [INFO] | +- org.company.commons:jar:1.4.0:compile
> [INFO] | \- org.company.commons:commons-xml:jar:1.4-SNAPSHOT:compile
> [INFO] +- org.company.commons:jar:jdk1.5:1.5-SNAPSHOT:compile
> ...
> it finds correctly the qualified version of stageof, but include non
> qualified commons and commons-xml.
> These unqualified versions are the dependencies of the also non qualified
> stageof-1.4-SNAPSHOT.
> From this behavior, I presume dependency plugin makes a mistake in looking
> from the wrong pom, probably not using the qualifier of the included
> dependency:
>
> org.company.project
> stageof
> 1.4-SNAPSHOT
> compile
> jdk1.5
>
> Hope this is clear.
> I could provide an example if you can't reproduce easily.
> Actually, just adding a qualifier to the jar-plugin to produce the artifact
> and to the section should do the job.
> rgds,
> jean
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MCHECKSTYLE-123) remove use of Serviceable (to be compatible wih maven 3.x)
[ http://jira.codehaus.org/browse/MCHECKSTYLE-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MCHECKSTYLE-123. Resolution: Fixed > remove use of Serviceable (to be compatible wih maven 3.x) > -- > > Key: MCHECKSTYLE-123 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-123 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Critical > Fix For: 2.5 > > > the current version use interface Serviceable which won't work with maven 3.x. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCOMPILER-75) Add apt support for Java 6
[
http://jira.codehaus.org/browse/MCOMPILER-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207432#action_207432
]
Milos Kleint commented on MCOMPILER-75:
---
the open question with generated-sources/annotation-processing/ output folder
setting is how do the xml (or other) files end up in the final binary then.
For generated .java files, the current solution is to add them to the list of
sourceRoots and they get compiled. For non-compilable resources we would have
to add them to the list of resources to be processed (but most likely the
resources processing phase has already passed by that time).
> Add apt support for Java 6
> --
>
> Key: MCOMPILER-75
> URL: http://jira.codehaus.org/browse/MCOMPILER-75
> Project: Maven 2.x Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 2.0.2
>Reporter: Mark Hobson
>
> Apt (Annotation Processing Tool) was merged into javac in Java 6. The
> compiler plugin should support this new functionality, which means supporting
> the following new arguments:
> {noformat}
> -proc:{none,only} Control whether annotation processing and/or
> compilation is done.
> -processor [,,...]Names of the annotation
> processors to run; bypasses default discovery process
> -processorpath Specify where to find annotation processors
> -s Specify where to place generated source files
> -implicit:{none,class} Specify whether or not to generate class files
> for implicitly referenced files
> -Akey[=value] Options to pass to annotation processors
> {noformat}
> Note that this should supersede the Apt Maven Plugin at Mojo by encompassing
> all of its functionality:
> http://mojo.codehaus.org/apt-maven-plugin/index.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCOMPILER-98) -sourcepath not passed to javac
[
http://jira.codehaus.org/browse/MCOMPILER-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207436#action_207436
]
Milos Kleint commented on MCOMPILER-98:
---
http://svn.apache.org/viewvc?rev=900690&view=rev
http://fisheye.codehaus.org/changelog/plexus/?cs=8590
the compiler plugin's trunk still references the 1.6 version of the javac
compiler plugin.
> -sourcepath not passed to javac
> ---
>
> Key: MCOMPILER-98
> URL: http://jira.codehaus.org/browse/MCOMPILER-98
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
> Environment: Ubuntu 8.10, JDK 6.
>Reporter: Jesse Glick
>Priority: Critical
> Attachments: maven-6647998-test.zip, MCOMPILER-98.diff
>
>
> JavacCompiler.java (actually in plexus-compiler-javac, but I cannot find the
> source project for this anywhere) has
> List sourceLocations = config.getSourceLocations();
> if ( sourceLocations != null && !sourceLocations.isEmpty() && (
> sourceFiles.length == 0 ) )
> {
> args.add( "-sourcepath" );
> args.add( getPathString( sourceLocations ) );
> }
> The sourceFiles.length == 0 clause should be deleted. The problem is that
> javac really does need to have -sourcepath even when you are passing an
> explicit list of *.java files; it is necessary for 269-compliant annotation
> processors:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6647998
> Following is a patch which
> 1. Fixes diagnostics to print compiler arguments even for unforked mode.
> (javac is still run with a command line when unforked, so there is no reason
> to omit this valuable diagnostic info.)
> 2. Hacks maven-compiler-plugin to work around the bug in
> plexus-compiler-javac and pass -sourcepath. Obviously a fix to p-c-j would be
> preferable.
> When applied to m-c-p 2.0.2 it allows the test case to build.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-456) [regression] Site navigation not generated
[ http://jira.codehaus.org/browse/MSITE-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207438#action_207438 ] Paul Grove commented on MSITE-456: -- Same issue here. Reverting to site 2.0.1 fixes it. How can such a bug be introduced this is fundamental functionality? > [regression] Site navigation not generated > -- > > Key: MSITE-456 > URL: http://jira.codehaus.org/browse/MSITE-456 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500) > Java version: 1.6.0_16 > Java home: d:\jdk1.6.0_16\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Paul Benedict >Priority: Critical > Fix For: 2.1.1 > > Attachments: MSITE-456.zip > > > My corporate POM locks down the maven-site-plugin to version 2.1. The site of > the corporate POM generates just fine. However, when a child project inherits > from it, that project's site contains no left-hand navigation. Reverting to > 2.0.1 is my workaround. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-104) while filtering resources the token replacement stops at the character @
[
http://jira.codehaus.org/browse/MRESOURCES-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207446#action_207446
]
Samuel Langlois commented on MRESOURCES-104:
I'm afraid I still have the same issue with Maven 2.2.1
And it is more complex than what the summary suggests.
For instance, if you add another @ on the second line of the hello.txt above,
the filtering is OK.
I thought it was related to the parity of @, but it's not that simple either.
A workaround is to stop considering @ as a delimiter in the
maven-resources-plugin :
maven-resources-plugin
${*}
false
> while filtering resources the token replacement stops at the character @
> -
>
> Key: MRESOURCES-104
> URL: http://jira.codehaus.org/browse/MRESOURCES-104
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.4
> Environment: Windows XP, Java 1.6.0_16
>Reporter: Thomas Fahrmeyer
> Fix For: 2.5
>
>
> Create a simple file hello.txt under src/main/resources with following
> content:
> "
> This property ${testProperty} was replaced
> but the one behind a @ will not be processed, as you
> see: ${testProperty}. You shouldn't see a property reference.
> "
> define a build section in your pom.xml like this
>
>
>
> src/main/resources
> true
>
> **/*.txt
>
>
>
> src/main/resources
> false
>
> **/*.txt
>
>
>
> Run the command:
> mvn process-resources -DtestProperty=IwasReplaced
> this produces the output
> "
> This property IwasReplaced was replaced
> but the one behind a @ will not be processed, as you
> see: ${testProperty}. You shouldn't see a property reference.
> "
> As you see, the second property reference was not resolved. The replacement
> just stops after the @ character.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4538) dependencyManagament dependencies within profiles are not activated by settings.xml
dependencyManagament dependencies within profiles are not activated by settings.xml Key: MNG-4538 URL: http://jira.codehaus.org/browse/MNG-4538 Project: Maven 2 & 3 Issue Type: Bug Affects Versions: 2.2.1, 3.0-alpha-7 Environment: Windows XP Reporter: Christian Moser Priority: Critical Attachments: profileBug.zip This issue is *not* reproducable with Maven 2.0.9, 2.0.10 and 2.2.2-RC1-SNAPSHOT. I'm referring to the sample projects contained in profileBug.zip: preparation: - You need to set in your settings.xml: testing - Install main-parent reproducing: - Install project parent. This will fail because of ChildTwo. The transivite dependency of junit is not beeing resolved correctly through project ChildOne even it's not necessary. I guess not finding commons-lang is just a "sequence error" of the "invalid" pom of ChildOne. It seems like the profile isn't activated by the settings.xml and so the dependencies aren't known in context of project ChildTwo transitive dependencies. But e.g. childOne or childThree can be installed without any problems so the profile should be loaded correctly, the only difference to ChildTwo is that they don't have any transitive dependencies to other projects with the same parent. If you cange in project parent the profile "testing" to: true or change the profile activation by property and install project parent with -Dtesting, childTwo will be installed correctly. This issue only occurs with maven 3.0 or 2.2.1. It works fine with maven 2.0.10 or 2.2.2-RC1-SNAPSHOT Will this error be fixed in maven 3.0? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-4538) dependencyManagament dependencies within profiles are not activated by settings.xml
[ http://jira.codehaus.org/browse/MNG-4538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207454#action_207454 ] Christian Moser edited comment on MNG-4538 at 1/19/10 6:42 AM: --- read the last two comments in MNG-1388, please was (Author: onmomo): read the last two comments, please > dependencyManagament dependencies within profiles are not activated by > settings.xml > > > Key: MNG-4538 > URL: http://jira.codehaus.org/browse/MNG-4538 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.2.1, 3.0-alpha-7 > Environment: Windows XP >Reporter: Christian Moser >Priority: Critical > Attachments: profileBug.zip > > > This issue is *not* reproducable with Maven 2.0.9, 2.0.10 and > 2.2.2-RC1-SNAPSHOT. > I'm referring to the sample projects contained in profileBug.zip: > preparation: > - You need to set in your settings.xml: > > testing > > - Install main-parent > reproducing: > - Install project parent. This will fail because of ChildTwo. > The transivite dependency of junit is not beeing resolved correctly through > project ChildOne even it's not necessary. I guess not finding commons-lang is > just a "sequence error" of the "invalid" pom of ChildOne. > It seems like the profile isn't activated by the settings.xml and so the > dependencies aren't known in context of project ChildTwo transitive > dependencies. > But e.g. childOne or childThree can be installed without any problems so the > profile should be loaded correctly, the only difference to ChildTwo is that > they don't have any transitive dependencies to other projects with the same > parent. > If you cange in project parent the profile "testing" to: > >true > > or change the profile activation by property and install project parent with > -Dtesting, childTwo will be installed correctly. > This issue only occurs with maven 3.0 or 2.2.1. It works fine with maven > 2.0.10 or 2.2.2-RC1-SNAPSHOT > Will this error be fixed in maven 3.0? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4538) dependencyManagament dependencies within profiles are not activated by settings.xml
[ http://jira.codehaus.org/browse/MNG-4538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207460#action_207460 ] Christian Moser commented on MNG-4538: -- I've found a different behavior of maven 2.2.1 & 3.0 maven 2.2.1: You're able to install project parent recursive, but installing project childTwo will fail. maven 3.0: You aren't able to install project parent recursive, neither you can install childTwo. > dependencyManagament dependencies within profiles are not activated by > settings.xml > > > Key: MNG-4538 > URL: http://jira.codehaus.org/browse/MNG-4538 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.2.1, 3.0-alpha-7 > Environment: Windows XP >Reporter: Christian Moser >Priority: Critical > Attachments: profileBug.zip > > > This issue is *not* reproducable with Maven 2.0.9, 2.0.10 and > 2.2.2-RC1-SNAPSHOT. > I'm referring to the sample projects contained in profileBug.zip: > preparation: > - You need to set in your settings.xml: > > testing > > - Install main-parent > reproducing: > - Install project parent. This will fail because of ChildTwo. > The transivite dependency of junit is not beeing resolved correctly through > project ChildOne even it's not necessary. I guess not finding commons-lang is > just a "sequence error" of the "invalid" pom of ChildOne. > It seems like the profile isn't activated by the settings.xml and so the > dependencies aren't known in context of project ChildTwo transitive > dependencies. > But e.g. childOne or childThree can be installed without any problems so the > profile should be loaded correctly, the only difference to ChildTwo is that > they don't have any transitive dependencies to other projects with the same > parent. > If you cange in project parent the profile "testing" to: > >true > > or change the profile activation by property and install project parent with > -Dtesting, childTwo will be installed correctly. > This issue only occurs with maven 3.0 or 2.2.1. It works fine with maven > 2.0.10 or 2.2.2-RC1-SNAPSHOT > Will this error be fixed in maven 3.0? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-593) Tag surefire-2.5 creates null.txt as test report
[ http://jira.codehaus.org/browse/SUREFIRE-593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207461#action_207461 ] Kristian Rosenvold commented on SUREFIRE-593: - The bit about "null.txt" and "TEST-org.junit.runner.Result.xml" was probably fixed in SUREFIRE-596, which is part of surefire 2.5 release. I would suspect that the actual test failure is related to some locale setting a file-system-type releated issue. Which file system is used? If you were using junit 4.7+, please re-test with surefire 2.5 release and provide updated results. > Tag surefire-2.5 creates null.txt as test report > > > Key: SUREFIRE-593 > URL: http://jira.codehaus.org/browse/SUREFIRE-593 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.5 > Environment: Windows XP Pro, maven 2.2.1 >Reporter: Kiril Raychev > Attachments: settings.xml > > > When executing 'mvn install' on the tags/surefire-2.5 release (r897179) I get > one failing test: > Running org.apache.maven.surefire.its.UmlautDirIT > Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.219 sec <<< > FAILURE! > When executing 'mvn install -Dmaven.test.skip=true' the build succeeds, but > when it is used on other project, the only output to target/surefire-reports > are null.txt and TEST-org.junit.runner.Result.xml, which contain report of > the last test class run. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (SUREFIRE-593) Tag surefire-2.5 creates null.txt as test report
[ http://jira.codehaus.org/browse/SUREFIRE-593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207461#action_207461 ] Kristian Rosenvold edited comment on SUREFIRE-593 at 1/19/10 7:02 AM: -- The bit about "null.txt" and "TEST-org.junit.runner.Result.xml" was probably fixed in SUREFIRE-596, which is part of surefire 2.5 release. I would suspect that the actual test failure is related to some locale setting or a file-system-type releated issue. Which locale & file system is used? If you were using junit 4.7+, please re-test with surefire 2.5 release and provide updated results. was (Author: krosenvold): The bit about "null.txt" and "TEST-org.junit.runner.Result.xml" was probably fixed in SUREFIRE-596, which is part of surefire 2.5 release. I would suspect that the actual test failure is related to some locale setting a file-system-type releated issue. Which file system is used? If you were using junit 4.7+, please re-test with surefire 2.5 release and provide updated results. > Tag surefire-2.5 creates null.txt as test report > > > Key: SUREFIRE-593 > URL: http://jira.codehaus.org/browse/SUREFIRE-593 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.5 > Environment: Windows XP Pro, maven 2.2.1 >Reporter: Kiril Raychev > Attachments: settings.xml > > > When executing 'mvn install' on the tags/surefire-2.5 release (r897179) I get > one failing test: > Running org.apache.maven.surefire.its.UmlautDirIT > Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.219 sec <<< > FAILURE! > When executing 'mvn install -Dmaven.test.skip=true' the build succeeds, but > when it is used on other project, the only output to target/surefire-reports > are null.txt and TEST-org.junit.runner.Result.xml, which contain report of > the last test class run. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-513) username part of scpexe URLs is ignored
username part of scpexe URLs is ignored --- Key: MRELEASE-513 URL: http://jira.codehaus.org/browse/MRELEASE-513 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform, scm Affects Versions: 2.0-beta-8 Environment: Ubuntu 9.10 x64, Maven 2.2.1 Reporter: Christoph Lechleitner Just like in WAGON-153 some 2 years ago, the current release plugin (2.0-beta-8) ignores the user@ part of scpexe: URLs. Per-server settings in ~/.m2/settings.xml are respected. But with our (clazzes.org) setup using one unix user per project, granting developer access through those users' ~/.ssh/authorized_keys file, this bug forces us to create a unix account for every releasing developmer and to put that in any project's unix group. This hack becomes impossible once there are 2 different developers using equal user names (on their local development machines). We'd appreciate if this bug could be fixed (again). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-514) release:branch hit remoteTagging problem
release:branch hit remoteTagging problem
Key: MRELEASE-514
URL: http://jira.codehaus.org/browse/MRELEASE-514
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: branch
Affects Versions: 2.0-beta-9
Reporter: Benson Margulies
I ran:
mvn release:branch -DbranchName=rlp_7.1
and got ...
{noformat}
[INFO] Working directory: /Users/benson/x/rex2009-trunk/java
org.apache.maven.shared.release.scm.ReleaseScmCommandException: Unable to
branch SCM
Provider message:
The svn branch command failed.
Command output:
svn: Commit failed (details follow):
svn: File '/engineering/rex2009/branches/rlp_7.1/annotatortools/pom.xml'
already exists
at
org.apache.maven.shared.release.phase.ScmBranchPhase.execute(ScmBranchPhase.java:98)
at
org.apache.maven.shared.release.DefaultReleaseManager.branch(DefaultReleaseManager.java:379)
at
org.apache.maven.shared.release.DefaultReleaseManager.branch(DefaultReleaseManager.java:350)
at
org.apache.maven.plugins.release.BranchReleaseMojo.execute(BranchReleaseMojo.java:133)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.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)
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to branch SCM
Provider message:
The svn branch command failed.
Command output:
svn: Commit failed (details follow):
svn: File '/engineering/rex2009/branches/rlp_7.1/annotatortools/pom.xml'
already exists
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-291) Maven uses artifact download credentials during deployment in some circumstances
[ http://jira.codehaus.org/browse/WAGON-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207480#action_207480 ] Brad Hendricks commented on WAGON-291: -- I believe I am also suffering from this issue. I am using maven 2.2.1 on OS X, and I have a pom.xml which has a repo configured in the Repositories section, as well as a different repository configured in the DistributionManagement section. I am using Nexus as the repository, the Repositories section acutally points to a Group and the DistributionManagement section points to the underlying repository, thus the urls are like https://foo.com/My_Group/ and https://foo.com/snapshots/ In my settings.xml I have two server entries for these repos, the first one has a read-only account and the second one has an account with deployment rights. I am unable to deploy my project. The Nexus logs show that during deployment maven attempts to authenticate using the credentials of the first server and not the deployment credentials. If I remove the entry from the Repositories section I am able to deploy. > Maven uses artifact download credentials during deployment in some > circumstances > > > Key: WAGON-291 > URL: http://jira.codehaus.org/browse/WAGON-291 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http-lightweight >Affects Versions: 1.0-beta-6 >Reporter: Rich Seddon > > If Maven downloads an artifact using authorization, this authorization seems > to be cached, which can cause a subsequent deployment to succeed where it > should have failed. > Steps to reproduce: > # Set up a build which will require downloading an artifact from a Nexus > server which requires authentication, and configure your settings.xml > appropriately. > # Create a project with a distribution management section which points to a > repository in the above server. Make sure the repository id doesn't exist in > your settings.xml > # Run "mvn deploy" > What happens: > If the credentials used to download artifacts from Nexus have deployment > privileges in the Nexus repository the deployment will succeed. > Now run "mvn deploy" again. This time the deployment will fail with a 401 > code. > This bug exists in both Maven 2.2.1 and the latest Maven 3.0 snapshots. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-513) username part of scpexe URLs is ignored
[ http://jira.codehaus.org/browse/MRELEASE-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207481#action_207481 ] Dennis Lundberg commented on MRELEASE-513: -- The current version is 2.0-beta-9. Do you have an example project that we use to test this issue? > username part of scpexe URLs is ignored > --- > > Key: MRELEASE-513 > URL: http://jira.codehaus.org/browse/MRELEASE-513 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: perform, scm >Affects Versions: 2.0-beta-8 > Environment: Ubuntu 9.10 x64, Maven 2.2.1 >Reporter: Christoph Lechleitner > > Just like in WAGON-153 some 2 years ago, the current release plugin > (2.0-beta-8) ignores the user@ part of scpexe: URLs. > Per-server settings in ~/.m2/settings.xml are respected. > But with our (clazzes.org) setup using one unix user per project, granting > developer access through those users' ~/.ssh/authorized_keys file, this bug > forces us to create a unix account for every releasing developmer and to put > that in any project's unix group. This hack becomes impossible once there are > 2 different developers using equal user names (on their local development > machines). > We'd appreciate if this bug could be fixed (again). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-261) release:prepare should support flat directory multi-module projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207486#action_207486 ] Dennis Lundberg commented on MRELEASE-261: -- Eric, After more digging in the source code I found an Integration Test for a flat multi module project. http://svn.apache.org/repos/asf/maven/release/trunk/maven-release-plugin/src/it/flat-multi-module/ This project only has an SCM element in the parent project. This is what I was expecting to find. Have a look at it and see if it can help you in any way. If you have a multi module project that you want to release all in one go, then that should also be reflected in the SCM, by having a single trunk for the entire multi module project. > release:prepare should support flat directory multi-module projects > --- > > Key: MRELEASE-261 > URL: http://jira.codehaus.org/browse/MRELEASE-261 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare > Environment: linux / maven2 / svn >Reporter: paul.whe...@gmail.com >Assignee: Maria Odea Ching > Fix For: 2.0 > > Attachments: flatProject.main.patch, flatProject.test.patch, > maven-release-issue.tar.gz, maven-release-issue.zip, > MRELEASE-261-sample-project.zip, MRELEASE-261-with-its-v3.patch, > MRELEASE-261-with-its.patch, MRELEASE-261.patch, odd-tags.png, > PrepareReleaseMojo.patch > > > What I mean by flat file structure firstly. > parent/pom.xml > module1/pom.xml > module2/pom.xml > . > . > . > module15/pom.xml > the parent references the modules like so > > ../module1 > ../module2 > . > . > . > ../module15 > > When i release:prepare only the parent project is tagged the modules > projects versions are incremented etc but the modules are not tagged in svn. > I use this structure as i use eclipse as my IDE. > I would love to see a fix for the issue marked as closed here > http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand > each submodule of the projects but it would be so nice to have the release > plugin do this for me. > forgive my english. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-513) username part of scpexe URLs is ignored
[ http://jira.codehaus.org/browse/MRELEASE-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207488#action_207488 ] Christoph Lechleitner commented on MRELEASE-513: I will set up a demo project and upgrade to beta-9 and report back in a few days. > username part of scpexe URLs is ignored > --- > > Key: MRELEASE-513 > URL: http://jira.codehaus.org/browse/MRELEASE-513 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: perform, scm >Affects Versions: 2.0-beta-8 > Environment: Ubuntu 9.10 x64, Maven 2.2.1 >Reporter: Christoph Lechleitner > > Just like in WAGON-153 some 2 years ago, the current release plugin > (2.0-beta-8) ignores the user@ part of scpexe: URLs. > Per-server settings in ~/.m2/settings.xml are respected. > But with our (clazzes.org) setup using one unix user per project, granting > developer access through those users' ~/.ssh/authorized_keys file, this bug > forces us to create a unix account for every releasing developmer and to put > that in any project's unix group. This hack becomes impossible once there are > 2 different developers using equal user names (on their local development > machines). > We'd appreciate if this bug could be fixed (again). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-444) Git provider does 'git push' during 'mvn release:prepare' which causes unwanted problems
[
http://jira.codehaus.org/browse/SCM-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207489#action_207489
]
Johannes Schneider commented on SCM-444:
Okay, just my opinion: I run into that problem, too. I really *hate* that push.
I prefer to do that manually after everything worked as expected. And sometimes
I prefer to adjust that commits too (multi module projects).
At the moment I end up deleting tags from origin and often doing a "git push
-f" if something failed (e.g. site generation)...
That does not seem to be the best solution...
Others here have also said, that they prefer *not* being forced to push to
origin. So there are the user stories you asked for.
So the solution seems to be very simple:
- Clone from ${basedir} instead of origin during the release. That might solve
some other issues too (performance, traffic, merge conflicts when origin has
changed in between).
- Make the push optional! That allows everybody to follow his preferred work
flow.
While I strongly believe that *distributed* VCS never should push
automatically, I accept that some people out there are still "brainwashed" by
the use of a centralized VCS for decades.
So for me it is ok, to push by default. But please offer an option to skip
that...
By the way: Thanks for your work...
> Git provider does 'git push' during 'mvn release:prepare' which causes
> unwanted problems
>
>
> Key: SCM-444
> URL: http://jira.codehaus.org/browse/SCM-444
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.1
>Reporter: Petter Måhlén
>Assignee: Mark Struberg
>Priority: Minor
>
> When doing 'mvn release:prepare' with a Git provider, a 'git push' command is
> executed. This is not ideal because the push command can fail or push things
> from the local repository that are not needed/wanted in the remote
> repository. Some examples are:
> 1. The local repository has two branches: master (tracking origin/master) and
> dummy (tracking origin/dummy). The release is being made on the master
> branch, and the dummy and origin/dummy branches have diverged. Running
> 'release:prepare' causes a 'git push', which will succeed for the master
> branch (assuming that the release preparation has been made correctly) and
> fail for the dummy branch (the two branches have diverged and need to be
> merged or rebased). The release preparation aborts and the directory is left
> in a somewhat inconsistent state where manual cleaning up is needed (removing
> pom.xml.next files, changing versions to -SNAPSHOT, etc.)
> 2. The local repository has two branches: master (tracking origin/master) and
> localtest (not in the origin repository). The localtest branch shouldn't be
> published because it is just used for some temporary testing and doesn't even
> work. It will be pushed during 'release:prepare'.
> Suggested behaviour: use 'git push origin :',
> or even better, query for which remote repository to push to (found in
> .git/config) and which branch to push from and to. For me, it would be great
> to have a 'confirm push' before doing it so as to keep things clean, but
> maybe that is quite complex.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-456) [regression] Site navigation not generated
[ http://jira.codehaus.org/browse/MSITE-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207492#action_207492 ] Dennis Lundberg commented on MSITE-456: --- I'll give you a couple of reasons: * We have too few integration tests * Not enough people help to test the plugins during the release process If you have patches I'll be happy to review them. > [regression] Site navigation not generated > -- > > Key: MSITE-456 > URL: http://jira.codehaus.org/browse/MSITE-456 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500) > Java version: 1.6.0_16 > Java home: d:\jdk1.6.0_16\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Paul Benedict >Priority: Critical > Fix For: 2.1.1 > > Attachments: MSITE-456.zip > > > My corporate POM locks down the maven-site-plugin to version 2.1. The site of > the corporate POM generates just fine. However, when a child project inherits > from it, that project's site contains no left-hand navigation. Reverting to > 2.0.1 is my workaround. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-261) release:prepare should support flat directory multi-module projects
[
http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207493#action_207493
]
Eric Miles commented on MRELEASE-261:
-
Dennis,
So I guess you're saying that it's impossible for the release plugin to support
the following SVN structure (or there are no future plans to support it)?
{noformat}
svnroot
|
+--release-parent/trunk/pom.xml
|
+--release-module1/trunk/pom.xml
|
+--release-module1/trunk/pom.xml
{noformat}
The reason I ask is I am often brought on client/projects LONG after their SVN
repos are setup and whether or not they can use the release plugin (especially
for large projects) would be a big determinator for me in a Maven
recommendation. Trust me, I'd prefer if clients could/would reposition their
SVN repo and existing projects so multi-module builds "just worked".
> release:prepare should support flat directory multi-module projects
> ---
>
> Key: MRELEASE-261
> URL: http://jira.codehaus.org/browse/MRELEASE-261
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: prepare
> Environment: linux / maven2 / svn
>Reporter: paul.whe...@gmail.com
>Assignee: Maria Odea Ching
> Fix For: 2.0
>
> Attachments: flatProject.main.patch, flatProject.test.patch,
> maven-release-issue.tar.gz, maven-release-issue.zip,
> MRELEASE-261-sample-project.zip, MRELEASE-261-with-its-v3.patch,
> MRELEASE-261-with-its.patch, MRELEASE-261.patch, odd-tags.png,
> PrepareReleaseMojo.patch
>
>
> What I mean by flat file structure firstly.
> parent/pom.xml
> module1/pom.xml
> module2/pom.xml
> .
> .
> .
> module15/pom.xml
> the parent references the modules like so
>
> ../module1
> ../module2
> .
> .
> .
> ../module15
>
> When i release:prepare only the parent project is tagged the modules
> projects versions are incremented etc but the modules are not tagged in svn.
> I use this structure as i use eclipse as my IDE.
> I would love to see a fix for the issue marked as closed here
> http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand
> each submodule of the projects but it would be so nice to have the release
> plugin do this for me.
> forgive my english.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRELEASE-261) release:prepare should support flat directory multi-module projects
[
http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207493#action_207493
]
Eric Miles edited comment on MRELEASE-261 at 1/19/10 10:08 AM:
---
Dennis,
So I guess you're saying that it's impossible for the release plugin to support
the following SVN structure (or there are no future plans to support it)?
{noformat}
svnroot
|
+--release-parent/trunk/pom.xml
|
+--release-module1/trunk/pom.xml
|
+--release-module1/trunk/pom.xml
{noformat}
The reason I ask is I am often brought on client/projects LONG after their SVN
repos are setup and whether or not they can use the release plugin (especially
for large projects) would be a big determinator for me in a Maven
recommendation. Trust me, I'd prefer if clients could/would reposition their
SVN repo and existing projects so multi-module builds "just worked".
It sounds like the definition of a flat structure in this particular test case
is all projects "flattened" behind a single trunk/branch/tag. My use case are
the projects are flattened at the SVN root level, but each have their own
trunk/branches/tags. It seems as though my use case is a hybrid of the typical
maven setup and the flattened use case you have provided.
was (Author: bigehokie):
Dennis,
So I guess you're saying that it's impossible for the release plugin to support
the following SVN structure (or there are no future plans to support it)?
{noformat}
svnroot
|
+--release-parent/trunk/pom.xml
|
+--release-module1/trunk/pom.xml
|
+--release-module1/trunk/pom.xml
{noformat}
The reason I ask is I am often brought on client/projects LONG after their SVN
repos are setup and whether or not they can use the release plugin (especially
for large projects) would be a big determinator for me in a Maven
recommendation. Trust me, I'd prefer if clients could/would reposition their
SVN repo and existing projects so multi-module builds "just worked".
> release:prepare should support flat directory multi-module projects
> ---
>
> Key: MRELEASE-261
> URL: http://jira.codehaus.org/browse/MRELEASE-261
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: prepare
> Environment: linux / maven2 / svn
>Reporter: paul.whe...@gmail.com
>Assignee: Maria Odea Ching
> Fix For: 2.0
>
> Attachments: flatProject.main.patch, flatProject.test.patch,
> maven-release-issue.tar.gz, maven-release-issue.zip,
> MRELEASE-261-sample-project.zip, MRELEASE-261-with-its-v3.patch,
> MRELEASE-261-with-its.patch, MRELEASE-261.patch, odd-tags.png,
> PrepareReleaseMojo.patch
>
>
> What I mean by flat file structure firstly.
> parent/pom.xml
> module1/pom.xml
> module2/pom.xml
> .
> .
> .
> module15/pom.xml
> the parent references the modules like so
>
> ../module1
> ../module2
> .
> .
> .
> ../module15
>
> When i release:prepare only the parent project is tagged the modules
> projects versions are incremented etc but the modules are not tagged in svn.
> I use this structure as i use eclipse as my IDE.
> I would love to see a fix for the issue marked as closed here
> http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand
> each submodule of the projects but it would be so nice to have the release
> plugin do this for me.
> forgive my english.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-444) Git provider does 'git push' during 'mvn release:prepare' which causes unwanted problems
[ http://jira.codehaus.org/browse/SCM-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207494#action_207494 ] Mark Struberg commented on SCM-444: --- Johannes, it's not about what people got used to but more about having kind of a 'common commit' (in the SQL commit way). While I see the wish to omit the push, we have to make sure that the tag gets pushed if the artifacts are going to be pushed to a public repo. My ideal scenario would be that we do not push if you do a release:stage but push if you do a release:perform. Ideally this would also integrate with nexus:staging-finish in an elegant way. > Git provider does 'git push' during 'mvn release:prepare' which causes > unwanted problems > > > Key: SCM-444 > URL: http://jira.codehaus.org/browse/SCM-444 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.1 >Reporter: Petter Måhlén >Assignee: Mark Struberg >Priority: Minor > > When doing 'mvn release:prepare' with a Git provider, a 'git push' command is > executed. This is not ideal because the push command can fail or push things > from the local repository that are not needed/wanted in the remote > repository. Some examples are: > 1. The local repository has two branches: master (tracking origin/master) and > dummy (tracking origin/dummy). The release is being made on the master > branch, and the dummy and origin/dummy branches have diverged. Running > 'release:prepare' causes a 'git push', which will succeed for the master > branch (assuming that the release preparation has been made correctly) and > fail for the dummy branch (the two branches have diverged and need to be > merged or rebased). The release preparation aborts and the directory is left > in a somewhat inconsistent state where manual cleaning up is needed (removing > pom.xml.next files, changing versions to -SNAPSHOT, etc.) > 2. The local repository has two branches: master (tracking origin/master) and > localtest (not in the origin repository). The localtest branch shouldn't be > published because it is just used for some temporary testing and doesn't even > work. It will be pushed during 'release:prepare'. > Suggested behaviour: use 'git push origin :', > or even better, query for which remote repository to push to (found in > .git/config) and which branch to push from and to. For me, it would be great > to have a 'confirm push' before doing it so as to keep things clean, but > maybe that is quite complex. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-85) java.lang.NoClassDefFoundError: org/apache/maven/surefire/util/NestedCheckedException
[ http://jira.codehaus.org/browse/SUREFIRE-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207495#action_207495 ] Anton Tagunov commented on SUREFIRE-85: --- me too just had it today with Apache Maven 2.2.1 (r801777; 2009-08-06 20:16:01+0100) and latest surefire > java.lang.NoClassDefFoundError: > org/apache/maven/surefire/util/NestedCheckedException > - > > Key: SUREFIRE-85 > URL: http://jira.codehaus.org/browse/SUREFIRE-85 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.0 (2.2 plugin) > Environment: Windows XP / Sun JDK 1.5.0_06 >Reporter: David J. M. Karlsen > Fix For: 2.0 (2.2 plugin) > > Attachments: log.txt > > > java.lang.NoClassDefFoundError: > org/apache/maven/surefire/util/NestedCheckedException > Exception in thread "main" > is thrown during execution of the maven-surefire-plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-261) release:prepare should support flat directory multi-module projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207514#action_207514 ] Dennis Lundberg commented on MRELEASE-261: -- Thanks for explaining Eric, It does seem that the problem you have is slightly different than the one covered by his issue. The reason why I'm asking all these questions is that I haven't worked with flat projects before. Because of that I'm not in a position to say if there are any future plans for such a feature. Would you mind opening up a new JIRA issue for your problem, so that we don't loose it. I'll link the two issues together. One final question, to give me a better understanding of your use case. Why do you (or your clients) have branches/tags/trunk for each module, when you (or they) release them all together? > release:prepare should support flat directory multi-module projects > --- > > Key: MRELEASE-261 > URL: http://jira.codehaus.org/browse/MRELEASE-261 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare > Environment: linux / maven2 / svn >Reporter: paul.whe...@gmail.com >Assignee: Maria Odea Ching > Fix For: 2.0 > > Attachments: flatProject.main.patch, flatProject.test.patch, > maven-release-issue.tar.gz, maven-release-issue.zip, > MRELEASE-261-sample-project.zip, MRELEASE-261-with-its-v3.patch, > MRELEASE-261-with-its.patch, MRELEASE-261.patch, odd-tags.png, > PrepareReleaseMojo.patch > > > What I mean by flat file structure firstly. > parent/pom.xml > module1/pom.xml > module2/pom.xml > . > . > . > module15/pom.xml > the parent references the modules like so > > ../module1 > ../module2 > . > . > . > ../module15 > > When i release:prepare only the parent project is tagged the modules > projects versions are incremented etc but the modules are not tagged in svn. > I use this structure as i use eclipse as my IDE. > I would love to see a fix for the issue marked as closed here > http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand > each submodule of the projects but it would be so nice to have the release > plugin do this for me. > forgive my english. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-261) release:prepare should support flat directory multi-module projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207519#action_207519 ] Eric Miles commented on MRELEASE-261: - Dennis, No problem with the questions. When I get enough time, I'll create a new JIRA and reference here in the comments. I wish I could answer why they have setup their repositories this way, I certainly would have steered them otherwise if I had been there during initial infrastructure setup. My current client I'm pushing to move to the more traditional nested model for Maven multi-module projects, but it's not a quick process. One multi-module build of theirs contains over 36 modules (and an obvious candidate for breaking into smaller project)! Thanks again for your help. > release:prepare should support flat directory multi-module projects > --- > > Key: MRELEASE-261 > URL: http://jira.codehaus.org/browse/MRELEASE-261 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare > Environment: linux / maven2 / svn >Reporter: paul.whe...@gmail.com >Assignee: Maria Odea Ching > Fix For: 2.0 > > Attachments: flatProject.main.patch, flatProject.test.patch, > maven-release-issue.tar.gz, maven-release-issue.zip, > MRELEASE-261-sample-project.zip, MRELEASE-261-with-its-v3.patch, > MRELEASE-261-with-its.patch, MRELEASE-261.patch, odd-tags.png, > PrepareReleaseMojo.patch > > > What I mean by flat file structure firstly. > parent/pom.xml > module1/pom.xml > module2/pom.xml > . > . > . > module15/pom.xml > the parent references the modules like so > > ../module1 > ../module2 > . > . > . > ../module15 > > When i release:prepare only the parent project is tagged the modules > projects versions are incremented etc but the modules are not tagged in svn. > I use this structure as i use eclipse as my IDE. > I would love to see a fix for the issue marked as closed here > http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand > each submodule of the projects but it would be so nice to have the release > plugin do this for me. > forgive my english. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-261) release:prepare should support flat directory multi-module projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MRELEASE-261. Resolution: Fixed The reason this was reopened turned out to be a variation on this issue. A new issue will be created for that variation. Closing this one as fixed now. > release:prepare should support flat directory multi-module projects > --- > > Key: MRELEASE-261 > URL: http://jira.codehaus.org/browse/MRELEASE-261 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare > Environment: linux / maven2 / svn >Reporter: paul.whe...@gmail.com >Assignee: Maria Odea Ching > Fix For: 2.0 > > Attachments: flatProject.main.patch, flatProject.test.patch, > maven-release-issue.tar.gz, maven-release-issue.zip, > MRELEASE-261-sample-project.zip, MRELEASE-261-with-its-v3.patch, > MRELEASE-261-with-its.patch, MRELEASE-261.patch, odd-tags.png, > PrepareReleaseMojo.patch > > > What I mean by flat file structure firstly. > parent/pom.xml > module1/pom.xml > module2/pom.xml > . > . > . > module15/pom.xml > the parent references the modules like so > > ../module1 > ../module2 > . > . > . > ../module15 > > When i release:prepare only the parent project is tagged the modules > projects versions are incremented etc but the modules are not tagged in svn. > I use this structure as i use eclipse as my IDE. > I would love to see a fix for the issue marked as closed here > http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand > each submodule of the projects but it would be so nice to have the release > plugin do this for me. > forgive my english. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-634) projectNameTemplate not applied to project references
[
http://jira.codehaus.org/browse/MECLIPSE-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207530#action_207530
]
Gary Gregory commented on MECLIPSE-634:
---
The .classpath is also incorrect:
{code:xml}
{code}
> projectNameTemplate not applied to project references
> -
>
> Key: MECLIPSE-634
> URL: http://jira.codehaus.org/browse/MECLIPSE-634
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : .project
>Affects Versions: 2.7
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
> Java version: 1.6.0_16
> Java home: C:\Program Files\Java\jdk1.6.0_16\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows vista" version: "6.0" arch: "amd64" Family: "windows"
>Reporter: Gary Gregory
>
> When I run the command:
> mvn -Psetup.eclipse -Declipse.projectNameTemplate=[artifactId]-2.2.x
> I get .project files like this one:
> {code:xml}
>
> cxf-api-2.2.x
>
>
> cxf-common-schemas
> cxf-common-utilities
> cxf-xjc-dv
>
>
>
> org.eclipse.jdt.core.javabuilder
>
>
> net.sourceforge.pmd.eclipse.plugin.pmdBuilder
>
>
> net.sf.eclipsecs.core.CheckstyleBuilder
>
>
> com.atlassw.tools.eclipse.checkstyle.CheckstyleBuilder
>
>
>
> org.eclipse.jdt.core.javanature
> net.sourceforge.pmd.eclipse.plugin.pmdNature
> net.sf.eclipsecs.core.CheckstyleNature
> com.atlassw.tools.eclipse.checkstyle.CheckstyleNature
>
>
> {code}
> You will notice the name has been correctly written:
> {code:xml}
> cxf-api-2.2.x
> {code}
> BUT, the references do not have the correct names:
> {code:xml}
>
> cxf-common-schemas
> cxf-common-utilities
> cxf-xjc-dv
>
> {code}
> They should be:
> {code:xml}
>
> cxf-common-schemas-2.2.x
> cxf-common-utilities-2.2.x
> cxf-xjc-dv-2.2.x
>
> {code}
> Which cause the projects to be marked with errors in Eclipse and the
> workspace build cannot complete.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-466) MultiModule Projects, Assembly target causes unpredictable build order
MultiModule Projects, Assembly target causes unpredictable build order -- Key: MASSEMBLY-466 URL: http://jira.codehaus.org/browse/MASSEMBLY-466 Project: Maven 2.x Assembly Plugin Issue Type: Bug Environment: Windows Reporter: Bill Smith Attachments: log.txt, mvn.zip I have a multi module project. One of the projects uses an ant task to generate source code. When runnning the command mvn package assembly:assembly I am seeing the ant task run more then once. If I simply run mvn package all builds fine, but I obviously don't have my assembly. Attached is a sample maven project. Inside there is also a log of out the output from my build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MECLIPSE-634) projectNameTemplate not applied to project references
[
http://jira.codehaus.org/browse/MECLIPSE-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207530#action_207530
]
Gary Gregory edited comment on MECLIPSE-634 at 1/19/10 3:07 PM:
The .classpath is also incorrect:
{code:xml}
{code}
was (Author: garydgregory):
The .classpath is also incorrect:
{code:xml}
{code}
> projectNameTemplate not applied to project references
> -
>
> Key: MECLIPSE-634
> URL: http://jira.codehaus.org/browse/MECLIPSE-634
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : .project
>Affects Versions: 2.7
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
> Java version: 1.6.0_16
> Java home: C:\Program Files\Java\jdk1.6.0_16\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows vista" version: "6.0" arch: "amd64" Family: "windows"
>Reporter: Gary Gregory
>
> When I run the command:
> mvn -Psetup.eclipse -Declipse.projectNameTemplate=[artifactId]-2.2.x
> I get .project files like this one:
> {code:xml}
>
> cxf-api-2.2.x
>
>
> cxf-common-schemas
> cxf-common-utilities
> cxf-xjc-dv
>
>
>
> org.eclipse.jdt.core.javabuilder
>
>
> net.sourceforge.pmd.eclipse.plugin.pmdBuilder
>
>
> net.sf.eclipsecs.core.CheckstyleBuilder
>
>
> com.atlassw.tools.eclipse.checkstyle.CheckstyleBuilder
>
>
>
> org.eclipse.jdt.core.javanature
> net.sourceforge.pmd.eclipse.plugin.pmdNature
> net.sf.eclipsecs.core.CheckstyleNature
> com.atlassw.tools.eclipse.checkstyle.CheckstyleNature
>
>
> {code}
> You will notice the name has been correctly written:
> {code:xml}
> cxf-api-2.2.x
> {code}
> BUT, the references do not have the correct names:
> {code:xml}
>
> cxf-common-schemas
> cxf-common-utilities
> cxf-xjc-dv
>
> {code}
> They should be:
> {code:xml}
>
> cxf-common-schemas-2.2.x
> cxf-common-utilities-2.2.x
> cxf-xjc-dv-2.2.x
>
> {code}
> Which cause the projects to be marked with errors in Eclipse and the
> workspace build cannot complete.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2723) Upload quartz-1.7.0 artifacts
Upload quartz-1.7.0 artifacts - Key: MAVENUPLOAD-2723 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2723 Project: Maven Upload Requests Issue Type: Wish Reporter: Jason Voegele http://download.terracotta.org/quartz-bundles/quartz-parent-1.7.0-bundle.jar http://download.terracotta.org/quartz-bundles/quartz-1.7.0-bundle.jar http://download.terracotta.org/quartz-bundles/quartz-jboss-1.7.0-bundle.jar http://download.terracotta.org/quartz-bundles/quartz-oracle-1.7.0-bundle.jar http://download.terracotta.org/quartz-bundles/quartz-weblogic-1.7.0-bundle.jar I am a developer and build engineer at Terracotta. We have taken over build responsibilities for Quartz. Please upload the bundles listed above, which represent the 1.7.0 release of Quartz using the org.quartz-scheduler groupId. There is no page on quartz-scheduler.org that lists my name as a developer, but to verify you may contact me at my Terracotta email address (jvoegele (at) terracotta dot org) or contact James House, the primary maintainer of the Quartz project. For future releases we intend to follow the process for "Sync'ing your own repository to the central repository automatically", but the infrastructure is not yet in place for us to do this. Hence this one time request for manual upload. Thank you. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4432) reimplement parallel artifacts download
[ http://jira.codehaus.org/browse/MNG-4432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4432. -- Resolution: Fixed Fix Version/s: 3.0-alpha-7 Assignee: Benjamin Bentmann Done in [r900982|http://svn.apache.org/viewvc?view=revision&revision=900982]. > reimplement parallel artifacts download > --- > > Key: MNG-4432 > URL: http://jira.codehaus.org/browse/MNG-4432 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Dependencies >Affects Versions: 3.0-alpha-3 >Reporter: Olivier Lamy >Assignee: Benjamin Bentmann > Fix For: 3.0-alpha-7 > > > the current maven3 trunk (3.0-alpha-3) doesn't contains a nice feature which > exists in 2.x : parallel download artifacts. > This made really faster starting with an empty repo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-527) Not enough information reported to enable troubleshooting
Not enough information reported to enable troubleshooting - Key: SCM-527 URL: http://jira.codehaus.org/browse/SCM-527 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-svn Reporter: Kohsuke Kawaguchi SVN provider for Wagon often uses a temporary file to invoke svn.exe. Such a file is immediately deleted, which makes it impossible for people to diagnose the problem when svn operation fails. For example, in MRELEASE-332, the user cannot replicate the problem since he doesn't know exactly what's in /tmp/maven-scm-248675112.commit. I just had a similar painful troubleshooting session. I suggest you leave those temporary files around if the svn execution fails, so that the user can just copy&paste the command line dump to the shell to retry the behavior. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-515) release:prepare eats the root cause of the exception
release:prepare eats the root cause of the exception
Key: MRELEASE-515
URL: http://jira.codehaus.org/browse/MRELEASE-515
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-9
Reporter: Kohsuke Kawaguchi
The PrepareReleaseMojo.execute() method contains the following statement:
{code:java}
try
{
releaseManager.prepare( config, getReleaseEnvironment(), reactorProjects,
resume, dryRun );
}
catch ( ReleaseExecutionException e )
{
throw new MojoExecutionException( e.getMessage(), e );
}
catch ( ReleaseFailureException e )
{
throw new MojoFailureException( e.getMessage() );
}
{code}
As you can see, the stack trace and nested exception of the
ReleaseFailureException is lost, which makes it unnecessarily hard to diagnose
the root cause of problems like MRELEASE-332. The code should be modified to
something like:
{code}
throw (MojoFailureException)new MojoFailureException( e.getMessage()
).initCause(e);
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-515) release:prepare eats the root cause of the exception
[
http://jira.codehaus.org/browse/MRELEASE-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207543#action_207543
]
Kohsuke Kawaguchi commented on MRELEASE-515:
Also see MNG-3279, which adds the right constructor to MojoFailureException,
although I don't know if maven-release-plugin can depend on 2.0.9 or not.
> release:prepare eats the root cause of the exception
>
>
> Key: MRELEASE-515
> URL: http://jira.codehaus.org/browse/MRELEASE-515
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-9
>Reporter: Kohsuke Kawaguchi
>
> The PrepareReleaseMojo.execute() method contains the following statement:
> {code:java}
> try
> {
> releaseManager.prepare( config, getReleaseEnvironment(), reactorProjects,
> resume, dryRun );
> }
> catch ( ReleaseExecutionException e )
> {
> throw new MojoExecutionException( e.getMessage(), e );
> }
> catch ( ReleaseFailureException e )
> {
> throw new MojoFailureException( e.getMessage() );
> }
> {code}
> As you can see, the stack trace and nested exception of the
> ReleaseFailureException is lost, which makes it unnecessarily hard to
> diagnose the root cause of problems like MRELEASE-332. The code should be
> modified to something like:
> {code}
> throw (MojoFailureException)new MojoFailureException( e.getMessage()
> ).initCause(e);
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPLUGIN-167) error when using Maven 3.x with maven-site-plugin 3.x
error when using Maven 3.x with maven-site-plugin 3.x - Key: MPLUGIN-167 URL: http://jira.codehaus.org/browse/MPLUGIN-167 Project: Maven 2.x Plugin Tools Issue Type: Bug Affects Versions: 2.5.1 Reporter: Herve Boutemy tested today on Modello (r1327), got the following error message: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-1-SNAPSHOT:site (default-site) on project modello-maven-plugin: failed to get Reports: Unable to load the mojo 'updateRegistry' in the plugin 'org.apache.maven.plugins:maven-plugin-plugin:2.5.1'. A required class is missing: org/apache/maven/plugin/registry/PluginRegistry -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
