[jira] Updated: (SCM-561) Final cleanup accurev provider for 1.4
[ http://jira.codehaus.org/browse/SCM-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-561: - Fix Version/s: 1.4 Final cleanup accurev provider for 1.4 -- Key: SCM-561 URL: http://jira.codehaus.org/browse/SCM-561 Project: Maven SCM Issue Type: Improvement Components: maven-scm-provider-accurev Affects Versions: 1.4 Reporter: Grant Gardner Assignee: Olivier Lamy Fix For: 1.4 Attachments: accurev-update.patch Using my patches for SCM-554 in real world scenarios exposed some issues not covered by the tck tests since these tests were using the depot root stream. The attached (large) patch has refactored the tck tests to use a more realistic example of a dynamic stream, which exposed a number of further issues that are also fixed. Also fixed the tck tests running on Windows. This patch passes tck tests on both Windows and Linux. Windows is tested against AccuRev 4.7.x, Linux has been tested against AccuRev 4.7.x and 5.0.1. The patch includes the changes implementing SCM-554 and also cleans up relevant additional system properties to be prefixed with maven.scm.accurev. These properties may also be passed in via the scm url. -- 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-536) CommonBasedir Calculation fails on windows
[ http://jira.codehaus.org/browse/MRELEASE-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=230293#action_230293 ] Jan Sievers commented on MRELEASE-536: -- no this is different I think. It's about non-case sensitive file name compare on windows platforms, i.e. c:\TMP\foo.txt and c:\tmp\Foo.txt denote the same file on windows but the case sensitive String comparison fails to find the common basedir. CommonBasedir Calculation fails on windows -- Key: MRELEASE-536 URL: http://jira.codehaus.org/browse/MRELEASE-536 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.0 Reporter: Matthias Vach Attachments: patchfile.patch The method getCommonBasedir in class org.apache.maven.shared.release.util.ReleaseUtil runs into the Exception:\\ java.lang.StringIndexOutOfBoundsException: String index out of range: -1 ... while comparing pathes with small and capital lettes for Windows drives. e.g.: C:\WoRkInG\root\project1 has no common base dir with c:\working\root\project2\\ but it should have c:\working\root as common base directory. A patch and a test for that bug is attached. I do have the problem with version 2.0 but I fixed it in trunk for now Regards Matthias -- 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: (SCM-561) Final cleanup accurev provider for 1.4
[ http://jira.codehaus.org/browse/SCM-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed SCM-561. Resolution: Fixed fixed rev 980673 Thanks ! Final cleanup accurev provider for 1.4 -- Key: SCM-561 URL: http://jira.codehaus.org/browse/SCM-561 Project: Maven SCM Issue Type: Improvement Components: maven-scm-provider-accurev Affects Versions: 1.4 Reporter: Grant Gardner Assignee: Olivier Lamy Fix For: 1.4 Attachments: accurev-update.patch Using my patches for SCM-554 in real world scenarios exposed some issues not covered by the tck tests since these tests were using the depot root stream. The attached (large) patch has refactored the tck tests to use a more realistic example of a dynamic stream, which exposed a number of further issues that are also fixed. Also fixed the tck tests running on Windows. This patch passes tck tests on both Windows and Linux. Windows is tested against AccuRev 4.7.x, Linux has been tested against AccuRev 4.7.x and 5.0.1. The patch includes the changes implementing SCM-554 and also cleans up relevant additional system properties to be prefixed with maven.scm.accurev. These properties may also be passed in via the scm url. -- 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-583) Better Snapshot Dependency Handling
Better Snapshot Dependency Handling --- Key: MRELEASE-583 URL: http://jira.codehaus.org/browse/MRELEASE-583 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Affects Versions: 2.0 Reporter: nicola sinapsi The plugin has a simple snapshot dependency resolution mechanism. When a snapshot dependency is found, it allows for setting it to release... but it does not allows to choice the release version to use: code Resolve Project Dependency Snapshots.: 'com.sinapsi.libs:sinapsi-commons' set to release? (yes/no) yes: : yes What is the next development version? (2.1.3-SNAPSHOT) 2.1.3-SNAPSHOT: : /code in this case the versions are: current: 2.1.2-SNAPSHOT release: 2.1.2 next: 2.1.3-SNAPSHOT The problem is that the only allowed development version is 2.1.3-SNAPSHOT (the value between the parentheses), hence the only allowed release version is 2.1.2. Notably, you cannot specify an OLDER relase (such as 2.1.1): this means you are forced to release the dependency (you cannot use an already released version). It would be better to ask for the release version to use, and then set the snapshot as the release following the release version specified by the user: code Resolve Project Dependency Snapshots.: 'com.sinapsi.libs:sinapsi-commons' set to release? (yes/no) yes: : yes What is the release version? 2.1.2: : 2.3.0 /code in this case the versions are: current: 2.1.2-SNAPSHOT release: 2.3.0 next: 2.3.1-SNAPSHOT The plugin suggests to set the release version to 2.1.2, but the user can choice another version, eventually an already released version. -- 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] Updated: (MRELEASE-583) Better Snapshot Dependency Handling
[ http://jira.codehaus.org/browse/MRELEASE-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nicola sinapsi updated MRELEASE-583: Attachment: better-snapshot-dependency.patch I have attached a patch with the enhancement, and corrected the corresponding test (CheckDependencySnapshotsPhaseTest). The patch is pretty straightforward. I could check whether all the integration tests are still working since i didn't succed in running all of them. Better Snapshot Dependency Handling --- Key: MRELEASE-583 URL: http://jira.codehaus.org/browse/MRELEASE-583 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Affects Versions: 2.0 Reporter: nicola sinapsi Attachments: better-snapshot-dependency.patch The plugin has a simple snapshot dependency resolution mechanism. When a snapshot dependency is found, it allows for setting it to release... but it does not allows to choice the release version to use: code Resolve Project Dependency Snapshots.: 'com.sinapsi.libs:sinapsi-commons' set to release? (yes/no) yes: : yes What is the next development version? (2.1.3-SNAPSHOT) 2.1.3-SNAPSHOT: : /code in this case the versions are: current: 2.1.2-SNAPSHOT release: 2.1.2 next: 2.1.3-SNAPSHOT The problem is that the only allowed development version is 2.1.3-SNAPSHOT (the value between the parentheses), hence the only allowed release version is 2.1.2. Notably, you cannot specify an OLDER relase (such as 2.1.1): this means you are forced to release the dependency (you cannot use an already released version). It would be better to ask for the release version to use, and then set the snapshot as the release following the release version specified by the user: code Resolve Project Dependency Snapshots.: 'com.sinapsi.libs:sinapsi-commons' set to release? (yes/no) yes: : yes What is the release version? 2.1.2: : 2.3.0 /code in this case the versions are: current: 2.1.2-SNAPSHOT release: 2.3.0 next: 2.3.1-SNAPSHOT The plugin suggests to set the release version to 2.1.2, but the user can choice another version, eventually an already released version. -- 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-583) Better Snapshot Dependency Handling
[ http://jira.codehaus.org/browse/MRELEASE-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=230317#action_230317 ] nicola sinapsi edited comment on MRELEASE-583 at 7/30/10 5:26 AM: -- I have attached a patch with the enhancement, and corrected the corresponding test (CheckDependencySnapshotsPhaseTest). The patch is pretty straightforward. I could not check whether all the integration tests are still working since i didn't succed in running all of them. was (Author: naaki): I have attached a patch with the enhancement, and corrected the corresponding test (CheckDependencySnapshotsPhaseTest). The patch is pretty straightforward. I could check whether all the integration tests are still working since i didn't succed in running all of them. Better Snapshot Dependency Handling --- Key: MRELEASE-583 URL: http://jira.codehaus.org/browse/MRELEASE-583 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Affects Versions: 2.0 Reporter: nicola sinapsi Attachments: better-snapshot-dependency.patch The plugin has a simple snapshot dependency resolution mechanism. When a snapshot dependency is found, it allows for setting it to release... but it does not allows to choice the release version to use: code Resolve Project Dependency Snapshots.: 'com.sinapsi.libs:sinapsi-commons' set to release? (yes/no) yes: : yes What is the next development version? (2.1.3-SNAPSHOT) 2.1.3-SNAPSHOT: : /code in this case the versions are: current: 2.1.2-SNAPSHOT release: 2.1.2 next: 2.1.3-SNAPSHOT The problem is that the only allowed development version is 2.1.3-SNAPSHOT (the value between the parentheses), hence the only allowed release version is 2.1.2. Notably, you cannot specify an OLDER relase (such as 2.1.1): this means you are forced to release the dependency (you cannot use an already released version). It would be better to ask for the release version to use, and then set the snapshot as the release following the release version specified by the user: code Resolve Project Dependency Snapshots.: 'com.sinapsi.libs:sinapsi-commons' set to release? (yes/no) yes: : yes What is the release version? 2.1.2: : 2.3.0 /code in this case the versions are: current: 2.1.2-SNAPSHOT release: 2.3.0 next: 2.3.1-SNAPSHOT The plugin suggests to set the release version to 2.1.2, but the user can choice another version, eventually an already released version. -- 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-4744) Validate coordinates of dependency exclusions
Validate coordinates of dependency exclusions - Key: MNG-4744 URL: http://jira.codehaus.org/browse/MNG-4744 Project: Maven 2 3 Issue Type: Improvement Components: Dependencies, POM Affects Versions: 3.0-beta-1 Reporter: Benjamin Bentmann Priority: Minor The coordinates for exclusons should be subject to the same validation as dependencies, i.e. groupIdartifactId should be valid IDs. Maven itself doesn't care, but a typo in there or an attempt to use wildcards will cause surprises to users so let's emit a warning. -- 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: (ARCHETYPE-304) problem with mvn archetype:generate for ear-jee5 (168)
[
http://jira.codehaus.org/browse/ARCHETYPE-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=230320#action_230320
]
Helge Tesgaard commented on ARCHETYPE-304:
--
When you execute:
mvn --debug archetype:generate -DgroupId=some groupId -DartifactId=some
artifactId
you see:
[DEBUG] Searching for META-INF/archetype.xml inside
C:\dokumenter\.m2\repository\org\codehaus\mojo\archetypes\ear-jee5\1.0\ear-jee5-1.0.jar
[DEBUG] - META-INF/
[DEBUG] - META-INF/MANIFEST.MF
[DEBUG] - archetype-resources/
[DEBUG] - archetype-resources/src/
[DEBUG] - archetype-resources/src/main/
[DEBUG] - archetype-resources/src/main/application/
[DEBUG] - archetype-resources/src/main/application/META-INF/
[DEBUG] - META-INF/maven/
[DEBUG] - archetype-resources/src/main/application/META-INF/MANIFEST.MF
[DEBUG] - archetype-resources/pom.xml
[DEBUG] - META-INF/maven/archetype-metadata.xml
[DEBUG] - META-INF/maven/org.codehaus.mojo.archetypes/
[DEBUG] - META-INF/maven/org.codehaus.mojo.archetypes/ear-jee5/
[DEBUG] - META-INF/maven/org.codehaus.mojo.archetypes/ear-jee5/pom.xml
[DEBUG] - META-INF/maven/org.codehaus.mojo.archetypes/ear-jee5/pom.properties
[DEBUG] No found META-INF/archetype.xml retrying with windows path separator.
This seams to indicate indicates that META-INF/archetype.xml is now moved to
META-INF/maven/archetype-metadata.xml
Environment:
C:\source\svn\SingleSignOnmvn -version
Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_14
Java home: C:\dokumenter\java\jdk1.6.0_14\jre
Default locale: da_DK, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 Family: windows
problem with mvn archetype:generate for ear-jee5 (168)
Key: ARCHETYPE-304
URL: http://jira.codehaus.org/browse/ARCHETYPE-304
Project: Maven Archetype
Issue Type: Bug
Components: Generator
Environment: Maven version: 2.0.10
Java version: 1.6.0_12
OS name: linux version: 2.6.26.8-57.fc8 arch: i386 Family: unix
Reporter: vincent laugier
Hello,
when calling 'mvn archetype:generate'
{noformat}
Choose a number: 58: 168
Choose version:
1: 1.0
2: 1.0.1
Choose a number: : 1
[ERROR] Cannot parse archetype descriptor
org.codehaus.plexus.util.xml.pull.XmlPullParserException: Unknown attribute
'id' for tag 'archetype-descriptor' (position: START_TAG seen ...escriptor
id=ear-jee5 partial=false name=JEE5 EAR archetype... @2:79)
at
org.apache.maven.archetype.metadata.io.xpp3.ArchetypeDescriptorXpp3Reader.checkUnknownAttribute(ArchetypeDescriptorXpp3Reader.java:99)
at
org.apache.maven.archetype.metadata.io.xpp3.ArchetypeDescriptorXpp3Reader.parseArchetypeDescriptor(ArchetypeDescriptorXpp3Reader.java:579)
at
org.apache.maven.archetype.metadata.io.xpp3.ArchetypeDescriptorXpp3Reader.read(ArchetypeDescriptorXpp3Reader.java:1212)
at
org.apache.maven.archetype.metadata.io.xpp3.ArchetypeDescriptorXpp3Reader.read(ArchetypeDescriptorXpp3Reader.java:1141)
at
org.apache.maven.archetype.common.DefaultArchetypeArtifactManager.loadFileSetArchetypeDescriptor(DefaultArchetypeArtifactManager.java:477)
at
org.apache.maven.archetype.common.DefaultArchetypeArtifactManager.isFileSetArchetype(DefaultArchetypeArtifactManager.java:455)
at
org.apache.maven.archetype.common.DefaultArchetypeArtifactManager.isFileSetArchetype(DefaultArchetypeArtifactManager.java:187)
at
org.apache.maven.archetype.common.DefaultArchetypeArtifactManager.isFileSetArchetype(DefaultArchetypeArtifactManager.java:215)
at
org.apache.maven.archetype.ui.DefaultArchetypeGenerationConfigurator.configureArchetype(DefaultArchetypeGenerationConfigurator.java:141)
at
org.apache.maven.archetype.mojos.CreateProjectFromArchetypeMojo.execute(CreateProjectFromArchetypeMojo.java:188)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:228)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at
[jira] Closed: (MNG-4744) Validate coordinates of dependency exclusions
[ http://jira.codehaus.org/browse/MNG-4744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4744. -- Resolution: Fixed Fix Version/s: 3.0-beta-2 Assignee: Benjamin Bentmann Done in [r980725|http://svn.apache.org/viewvc?view=revisionrevision=980725]. Validate coordinates of dependency exclusions - Key: MNG-4744 URL: http://jira.codehaus.org/browse/MNG-4744 Project: Maven 2 3 Issue Type: Improvement Components: Dependencies, POM Affects Versions: 3.0-beta-1 Reporter: Benjamin Bentmann Assignee: Benjamin Bentmann Priority: Minor Fix For: 3.0-beta-2 The coordinates for exclusons should be subject to the same validation as dependencies, i.e. groupIdartifactId should be valid IDs. Maven itself doesn't care, but a typo in there or an attempt to use wildcards will cause surprises to users so let's emit a warning. -- 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-536) CommonBasedir Calculation fails on windows
[ http://jira.codehaus.org/browse/MRELEASE-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=230329#action_230329 ] Francis De Brabandere commented on MRELEASE-536: here is a stacktrace: java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1937) at org.apache.maven.shared.release.util.ReleaseUtil.getCommonBasedir(ReleaseUtil.java:206) at org.apache.maven.shared.release.util.ReleaseUtil.getCommonBasedir(ReleaseUtil.java:177) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformDocument(AbstractRewritePomsPhase.java:303) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:208) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:114) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execute(AbstractRewritePomsPhase.java:97) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:203) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:140) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:103) at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:211) at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:181) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) 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) CommonBasedir Calculation fails on windows -- Key: MRELEASE-536 URL: http://jira.codehaus.org/browse/MRELEASE-536 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.0 Reporter: Matthias Vach Attachments: patchfile.patch The method getCommonBasedir in class org.apache.maven.shared.release.util.ReleaseUtil runs into the Exception:\\ java.lang.StringIndexOutOfBoundsException: String index out of range: -1 ... while comparing pathes with small and capital lettes for Windows drives. e.g.: C:\WoRkInG\root\project1 has no common base dir with c:\working\root\project2\\ but it should have c:\working\root as common base directory. A patch and a test for that bug is attached. I do have the problem with version 2.0 but I fixed it in trunk for now Regards Matthias -- 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-492) publishDate position=bottom doesn't work
[ http://jira.codehaus.org/browse/MSITE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=230330#action_230330 ] Aaron Digulla commented on MSITE-492: - Sorry, PEBKAC. Thanks. :-) publishDate position=bottom doesn't work -- Key: MSITE-492 URL: http://jira.codehaus.org/browse/MSITE-492 Project: Maven 2.x Site Plugin Issue Type: Bug Components: site descriptor Affects Versions: 2.1.1 Reporter: Aaron Digulla In the file default-site.vm is a call for the macro #publishDate with the parameter buttom but this value isn't used in the macro 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] Closed: (MSITE-492) publishDate position=bottom doesn't work
[ http://jira.codehaus.org/browse/MSITE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Digulla closed MSITE-492. --- Resolution: Not A Bug Fix Version/s: 2.1.1 There was an additional head element around the publishDate element. publishDate position=bottom doesn't work -- Key: MSITE-492 URL: http://jira.codehaus.org/browse/MSITE-492 Project: Maven 2.x Site Plugin Issue Type: Bug Components: site descriptor Affects Versions: 2.1.1 Reporter: Aaron Digulla Fix For: 2.1.1 In the file default-site.vm is a call for the macro #publishDate with the parameter buttom but this value isn't used in the macro 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-530) Git provider does 'git push' during 'mvn release:prepare' which causes unwanted problems (scm 1.4 upgrade)
[ http://jira.codehaus.org/browse/MRELEASE-530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=230364#action_230364 ] Olivier Lamy commented on MRELEASE-530: --- Ok I reproduce. I will investigate. Git provider does 'git push' during 'mvn release:prepare' which causes unwanted problems (scm 1.4 upgrade) -- Key: MRELEASE-530 URL: http://jira.codehaus.org/browse/MRELEASE-530 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: scm Reporter: Olivier Lamy Assignee: Olivier Lamy Priority: Minor Fix For: 2.1 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 new-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 currentbranch:currentbranch', 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] Closed: (MRELEASE-551) Unable to release with maven 3 when having no $HOME/.m2/settings.xml
[ http://jira.codehaus.org/browse/MRELEASE-551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MRELEASE-551. -- Resolution: Fixed Fix Version/s: 2.1 Assignee: Benjamin Bentmann Made plugin more careful in [r980883|http://svn.apache.org/viewvc?view=revisionrevision=980883]. The other half of this issues lies actually in the core of Maven 3 which supplies the path to the non-existing file. Unable to release with maven 3 when having no $HOME/.m2/settings.xml Key: MRELEASE-551 URL: http://jira.codehaus.org/browse/MRELEASE-551 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.0-beta-8, 2.0-beta-9, 2.0 Reporter: Baptiste MATHUS Assignee: Benjamin Bentmann Fix For: 2.1 I've recently tried to release a small remote-resources project, but couldn't do it with mvn3. After some look-up, it seems to be the result of several changes: * I don't have any $HOME/.m2/settings.xml (only the $M2_HOME/conf/settings.xml is present and configured). * From the 2.0-beta-8 of the release plugin, it now uses the -s option during the prepare phase * from the mvn3.0-alpha-3, maven now don't ignore silently the absence of a settings.xml file specified with the -s option (see MNG-4408) To reproduce, try to run release:prepare with mvn3 without having a user settings.xml. Let me know if you need more information. Cheers -- 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-566) During release the tag is pushed to 'origin' instead of the remote repo specified in developerConnection
During release the tag is pushed to 'origin' instead of the remote repo specified in developerConnection Key: SCM-566 URL: http://jira.codehaus.org/browse/SCM-566 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Reporter: Carlo de Wolf I have origin pointing to http://github.com/wolfc/jboss-ejb3-bom-eap5 while upstream points to http://github.com/jbossejb3/jboss-ejb3-bom-eap5 During the release of http://github.com/jbossejb3/jboss-ejb3-bom-eap5/blob/bom-eap5-0.1.3/pom.xml the tag was pushed to origin, not upstream. -- 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-492) Reopen of MASSEMBLY-126 : DependencySet: Jars with scope runtime not assembled anymore
Reopen of MASSEMBLY-126 : DependencySet: Jars with scope runtime not assembled anymore -- Key: MASSEMBLY-492 URL: http://jira.codehaus.org/browse/MASSEMBLY-492 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-5, 2.2-beta-4, 2.2-beta-3 Environment: Windows XP, maven 2.2.1 Reporter: Pinson Pierre-Marie Before I used 2.2-beta-1 version of assembly plugin to create my binary, and it worked well. Today I upgraded the plugin to version 2.2-beta-5. There is a difference in the treatment of scope runtime in dependancySet. The libraries of this scope are not included in the archive. I tested 2.2-beta-4 and 2.2-beta-3, is the same problem. In 2.2-beta-2, it work. -- 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-4745) [regression] Maven does not check for plugin updates, even if forced via -U
[regression] Maven does not check for plugin updates, even if forced via -U --- Key: MNG-4745 URL: http://jira.codehaus.org/browse/MNG-4745 Project: Maven 2 3 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 3.0-beta-1 Reporter: Benjamin Bentmann Priority: Minor Trying to bring the (currently disabled) IT MavenIT0109ReleaseUpdateTest back into shape revealed an actual issue with the plugin version resolution. Once Maven 3.0-beta-1 resolved a plugin version, it will never ever refetch the corresponding g:a-level metadata (unless completely removed from the local 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] Commented: (MCHANGES-190) HTML in changes.xml stopped working
[ http://jira.codehaus.org/browse/MCHANGES-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=230409#action_230409 ] Jörg Hohwiller commented on MCHANGES-190: - IMHO adding markup as text in CDATA sections was always a hack. The best way to fix this would be to allow xsd:any in action and put the content as is in the result. Then we also do not need a trigger as commented in Dennis Lundberg added a comment - 21/Dec/09 2:31 PM because one can still have plain text in CDATA and does not need to care about escaping. HTML in changes.xml stopped working --- Key: MCHANGES-190 URL: http://jira.codehaus.org/browse/MCHANGES-190 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: changes-report Affects Versions: 2.3 Environment: Maven version: 2.0.10 Java version: 1.5.0_17 OS name: linux version: 2.6.32-686 arch: i386 Family: unix Reporter: Christian Schulte Priority: Critical Attachments: changes.xml, changes.xml, MCHANGES-190.zip The fix for MCHANGES-189 does not seem to be correct. A changes.xml file containing HTML-Tags got rendered correctly using version 2.2. Starting with version 2.3, HTML-Tags will be encoded using HTML entities for the '' and '' characters leading to the actual tags getting shown in the report. See the attached example changes.xml file containing HTML no longer working with version 2.3. -- 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: (MANTTASKS-197) Dependency with packaging=pom shows up in the classpath
[
http://jira.codehaus.org/browse/MANTTASKS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=230419#action_230419
]
Knut Forkalsrud commented on MANTTASKS-197:
---
If I apply the following patch I get the behavior I want.
{noformat}
--- src/main/java/org/apache/maven/artifact/ant/DependenciesTask.java HEAD
+++ src/main/java/org/apache/maven/artifact/ant/DependenciesTask.java
2010-07-30 15:51:08.0 -0700
@@ -479,7 +479,11 @@
if ( path != null )
{
-path.addFileset( artifactFileSet );
+if ( jar.equals( artifact.getArtifactHandler().getPackaging() )
) {
+path.addFileset( artifactFileSet );
+} else {
+log( Not adding POM artifact to classpath: +
artifact.getArtifactHandler().getPackaging() + + artifact.getGroupId() +
: + artifact.getArtifactId() );
+}
}
}
{noformat}
Dependency with packaging=pom shows up in the classpath
---
Key: MANTTASKS-197
URL: http://jira.codehaus.org/browse/MANTTASKS-197
Project: Maven 2.x Ant Tasks
Issue Type: Bug
Components: dependencies task
Affects Versions: 2.1.1
Environment: Mac OSX, Ant 1.8.1
Reporter: Knut Forkalsrud
My use case is that I have a set of common dependencies that I use across
many projects.
In order to save me some typing I created a pom whose sole purpose is to
depend on all
the common dependencies, so that each of my projects can depend on only this
one pom.
The problem is that the pom file gets included in the classpath, an the junit
task shows
an annoying error because it can't make sense of it as a directory or jar
file.
A relatively simple testcase to show the issue is this pom.xml:
{code:xml}project xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
modelVersion4.0.0/modelVersion
groupIdfoo/groupId
artifactIdbar/artifactId
version1.0/version
dependencies
dependency
groupIdasm/groupId
artifactIdasm-parent/artifactId
version3.1/version
typepom/type
/dependency
/dependencies
/project
{code}
An the following build.xml in the same directory:
{code:xml}
?xml version=1.0 encoding=UTF-8?
project name=foo default=test
xmlns:artifact=antlib:org.apache.maven.artifact.ant
target name=test
artifact:pom file=${basedir}/pom.xml id=maven.project/
artifact:dependencies pathId=maven2.test.classpath
filesetId=test.fileset
pom refid=maven.project/
/artifact:dependencies
echo${toString:maven2.test.classpath}/echo
/target
/project
{code}
When I run this I expect the output from echo to list the classpath
consisting of the jars dependencies from {{asm-parent}}. That pom happens to
have no jar dependencies, so I expect the output to be empty. Instead I get
the path of the pom file.
In a more realistic example I will use this as a classpath argument to
junit and get an error like:
{noformat}
Unable to obtain resource from
/Users/knut/.m2/repository/asm/asm-parent/3.1/asm-parent-3.1.pom:
java.util.zip.ZipException: error in opening zip file
[junit] Unable to obtain resource from
/Users/knut/.m2/repository/asm/asm-parent/3.1/asm-parent-3.1.pom:
[junit] java.util.zip.ZipException: error in opening zip file
[junit] at java.util.zip.ZipFile.open(Native Method)
[junit] at java.util.zip.ZipFile.init(ZipFile.java:114)
[junit] at java.util.jar.JarFile.init(JarFile.java:135)
[junit] at java.util.jar.JarFile.init(JarFile.java:99)
[junit] at
org.apache.tools.ant.AntClassLoader.getResourceURL(AntClassLoader.java:1002)
[junit] at
org.apache.tools.ant.AntClassLoader$ResourceEnumeration.findNextResource(AntClassLoader.java:145)
[junit] at
org.apache.tools.ant.AntClassLoader$ResourceEnumeration.init(AntClassLoader.java:109)
[junit] at
org.apache.tools.ant.AntClassLoader.findResources(AntClassLoader.java:949)
[junit] at
org.apache.tools.ant.AntClassLoader.getNamedResources(AntClassLoader.java:918)
[junit] at
org.apache.tools.ant.loader.AntClassLoader5.getResources(AntClassLoader5.java:54)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.checkForkedPath(JUnitTask.java:1135)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeAsForked(JUnitTask.java:1011)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:811)
[junit] at
[jira] Updated: (MANTTASKS-197) Dependency with packaging=pom shows up in the classpath
[
http://jira.codehaus.org/browse/MANTTASKS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Forkalsrud updated MANTTASKS-197:
--
Attachment: MANTTASKS-197.zip
Attached is a more comprehensive example.
It is just some silly code to test.
When I fork the junit task to execute the unit test I get the annoying stack
trace.
There are maven2 build files as well as ant build files.
Extract the archive somewhere, cd into MANTTASKS-197 and run
{{mvn clean test}}
{{ant clean test}}
and compare.
Dependency with packaging=pom shows up in the classpath
---
Key: MANTTASKS-197
URL: http://jira.codehaus.org/browse/MANTTASKS-197
Project: Maven 2.x Ant Tasks
Issue Type: Bug
Components: dependencies task
Affects Versions: 2.1.1
Environment: Mac OSX, Ant 1.8.1
Reporter: Knut Forkalsrud
Attachments: MANTTASKS-197.zip
My use case is that I have a set of common dependencies that I use across
many projects.
In order to save me some typing I created a pom whose sole purpose is to
depend on all
the common dependencies, so that each of my projects can depend on only this
one pom.
The problem is that the pom file gets included in the classpath, an the junit
task shows
an annoying error because it can't make sense of it as a directory or jar
file.
A relatively simple testcase to show the issue is this pom.xml:
{code:xml}project xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
modelVersion4.0.0/modelVersion
groupIdfoo/groupId
artifactIdbar/artifactId
version1.0/version
dependencies
dependency
groupIdasm/groupId
artifactIdasm-parent/artifactId
version3.1/version
typepom/type
/dependency
/dependencies
/project
{code}
An the following build.xml in the same directory:
{code:xml}
?xml version=1.0 encoding=UTF-8?
project name=foo default=test
xmlns:artifact=antlib:org.apache.maven.artifact.ant
target name=test
artifact:pom file=${basedir}/pom.xml id=maven.project/
artifact:dependencies pathId=maven2.test.classpath
filesetId=test.fileset
pom refid=maven.project/
/artifact:dependencies
echo${toString:maven2.test.classpath}/echo
/target
/project
{code}
When I run this I expect the output from echo to list the classpath
consisting of the jars dependencies from {{asm-parent}}. That pom happens to
have no jar dependencies, so I expect the output to be empty. Instead I get
the path of the pom file.
In a more realistic example I will use this as a classpath argument to
junit and get an error like:
{noformat}
Unable to obtain resource from
/Users/knut/.m2/repository/asm/asm-parent/3.1/asm-parent-3.1.pom:
java.util.zip.ZipException: error in opening zip file
[junit] Unable to obtain resource from
/Users/knut/.m2/repository/asm/asm-parent/3.1/asm-parent-3.1.pom:
[junit] java.util.zip.ZipException: error in opening zip file
[junit] at java.util.zip.ZipFile.open(Native Method)
[junit] at java.util.zip.ZipFile.init(ZipFile.java:114)
[junit] at java.util.jar.JarFile.init(JarFile.java:135)
[junit] at java.util.jar.JarFile.init(JarFile.java:99)
[junit] at
org.apache.tools.ant.AntClassLoader.getResourceURL(AntClassLoader.java:1002)
[junit] at
org.apache.tools.ant.AntClassLoader$ResourceEnumeration.findNextResource(AntClassLoader.java:145)
[junit] at
org.apache.tools.ant.AntClassLoader$ResourceEnumeration.init(AntClassLoader.java:109)
[junit] at
org.apache.tools.ant.AntClassLoader.findResources(AntClassLoader.java:949)
[junit] at
org.apache.tools.ant.AntClassLoader.getNamedResources(AntClassLoader.java:918)
[junit] at
org.apache.tools.ant.loader.AntClassLoader5.getResources(AntClassLoader5.java:54)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.checkForkedPath(JUnitTask.java:1135)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeAsForked(JUnitTask.java:1011)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:811)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeOrQueue(JUnitTask.java:1808)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:760)
[junit] at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
[junit] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
[junit] at
[jira] Created: (MARCHETYPES-34) Release maven-archetype-quickstart 1.2 with explicit source level
Release maven-archetype-quickstart 1.2 with explicit source level - Key: MARCHETYPES-34 URL: http://jira.codehaus.org/browse/MARCHETYPES-34 Project: Maven Archetype Bundles Issue Type: Task Components: Maven Quickstart Archetype Affects Versions: 1.1 Reporter: Jesse Glick Please consider doing a release soon of maven-archetype-quickstart 1.2, especially for the explicit source level. MCOMPILER-80 means that Maven 3 will be passing -source 1.5 rather than -source 1.3 by default, which could be a confusing discrepancy for developers who do not realize they should specify a source level (especially given the lack of a warning as recommended by MCOMPILER-125). -- 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-4579) Maven Wagon SSH does not mask password
[
http://jira.codehaus.org/browse/MNG-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=230432#action_230432
]
Heinrich Schuchardt commented on MNG-4579:
--
Had a quick look at it, problem is located inside plexus-interactivity-api
dependency, which handles readPassword() the same way like readLine().
Do you refer to:
// revision 7276
package org.codehaus.plexus.components.interactivity.jline;
import jline.ConsoleReader;
public class JLineInputHandler
public String readPassword()
throws IOException {
return consoleReader.readLine( new Character( '*' ) );
}
public String readLine()
throws IOException {
return consoleReader.readLine();
}
Maven Wagon SSH does not mask password
--
Key: MNG-4579
URL: http://jira.codehaus.org/browse/MNG-4579
Project: Maven 2 3
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.2.1
Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_17
Java home: C:\program Files\Java\jdk1.6.0_17\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Heinrich Schuchardt
Priority: Minor
I am using
mvn site:deploy
with scp as protocol.
When uploading mvn asks for the ssh password. The password is displayed
instead of being masked by .
To reproduce the issue try the following:
mvn wagon:upload-single -Dwagon.fromFile=c:\temp\test.mhtml
-Dwagon.url=scp:www.myserver.com/home/myuser/temp
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'wagon'.
[INFO]
[INFO] Building Io
[INFO]task-segment: [wagon:upload-single] (aggregator-style)
[INFO]
[INFO] [wagon:upload-single {execution: default-cli}]
Password for myu...@www.myserver.com: password
--
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
