[jira] Commented: (SUREFIRE-615) Surefire providers shouldn't need to download old versions of the library
[ http://jira.codehaus.org/browse/SUREFIRE-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=231433#action_231433 ] Stephen Connolly commented on SUREFIRE-615: --- r983549 reverse merged r982995 Surefire providers shouldn't need to download old versions of the library - Key: SUREFIRE-615 URL: http://jira.codehaus.org/browse/SUREFIRE-615 Project: Maven Surefire Issue Type: Improvement Components: JUnit 3.x support, Junit 4.x support, Maven Surefire Plugin, TestNG support Affects Versions: 2.5 Reporter: Brett Porter Assignee: Stephen Connolly Fix For: 2.6 currently, the Surefire plugin uses resolveTransitively to obtain the Surefire provider (junit, junit4, junit47, testng). Each of these has a compile time dependency on the library itself to interact with their API. This results in downloading older versions as well as the newer one requested by the project (TestNG 5.7, JUnit 4.0, JUnit 3.8.1). There are two possible solutions to this: - alter the resolveTranstively method to exclude the artifact that is already available from the project - set the dependency to 'provided' in the providers POM -- 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-523) ReleaseUtil throws java.lang.StringIndexOutOfBoundsException: String index out of range: -1
[
http://jira.codehaus.org/browse/MRELEASE-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=231435#action_231435
]
Conny Kreyßel commented on MRELEASE-523:
Any news on this issue?
We must rollback our internal company parent to 2.0-beta9 ...
ReleaseUtil throws java.lang.StringIndexOutOfBoundsException: String index
out of range: -1
-
Key: MRELEASE-523
URL: http://jira.codehaus.org/browse/MRELEASE-523
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0
Environment: Windows XP, Maven 2.2.1
Reporter: Ulrich Hofstötter
Attachments: log.txt
Hello,
i have an issue using the maven release plugin 2.0, previous versions did not
have this issue.
In a multimodule project, release:prepare exits with the attached stack trace.
After a litte debugging, i found out that in ReleaseUtil, line 188
String dir = FileUtils.normalize( p.getBasedir().getPath().replace( '\\', '/'
) );
returns c:\... for the parent module, but C:\... for the first submodule.
So in line 202
basedir = StringUtils.getCommonPrefix( new String[]{dir, basedir} );
results in an empty String, which leads to the exception in line 206.
I will try to compose a simple example as soon as possible.
--
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: (MPDF-40) When using findbugs-maven-plugin pdf report generation fails with afatal error
[ http://jira.codehaus.org/browse/MPDF-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=231437#action_231437 ] Espen Skogen commented on MPDF-40: -- Bug raised for findbugs: http://jira.codehaus.org/browse/MFINDBUGS-116 When using findbugs-maven-plugin pdf report generation fails with afatal error -- Key: MPDF-40 URL: http://jira.codehaus.org/browse/MPDF-40 Project: Maven 2.x PDF Plugin Issue Type: Bug Affects Versions: 1.2 Environment: Windows XP Java 1.6 Reporter: Espen Skogen Attachments: error.log When using findbugs-maven-plugin v 2.3.2-SNAPSHOT a fatal error occurs when attempting PDF generation. -- 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: (DOXIA-400) Velocity 1.5 can't parse default-site.vm
[
http://jira.codehaus.org/browse/DOXIA-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=231442#action_231442
]
Lukas Theussl commented on DOXIA-400:
-
Velocity 1.7 doesn't seem to be available on central yet? I tried with 1.6.4,
got some errors that I fixed by replacing things like
{noformat}
replaceAll( \\, / )
{noformat}
by
{noformat}
replaceAll( '\\', '/' )
{noformat}
but no problem with the line you quote above.
Velocity 1.5 can't parse default-site.vm
--
Key: DOXIA-400
URL: http://jira.codehaus.org/browse/DOXIA-400
Project: Maven Doxia
Issue Type: Improvement
Components: Doc renderer, Site renderer
Affects Versions: 1.0, 1.1
Reporter: Stefan Bodewig
Priority: Minor
This is an issue detected by Gump which runs Maven builds but replaces
dependencies with the trunk versions of things built by Gump rather than the
version a project asks for.
The Cargo build - see
http://gump.zones.apache.org/gump/test/cargo/cargo/gump_work/build_cargo_cargo.html
- fails because Velocity doesn't like the line
#set ( $documentHeader = ?xml version=\1.0\ encoding=\UTF-8\? )
because \ is not an escape sequence for Velocity (anymore?).
I've taken this to the velocity list -
http://mail-archives.apache.org/mod_mbox/velocity-dev/201008.mbox/%3c87ocdlps07@v35516.1blu.de%3e
- and received the feedback that backslash
escaping was not supported - and likely never has been - and you should
either use single
quotes inside the double quotes or use something like
#set( $Q = '' )
#set ( $documentHeader = ?xml version= + $Q + 1.0 + $Q + ...
I realize that it probably works for you right now using Velocity 1.5, that's
why I used Improvement rather than bug as category. Still it may be worth to
find a solution that works for the version of Velocity you want to use as
well as future versions.
--
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] Moved: (DOXIASITETOOLS-39) Velocity 1.5 can't parse default-site.vm
[ http://jira.codehaus.org/browse/DOXIASITETOOLS-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl moved DOXIA-400 to DOXIASITETOOLS-39: --- Component/s: (was: Site Renderer) Site renderer Doc renderer Affects Version/s: (was: 1.0) 1.0 1.1 Key: DOXIASITETOOLS-39 (was: DOXIA-400) Project: Maven Doxia Sitetools (was: Maven Doxia) Velocity 1.5 can't parse default-site.vm -- Key: DOXIASITETOOLS-39 URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-39 Project: Maven Doxia Sitetools Issue Type: Improvement Components: Doc renderer, Site renderer Affects Versions: 1.1, 1.0 Reporter: Stefan Bodewig Priority: Minor This is an issue detected by Gump which runs Maven builds but replaces dependencies with the trunk versions of things built by Gump rather than the version a project asks for. The Cargo build - see http://gump.zones.apache.org/gump/test/cargo/cargo/gump_work/build_cargo_cargo.html - fails because Velocity doesn't like the line #set ( $documentHeader = ?xml version=\1.0\ encoding=\UTF-8\? ) because \ is not an escape sequence for Velocity (anymore?). I've taken this to the velocity list - http://mail-archives.apache.org/mod_mbox/velocity-dev/201008.mbox/%3c87ocdlps07@v35516.1blu.de%3e - and received the feedback that backslash escaping was not supported - and likely never has been - and you should either use single quotes inside the double quotes or use something like #set( $Q = '' ) #set ( $documentHeader = ?xml version= + $Q + 1.0 + $Q + ... I realize that it probably works for you right now using Velocity 1.5, that's why I used Improvement rather than bug as category. Still it may be worth to find a solution that works for the version of Velocity you want to use as well as future versions. -- 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-524) command line versions don't seem to work on release:branch for specific format
[ http://jira.codehaus.org/browse/MRELEASE-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=231443#action_231443 ] Lars Corneliussen commented on MRELEASE-524: I created a new patch and also included test cases. http://lcorneliussen.de/utils/git-svn/github.com/lcorneliussen/maven-release/commits/MRELEASE-524-batch-mode command line versions don't seem to work on release:branch for specific format Key: MRELEASE-524 URL: http://jira.codehaus.org/browse/MRELEASE-524 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.0 Environment: maven 2.2.1 Reporter: Max Schaefer I have tried passing versions for certain modules to the command line while making a branch. The plugin ignores my parameters when running release:branch. It injects the defaults if I pass parameters in batch mode. E.g. this command taken from the documentation does not work. mvn --batch-mode release:branch -DbranchName=my-branch-1.2 -Dproject.rel.org.myCompany:projectA=1.2 \ -Dproject.dev.org.myCompany:projectA=2.0-SNAPSHOT release:prepare supports this specific format for setting these values at command line. Setting these values in a release.properties file e.g. project.dev.org.myCompany\:projectA=2.0-SNAPSHOT project.rel.org.myCompany\:projectA=1.2 works also fine. Specifying the default at commandline works also e.g. mvn --batch-mode release:branch -DbranchName=my-branch-1.2 -DreleaseVersion=1.2 \ -DdevelopmentVersion=2.0-SNAPSHOT -- 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-524) command line versions don't seem to work on release:branch for specific format
[ http://jira.codehaus.org/browse/MRELEASE-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Corneliussen updated MRELEASE-524: --- Attachment: MRELEASE-524-batch-mode.patch Based on r983489 in https://svn.apache.org/repos/asf/maven/release/trunk Included commits: - [MRELEASE-524] Added test cases (by Lars Corneliussenm...@lcorneliussen.de on 09.08.2010 12:05:12) - [MRELEASE-524] command line versions don't seem to work on release:branch for specific format\n\no In interactive mode, the user was allways asked. Now he is only asked when the user did not specify versions explicitely. The fallback-suggestions on errors now are 1.0 for release, and 1.1-SNAPSHOT for development version. (by Lars Corneliussenm...@lcorneliussen.de on 05.05.2010 15:13:27) View changes online: http://github.com/lcorneliussen/maven-release/compare/473197249e1caf39ee2cee6d0efc8a288c30d0c3...2e99512130cf7c224b9c9fcedfef0b96448d1934 # created from http://lcorneliussen.de/utils/git-svn/github.com/lcorneliussen/maven-release/commits/MRELEASE-524-batch-mode command line versions don't seem to work on release:branch for specific format Key: MRELEASE-524 URL: http://jira.codehaus.org/browse/MRELEASE-524 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.0 Environment: maven 2.2.1 Reporter: Max Schaefer Attachments: MRELEASE-524-batch-mode.patch I have tried passing versions for certain modules to the command line while making a branch. The plugin ignores my parameters when running release:branch. It injects the defaults if I pass parameters in batch mode. E.g. this command taken from the documentation does not work. mvn --batch-mode release:branch -DbranchName=my-branch-1.2 -Dproject.rel.org.myCompany:projectA=1.2 \ -Dproject.dev.org.myCompany:projectA=2.0-SNAPSHOT release:prepare supports this specific format for setting these values at command line. Setting these values in a release.properties file e.g. project.dev.org.myCompany\:projectA=2.0-SNAPSHOT project.rel.org.myCompany\:projectA=1.2 works also fine. Specifying the default at commandline works also e.g. mvn --batch-mode release:branch -DbranchName=my-branch-1.2 -DreleaseVersion=1.2 \ -DdevelopmentVersion=2.0-SNAPSHOT -- 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-4758) lastUpdated file created for releases
[ http://jira.codehaus.org/browse/MNG-4758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4758. -- Resolution: Duplicate Assignee: Benjamin Bentmann You can specify -U on the command line to force a remote trip. lastUpdated file created for releases - Key: MNG-4758 URL: http://jira.codehaus.org/browse/MNG-4758 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories Environment: JAVA_HOME=/usr/lib/jvm/java-6-sun Apache Maven 3.0-beta-1 (r935667; 2010-04-19 13:00:39-0400) Java version: 1.6.0_20 Java home: /usr/lib/jvm/java-6-sun-1.6.0.20/jre Default locale: en_CA, platform encoding: UTF-8 OS name: linux version: 2.6.32-24-generic arch: i386 Family: unix Reporter: Mathieu Carbou Assignee: Benjamin Bentmann Priority: Blocker I have a project depending transitively on easymock 2.4 (http://repo2.maven.org/maven2/org/easymock/easymock/2.4/) When connecting to download the dependency, my network connection failed (for 5-10 seconds) which made maven stop with a connection timeout. The issue is that a file has been created on my local repo for this release: easymock-2.4.jar.lastUpdated So when i re-executed the mvn package command, Maven keeps stopping with the same error (connection timeout), whereas it is now came back and working. I understand the purpose of the lastUpdated file: for snapshots they are more than required. But i really don't understand why the lastUpdated is also applied to releases. If a project is deployed and depends on a release version, I think Maven should keep trying to get this dependency in all available repository until it is found, because it's an illegal state to not find it. Also, by working in a large company, I really think this lastUpdated file on releases could really prevent or slow down Maven 3 adoption since this is quite an annoying think that will slow down people and increase the work load of the maven support team (at least because Maven will report false-problems that could be now solved). Is there an option or something that could be temporary put somewhere to get back to the same Maven 2 behavior ? Thanks a lot, Mathieu. -- 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: (SUREFIRE-615) Surefire providers shouldn't need to download old versions of the library
[ http://jira.codehaus.org/browse/SUREFIRE-615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed SUREFIRE-615. - Resolution: Fixed r983577 Surefire providers shouldn't need to download old versions of the library - Key: SUREFIRE-615 URL: http://jira.codehaus.org/browse/SUREFIRE-615 Project: Maven Surefire Issue Type: Improvement Components: JUnit 3.x support, Junit 4.x support, Maven Surefire Plugin, TestNG support Affects Versions: 2.5 Reporter: Brett Porter Assignee: Stephen Connolly Fix For: 2.6 currently, the Surefire plugin uses resolveTransitively to obtain the Surefire provider (junit, junit4, junit47, testng). Each of these has a compile time dependency on the library itself to interact with their API. This results in downloading older versions as well as the newer one requested by the project (TestNG 5.7, JUnit 4.0, JUnit 3.8.1). There are two possible solutions to this: - alter the resolveTranstively method to exclude the artifact that is already available from the project - set the dependency to 'provided' in the providers POM -- 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-585) release:branch commits working copy changes even when -DupdateWorkingCopyVersions=false
[ http://jira.codehaus.org/browse/MRELEASE-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=231447#action_231447 ] Lars Corneliussen commented on MRELEASE-585: ups... I mixed up fixed versions with resolved so MRELEASE-458 is fine... I'll add the patch there. This issue can be closed as duplicate. release:branch commits working copy changes even when -DupdateWorkingCopyVersions=false --- Key: MRELEASE-585 URL: http://jira.codehaus.org/browse/MRELEASE-585 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.0 Reporter: Lars Corneliussen MRELEASE-471 and MRELEASE-458 already described the problem. The fixes made were only workarounds. Branch now commits the changes, then performs the release, and then it rolles back the changes made to the working copy. For SVN, if remoteTagging is false, it could create the branch from the workingcopy before checking it in. I'm working on a patch that I will submit soon. -- 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-585) release:branch commits working copy changes even when -DupdateWorkingCopyVersions=false
release:branch commits working copy changes even when -DupdateWorkingCopyVersions=false --- Key: MRELEASE-585 URL: http://jira.codehaus.org/browse/MRELEASE-585 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.0 Reporter: Lars Corneliussen MRELEASE-471 and MRELEASE-458 already described the problem. The fixes made were only workarounds. Branch now commits the changes, then performs the release, and then it rolles back the changes made to the working copy. For SVN, if remoteTagging is false, it could create the branch from the workingcopy before checking it in. I'm working on a patch that I will submit soon. -- 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-3228) Maven profile activation does not work when profile is defined in inherited 'parent' pom
[ http://jira.codehaus.org/browse/MNG-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=231452#action_231452 ] Sven Ludwig commented on MNG-3228: -- I have made the following observations with Maven 2.2.1. I have three poms, a parent, a child, and an aggregator. The aggregator includes the child directly as a module, but not the parent. The parent is the parent POM of the child. I am running the build with mvn clean install on the aggregator. I wrote a profile with a configuration of some plugins that are usually not applied within my project hierarchy, i.e. the occurrences of these plugins in the profile defined in the parent POM are the only ones. Therefore, when I run my build, I can easily see if the profile is in effect, since I can see whether not not the extra plugins were executed. In the following constellations, the profile was active during the build: 1.1 Activation via System Property defined in the parent. Profile not mentioned in the child at all. System Property set on the console. 1.2 Same activation via System Property defined in the parent and in the child. System Property set on the console. In this case however, the profile would also be active when building only the parent itself, an unwanted effect. 1.3 No explicit activation defined in the parent nor the child. Profile not mentioned in the child at all. Profile included in activeProfiles in settings.xml. In this case however, the profile would also be active when building only the parent itself, an unwanted effect. In the following constellations, the profile was NOT active during the build: 2.1 Activation via System Property defined in the parent. Profile not mentioned in the child. Maven Property set within the child. 2.2 No explicit activation defined in the parent. Activation via System Property defined in the child. Maven Property set within the child. It appears that the property resolving mechanism for the activation of plugins has already been changed for Maven 3. There, the normal Maven Properties are evaluated, not only the System Properties. I do not know if it has been considered to include this nice behavior also in Maven 2, I personally would like to see that. Maven profile activation does not work when profile is defined in inherited 'parent' pom Key: MNG-3228 URL: http://jira.codehaus.org/browse/MNG-3228 Project: Maven 2 3 Issue Type: Bug Affects Versions: 2.0.7 Reporter: tony nys Assignee: John Casey Fix For: 2.1.0 The goal is to activate a maven profile based on OS user name. When I create a standalone project with a profile activation, it works, however, when I define the profile in a parent pom, it is never activated. this works: ... profile idTONY/id activation property nameuser.name/name valueWINTONY/value /property /activation properties /properties So in this case, my profile is activated based on my OS user name [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'help'. [INFO] [INFO] Building Proj1 [INFO] task-segment: [help:active-profiles] (aggregator-style) [INFO] [INFO] [help:active-profiles] [INFO] Active Profiles for Project 'com.capgemini.be.proj1:parent:pom:4.0.2': The following profiles are active: - TONY (source: pom) -- However, if I now have the profiles definition in the parent pom, it doesn't work when I build a child project So the child project references the parent pom containing the profiles and the activation, but when it is built, the profile is not activated PARENT POM: ... profiles profile idTONY/id activation property nameuser.name/name valueWINTONY/value /property /activation properties ... CHILD POM (the one being built) project parent groupIdcom.capgemini.be.proj1/groupId artifactIdparent/artifactId version4.0.2/version /parent [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'help'. [INFO] [INFO] Building Proj1 Application [INFO] task-segment: [help:active-profiles] (aggregator-style) [INFO] [INFO] [help:active-profiles] [INFO] Active Profiles for Project 'com.capgemini.be.proj1:proj1-webapp:jar:4.0.2': There are no active profiles. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators:
[jira] Issue Comment Edited: (MNG-3228) Maven profile activation does not work when profile is defined in inherited 'parent' pom
[ http://jira.codehaus.org/browse/MNG-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=231452#action_231452 ] Sven Ludwig edited comment on MNG-3228 at 8/9/10 6:26 AM: -- I have made the following observations with Maven 2.2.1. I have three poms, a parent, a child, and an aggregator. The aggregator includes the child directly as a module, but not the parent. The parent is the parent POM of the child. I am running the build with mvn clean install on the aggregator. I wrote a profile with a configuration of some plugins that are usually not applied within my project hierarchy, i.e. the occurrences of these plugins in the profile defined in the parent POM are the only ones. Therefore, when I run my build, I can easily see if the profile is in effect, since I can see whether not not the extra plugins were executed. In the following constellations, the profile was active during the build: 1.1 Activation via System Property defined in the parent. Profile not mentioned in the child at all. System Property set on the console. In this case however, the profile would also be active when building only the parent itself, an unwanted effect. 1.2 Same activation via System Property defined in the parent and in the child. System Property set on the console. In this case however, the profile would also be active when building only the parent itself, an unwanted effect. 1.3 No explicit activation defined in the parent nor the child. Profile not mentioned in the child at all. Profile included in activeProfiles in settings.xml. In this case however, the profile would also be active when building only the parent itself, an unwanted effect. In the following constellations, the profile was NOT active during the build: 2.1 Activation via System Property defined in the parent. Profile not mentioned in the child. Maven Property set within the child. 2.2 No explicit activation defined in the parent. Activation via System Property defined in the child. Maven Property set within the child. It appears that the property resolving mechanism for the activation of plugins has already been changed for Maven 3. There, the normal Maven Properties are evaluated, not only the System Properties. I do not know if it has been considered to include this nice behavior also in Maven 2, I personally would like to see that. was (Author: sludwig): I have made the following observations with Maven 2.2.1. I have three poms, a parent, a child, and an aggregator. The aggregator includes the child directly as a module, but not the parent. The parent is the parent POM of the child. I am running the build with mvn clean install on the aggregator. I wrote a profile with a configuration of some plugins that are usually not applied within my project hierarchy, i.e. the occurrences of these plugins in the profile defined in the parent POM are the only ones. Therefore, when I run my build, I can easily see if the profile is in effect, since I can see whether not not the extra plugins were executed. In the following constellations, the profile was active during the build: 1.1 Activation via System Property defined in the parent. Profile not mentioned in the child at all. System Property set on the console. 1.2 Same activation via System Property defined in the parent and in the child. System Property set on the console. In this case however, the profile would also be active when building only the parent itself, an unwanted effect. 1.3 No explicit activation defined in the parent nor the child. Profile not mentioned in the child at all. Profile included in activeProfiles in settings.xml. In this case however, the profile would also be active when building only the parent itself, an unwanted effect. In the following constellations, the profile was NOT active during the build: 2.1 Activation via System Property defined in the parent. Profile not mentioned in the child. Maven Property set within the child. 2.2 No explicit activation defined in the parent. Activation via System Property defined in the child. Maven Property set within the child. It appears that the property resolving mechanism for the activation of plugins has already been changed for Maven 3. There, the normal Maven Properties are evaluated, not only the System Properties. I do not know if it has been considered to include this nice behavior also in Maven 2, I personally would like to see that. Maven profile activation does not work when profile is defined in inherited 'parent' pom Key: MNG-3228 URL: http://jira.codehaus.org/browse/MNG-3228 Project: Maven 2 3 Issue Type: Bug Affects Versions: 2.0.7 Reporter: tony nys Assignee: John Casey
[jira] Updated: (MRELEASE-458) Branch Does Not Honor updateWorkingCopyVersions Setting
[ http://jira.codehaus.org/browse/MRELEASE-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Corneliussen updated MRELEASE-458: --- Attachment: MRELEASE-458-dont-change-workingcopy.patch Based on r983489 in https://svn.apache.org/repos/asf/maven/release/trunk This fixes the original bug and adds the parameter (suppressCommitBeforeTag or suppressCommitBeforeBranch) that ensures no changes are made to the working copy at all. I had to split the ScmCommitPhase (was used twice) into two separate phases. One for the preparation (before a tag or branch is created) and one for cleanup (after tag or branch was created) in order to avoid rolling back something that hasn't happend :-) Online Diff Viewer: http://github.com/lcorneliussen/maven-release/compare/473197249e1caf39ee2cee6d0efc8a288c30d0c3...c9fc0baef2f52153040241cbc7c561dd87b9e97e h4. Included commits: - [MRELEASE-458] Working copy can now be protected from any commits in goals 'branch' and 'prepare' by using 'suppressCommitBeforeTag/Branch' (by Lars Corneliussenm...@lcorneliussen.de on 06.05.2010 15:26:51) - [MRELEASE-458] *Branch Does Not Honor updateWorkingCopyVersions Setting* - ScmCommitPhase now doesn't commit changes on the working copy for branches, where updateWorkingCopyVersions and remoteTagging are set to false. (by Lars Corneliussenm...@lcorneliussen.de on 05.05.2010 15:33:09) Created from http://lcorneliussen.de/utils/git-svn/github.com/lcorneliussen/maven-release/tree/MRELEASE-458-dont-change-workingcopy Branch Does Not Honor updateWorkingCopyVersions Setting --- Key: MRELEASE-458 URL: http://jira.codehaus.org/browse/MRELEASE-458 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.0-beta-7, 2.0-beta-9 Reporter: James Carman Fix For: 2.1 Attachments: MRELEASE-458-dont-change-workingcopy.patch, MRELEASE-458-test.diff I copied the following command line from the documentation site (http://maven.apache.org/plugins/maven-release-plugin/examples/branch.html): mvn release:branch -DbranchName=my-branch -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false I have used this method in the past to cut a milestone release from our trunk. However, it seems that the working copy is actually being modified now. Has there been a newer release or something? -- 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-586) release:perform - The temporary file pom.xml.branch should be ignored as pom.xml.next and pom.xml.tag are ignored
release:perform - The temporary file pom.xml.branch should be ignored as pom.xml.next and pom.xml.tag are ignored --- Key: MRELEASE-586 URL: http://jira.codehaus.org/browse/MRELEASE-586 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform Affects Versions: 2.0 Reporter: Lars Corneliussen Priority: Minor Attachments: MRELEASE-425-ignore-pom.xml.branch.patch When performing a release after a branch-dry-run, the temp file 'pom.xml.branch' should be ignored. Now the perform will fail, because the working copy has modifications. There has been an issue that was closed as Won't fix: MRELEASE-425 Information about the patch: Based on r983489 in https://svn.apache.org/repos/asf/maven/release/trunk Online Compare View: http://github.com/lcorneliussen/maven-release/compare/473197249e1caf39ee2cee6d0efc8a288c30d0c3...939d6e05bbed440622a40b2094e31963d0a90c78 h4. Included commits: - [MRELEASE-425] Fixed: When running release:branch in -DdryRun mode, the resulting pom.xml.branch is seen as an unknown file the next time a release is run (by Lars Corneliussenm...@lcorneliussen.de on 05.05.2010 17:01:54) -- 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-586) release:perform - The temporary file pom.xml.branch should be ignored as pom.xml.next and pom.xml.tag are ignored
[ http://jira.codehaus.org/browse/MRELEASE-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Corneliussen updated MRELEASE-586: --- Attachment: MRELEASE-425-ignore-pom.xml.branch(2).patch Sorry. I was a little to fast uploading the first patch - it had some changes that were meant for a different issue. release:perform - The temporary file pom.xml.branch should be ignored as pom.xml.next and pom.xml.tag are ignored --- Key: MRELEASE-586 URL: http://jira.codehaus.org/browse/MRELEASE-586 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform Affects Versions: 2.0 Reporter: Lars Corneliussen Priority: Minor Attachments: MRELEASE-425-ignore-pom.xml.branch(2).patch, MRELEASE-425-ignore-pom.xml.branch.patch When performing a release after a branch-dry-run, the temp file 'pom.xml.branch' should be ignored. Now the perform will fail, because the working copy has modifications. There has been an issue that was closed as Won't fix: MRELEASE-425 Information about the patch: Based on r983489 in https://svn.apache.org/repos/asf/maven/release/trunk Online Compare View: http://github.com/lcorneliussen/maven-release/compare/473197249e1caf39ee2cee6d0efc8a288c30d0c3...939d6e05bbed440622a40b2094e31963d0a90c78 h4. Included commits: - [MRELEASE-425] Fixed: When running release:branch in -DdryRun mode, the resulting pom.xml.branch is seen as an unknown file the next time a release is run (by Lars Corneliussenm...@lcorneliussen.de on 05.05.2010 17:01:54) -- 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-554) Allow custom files to be modified before doing a prepare or branch...
[ http://jira.codehaus.org/browse/MRELEASE-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Corneliussen updated MRELEASE-554: --- Attachment: MRELEASE-554-custom-modified-files.patch Allows for configuration of user-defined local modifications that will be accepted during a release:perform. Based on r983489 in https://svn.apache.org/repos/asf/maven/release/trunk Online Compare: http://github.com/lcorneliussen/maven-release/compare/473197249e1caf39ee2cee6d0efc8a288c30d0c3...1b0672d1050a9c100cde4e1b788d5126ea8468f3 h4. Included commits: - [MRELEASE-554] Allow custom files to be modified before doing a prepare or branch o Bumped the release-descriptor.mdo to version 2.1 o Both 'prepare' and 'branch' now have a configuration value checkModificationExcludes/checkModificationExcludeList (by Lars Corneliussenm...@lcorneliussen.de on 05.05.2010 18:57:18) Generated from http://lcorneliussen.de/utils/git-svn/github.com/lcorneliussen/maven-release/tree/MRELEASE-554-custom-modified-files Allow custom files to be modified before doing a prepare or branch... - Key: MRELEASE-554 URL: http://jira.codehaus.org/browse/MRELEASE-554 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: branch, prepare Affects Versions: 2.0 Reporter: Lars Corneliussen Priority: Minor Attachments: MRELEASE-554-custom-modified-files.patch I want to call 'versions:update-parent' and 'versions:update' before I do a release preparation. This should not be a separate commit, but in the 'prepare release' commit. In conjunction with MRELEASE-458 (create branch/tag from working copy, no commits to working copy) this allows for releases without touching the working copy. This is useful in cases where the release is created from a tag or where the trunk should not move forward to a new development version. I'm working on a patch that I will attach when it is done. -- 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-571) When collecting active profiles, the active profiles from parent poms are not considered
[ http://jira.codehaus.org/browse/MRELEASE-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Corneliussen updated MRELEASE-571: --- Attachment: MRELEASE-571-collect-profiles.patch Based on r983489 in https://svn.apache.org/repos/asf/maven/release/trunk View Changes Online: http://github.com/lcorneliussen/maven-release/compare/473197249e1caf39ee2cee6d0efc8a288c30d0c3...66439919ba7d2669e46db4cc7f88dd0d24b6709c h4. Included commits: - [MRELEASE-571] Active profiles for prepare and perform are now collected from the current project and it's parents profiles (by Lars Corneliussenm...@lcorneliussen.de on 08.06.2010 13:44:10) Created from http://lcorneliussen.de/utils/git-svn/github.com/lcorneliussen/maven-release/tree/MRELEASE-571-collect-profiles When collecting active profiles, the active profiles from parent poms are not considered Key: MRELEASE-571 URL: http://jira.codehaus.org/browse/MRELEASE-571 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform, prepare Affects Versions: 2.0 Reporter: Lars Corneliussen Attachments: 89d9799a56d46d7435d08c94ca538845d7145c9b[1].patch, MRELEASE-571-collect-profiles.patch MavenProject.getActiveProfiles() does not return all profiles that are currently run, but instead only those that are run AND defined on the current project. This leads to preparation-builds of modules without the specified active profiles derived from their parents. -- This message is automatically generated by JIRA. - 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-483) Update SCM Perforce Provider to use P4Java
[
http://jira.codehaus.org/browse/SCM-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=231466#action_231466
]
Brian Jackson commented on SCM-483:
---
P4Java jar is now available in Maven Central:
http://repo1.maven.org/maven2/com/perforce/p4java/2009.3/
{code}
dependency
groupIdcom.perforce/groupId
artifactIdp4java/artifactId
version2009.3/version
/dependency
{code}
Update SCM Perforce Provider to use P4Java
--
Key: SCM-483
URL: http://jira.codehaus.org/browse/SCM-483
Project: Maven SCM
Issue Type: Improvement
Components: maven-scm-provider-perforce
Affects Versions: 1.2
Reporter: Tom Rodriguez
Fix For: future
Attachments: maven-scm-perforce-p4java.jar
Perforce has developed a new Java Native API for access to perforce called
P4Java. You can access it here:
ftp://ftp.perforce.com/perforce/r09.1/bin.java/p4java.zip. This completely
reworked API does not require that the p4 client be installed on the system.
The SCM Perforce Provider should be modified to use this new native java API
to eliminate the many issues involved with depending on the p4 executable.
--
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: (MPIR-80) Add Java requirements to the Dependency Report
[ http://jira.codehaus.org/browse/MPIR-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=231467#action_231467 ] SebbASF commented on MPIR-80: - I think the output should include both the source and target settings from the POM. Both are important. Not sure why the code bothers reading the fork and compilerVersion settings. Add Java requirements to the Dependency Report -- Key: MPIR-80 URL: http://jira.codehaus.org/browse/MPIR-80 Project: Maven 2.x Project Info Reports Plugin Issue Type: New Feature Components: dependencies, summary Affects Versions: 2.0.1 Reporter: Niall Pemberton Attachments: maven-projectinfo-dependency-java-v3.patch, maven-projectinfo-dependency-java.patch, maven-projectinfo-summary-java.patch It would be nice to add a section to the dependency report showing the java version requirements. Attaching a patch which discovers the java version and compiler options from the java-compiler-plugin configuration and outputs a Java Version section. Has an option to configure whether or not this section is shown (default to false). -- 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-483) Update SCM Perforce Provider to use P4Java
[ http://jira.codehaus.org/browse/SCM-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=231468#action_231468 ] Aaron Johnson commented on SCM-483: --- Is there anything else that needs to be done before someone can be assigned this to work? Update SCM Perforce Provider to use P4Java -- Key: SCM-483 URL: http://jira.codehaus.org/browse/SCM-483 Project: Maven SCM Issue Type: Improvement Components: maven-scm-provider-perforce Affects Versions: 1.2 Reporter: Tom Rodriguez Fix For: future Attachments: maven-scm-perforce-p4java.jar Perforce has developed a new Java Native API for access to perforce called P4Java. You can access it here: ftp://ftp.perforce.com/perforce/r09.1/bin.java/p4java.zip. This completely reworked API does not require that the p4 client be installed on the system. The SCM Perforce Provider should be modified to use this new native java API to eliminate the many issues involved with depending on the p4 executable. -- 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-483) Update SCM Perforce Provider to use P4Java
[ http://jira.codehaus.org/browse/SCM-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=231469#action_231469 ] Evgeny Mandrikov commented on SCM-483: -- Hi Aaron, I've looked a bit on your patch and I think that this patch requires a lot of refactoring. Update SCM Perforce Provider to use P4Java -- Key: SCM-483 URL: http://jira.codehaus.org/browse/SCM-483 Project: Maven SCM Issue Type: Improvement Components: maven-scm-provider-perforce Affects Versions: 1.2 Reporter: Tom Rodriguez Fix For: future Attachments: maven-scm-perforce-p4java.jar Perforce has developed a new Java Native API for access to perforce called P4Java. You can access it here: ftp://ftp.perforce.com/perforce/r09.1/bin.java/p4java.zip. This completely reworked API does not require that the p4 client be installed on the system. The SCM Perforce Provider should be modified to use this new native java API to eliminate the many issues involved with depending on the p4 executable. -- 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: (SUREFIRE-468) When tests timeout, report files on disk are incorrect
[ http://jira.codehaus.org/browse/SUREFIRE-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated SUREFIRE-468: -- Fix Version/s: (was: 2.6) Backlog Moving to the backlog as it's not a regression and it is more pressing to get 2.6 out first When tests timeout, report files on disk are incorrect -- Key: SUREFIRE-468 URL: http://jira.codehaus.org/browse/SUREFIRE-468 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin, process forking Affects Versions: 2.4.2 Reporter: A Fix For: Backlog When forkmode is always/prtest (probably that could be true for the last test and forkmode once) when one test hangs and timeout occurs, est suite execution stops and report file for the offending test not generated. That could mislead somebody to think all tests passed if all tests before the offending one passed. AFAICT that should be synchronized between one of these: 1. CommandLineUtils.executeCommandLine() 2. SurefireBooter.fork() 3. SurefireBooter.run() 4. SurefirePlugin.execute() Probably fork must detect a timeout. Then the timeout be gracefully handled by generating a report file for the test. Then continue execution of remaining tests. -- 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: (SCM-483) Update SCM Perforce Provider to use P4Java
[ http://jira.codehaus.org/browse/SCM-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=231469#action_231469 ] Evgeny Mandrikov edited comment on SCM-483 at 8/9/10 9:11 AM: -- Aaron, I've looked a bit on your patch and I think that this patch requires a lot of refactoring. Brian, Thank you for your effort. was (Author: godin): Hi Aaron, I've looked a bit on your patch and I think that this patch requires a lot of refactoring. Update SCM Perforce Provider to use P4Java -- Key: SCM-483 URL: http://jira.codehaus.org/browse/SCM-483 Project: Maven SCM Issue Type: Improvement Components: maven-scm-provider-perforce Affects Versions: 1.2 Reporter: Tom Rodriguez Fix For: future Attachments: maven-scm-perforce-p4java.jar Perforce has developed a new Java Native API for access to perforce called P4Java. You can access it here: ftp://ftp.perforce.com/perforce/r09.1/bin.java/p4java.zip. This completely reworked API does not require that the p4 client be installed on the system. The SCM Perforce Provider should be modified to use this new native java API to eliminate the many issues involved with depending on the p4 executable. -- 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-524) command line versions don't seem to work on release:branch for specific format
[ http://jira.codehaus.org/browse/MRELEASE-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Corneliussen updated MRELEASE-524: --- Attachment: MRELEASE-524-batch-mode(2).patch Updated patch from http://lcorneliussen.de/utils/git-svn/github.com/lcorneliussen/maven-release/tree/MRELEASE-524-batch-mode There were some runtime assertions causing test errors only when I ran the maven commandline. In IDEA the tests ran all fine. Those assertions were never really necessary - I seem to be the first one. No tests covering them either. http://github.com/lcorneliussen/maven-release/commit/66e5981dd944c6931face5a86a5862c1c0c73923 [MRELEASE-524] removed two runtime assertions that overeagerly tried to protect the ReleaseDescripto [more...] command line versions don't seem to work on release:branch for specific format Key: MRELEASE-524 URL: http://jira.codehaus.org/browse/MRELEASE-524 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.0 Environment: maven 2.2.1 Reporter: Max Schaefer Attachments: MRELEASE-524-batch-mode(2).patch, MRELEASE-524-batch-mode.patch I have tried passing versions for certain modules to the command line while making a branch. The plugin ignores my parameters when running release:branch. It injects the defaults if I pass parameters in batch mode. E.g. this command taken from the documentation does not work. mvn --batch-mode release:branch -DbranchName=my-branch-1.2 -Dproject.rel.org.myCompany:projectA=1.2 \ -Dproject.dev.org.myCompany:projectA=2.0-SNAPSHOT release:prepare supports this specific format for setting these values at command line. Setting these values in a release.properties file e.g. project.dev.org.myCompany\:projectA=2.0-SNAPSHOT project.rel.org.myCompany\:projectA=1.2 works also fine. Specifying the default at commandline works also e.g. mvn --batch-mode release:branch -DbranchName=my-branch-1.2 -DreleaseVersion=1.2 \ -DdevelopmentVersion=2.0-SNAPSHOT -- 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-519) release plugin fails on version ranges
[ http://jira.codehaus.org/browse/MRELEASE-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Cooper closed MRELEASE-519. --- Resolution: Duplicate This is a dupe of MRELEASE-318. If you've voted for this issue, please move your votes over to MRELEASE-318. release plugin fails on version ranges -- Key: MRELEASE-519 URL: http://jira.codehaus.org/browse/MRELEASE-519 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.0 Environment: Mac OS X 10.6, maven 2.2.1 Reporter: Stephen Cooper Priority: Critical I have the following dependency in my pom.xml dependency groupIdcom.ften.protocols/groupId artifactIdprotocols/artifactId version[3.0.0,)/version scopecompile/scope /dependency I downloaded the source for maven-release 2.0 and installed locally. If I specify 2.0-beta-9, then mvn release:perform functions as it should. If I specify maven-release-plugin version 2.0, I get the following error: [INFO] Checking dependencies and plugins for snapshots ... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] version was null for com.ften.protocols:protocols [INFO] [INFO] Trace java.lang.NullPointerException: version was null for com.ften.protocols:protocols at org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:390) at org.apache.maven.artifact.DefaultArtifact.isSnapshot(DefaultArtifact.java:562) -- 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: (SUREFIRE-633) Upgrade plexus-utils to avoid potential deadlocks in versions prior to 2.0.5
Upgrade plexus-utils to avoid potential deadlocks in versions prior to 2.0.5 Key: SUREFIRE-633 URL: http://jira.codehaus.org/browse/SUREFIRE-633 Project: Maven Surefire Issue Type: Bug Components: process forking Affects Versions: 2.5 Reporter: Kristian Rosenvold Plexus-utils should be upgraded to avoid potential deadlocks -- 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: (SUREFIRE-633) Upgrade plexus-utils to avoid potential deadlocks in versions prior to 2.0.5
[ http://jira.codehaus.org/browse/SUREFIRE-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-633. --- Resolution: Fixed Fix Version/s: 2.6 Assignee: Kristian Rosenvold Fixed in r983693 Upgrade plexus-utils to avoid potential deadlocks in versions prior to 2.0.5 Key: SUREFIRE-633 URL: http://jira.codehaus.org/browse/SUREFIRE-633 Project: Maven Surefire Issue Type: Bug Components: process forking Affects Versions: 2.5 Reporter: Kristian Rosenvold Assignee: Kristian Rosenvold Fix For: 2.6 Plexus-utils should be upgraded to avoid potential deadlocks -- 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-4643) [regression] Transitive dependency not available due to dependency POM erroneously rejected as invalid
[ http://jira.codehaus.org/browse/MNG-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=231498#action_231498 ] Basil James Whitehouse III commented on MNG-4643: - FYI a fix to Apache FTP server has been filed (and resolved): https://issues.apache.org/jira/browse/FTPSERVER-382 And a request made to fix the poms in Central: http://jira.codehaus.org/browse/MEV-669 [regression] Transitive dependency not available due to dependency POM erroneously rejected as invalid -- Key: MNG-4643 URL: http://jira.codehaus.org/browse/MNG-4643 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Affects Versions: 3.0-alpha-7, 3.0-beta-1 Environment: linux Reporter: Francis De Brabandere Assignee: Benjamin Bentmann Fix For: 3.0-beta-2 Attachments: testbrokendep.tar.gz, testbrokendep.zip I depend on apache ftpserver for my tests. But somehow since 3.0-beta-1 the transitive apache mina dependency is not available in the test classpath any more See the provided project. This code works on maven 2.x and also worked with 3.x versions until 3.0-alpha-7. But with beta 1 this build fails with class not found. Apache Maven 3.0-beta-1 (r935667; 2010-04-19 19:00:39+0200) Java version: 1.6.0_16 Java home: /usr/lib/jvm/java-6-sun-1.6.0.16/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.31-20-generic arch: i386 Family: unix -- 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-585) release:branch commits working copy changes even when -DupdateWorkingCopyVersions=false
[ http://jira.codehaus.org/browse/MRELEASE-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MRELEASE-585. Resolution: Duplicate release:branch commits working copy changes even when -DupdateWorkingCopyVersions=false --- Key: MRELEASE-585 URL: http://jira.codehaus.org/browse/MRELEASE-585 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.0 Reporter: Lars Corneliussen MRELEASE-471 and MRELEASE-458 already described the problem. The fixes made were only workarounds. Branch now commits the changes, then performs the release, and then it rolles back the changes made to the working copy. For SVN, if remoteTagging is false, it could create the branch from the workingcopy before checking it in. I'm working on a patch that I will submit soon. -- 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-262) Allow empty properties in generated pom.xml
[ http://jira.codehaus.org/browse/ARCHETYPE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=231505#action_231505 ] charles cate commented on ARCHETYPE-262: users are reporting pre-fix beharior in release alpha-6 Allow empty properties in generated pom.xml --- Key: ARCHETYPE-262 URL: http://jira.codehaus.org/browse/ARCHETYPE-262 Project: Maven Archetype Issue Type: Bug Components: Creator Affects Versions: 2.0-alpha-4 Reporter: Matt Raible Assignee: Herve Boutemy Fix For: 2.0-alpha-5 http://www.nabble.com/Issues-with-archetype%3Acreate-from-project-to23286970.html#a23427955 When I have an empty property (e.g. jdbc.password/jdbc.password), it's removed from the resulting pom.xml. -- 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: (DOXIASITETOOLS-39) Velocity 1.5 can't parse default-site.vm
[ http://jira.codehaus.org/browse/DOXIASITETOOLS-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=231518#action_231518 ] Stefan Bodewig commented on DOXIASITETOOLS-39: -- Let me start with a disclaimer: I'm not a velocity developer and not a doxia user, I'm just an observer and maybe a messenger between velocity and doxia. 8-) I see Velocity 1.7-beta1 inside the central repo (groupId is org.apache.velocity now) and don't think there is a final release, yet. The feedback I received from the velocity developers is that while the parser may have accepted your template with older versions, it likely never has done what you intended it to do. If you now tell me that it works for you, I don't know how to respond to that. Quotes cannot be escaped by \ in Velocity templates. Velocity 1.5 can't parse default-site.vm -- Key: DOXIASITETOOLS-39 URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-39 Project: Maven Doxia Sitetools Issue Type: Improvement Components: Doc renderer, Site renderer Affects Versions: 1.0, 1.1 Reporter: Stefan Bodewig Priority: Minor This is an issue detected by Gump which runs Maven builds but replaces dependencies with the trunk versions of things built by Gump rather than the version a project asks for. The Cargo build - see http://gump.zones.apache.org/gump/test/cargo/cargo/gump_work/build_cargo_cargo.html - fails because Velocity doesn't like the line #set ( $documentHeader = ?xml version=\1.0\ encoding=\UTF-8\? ) because \ is not an escape sequence for Velocity (anymore?). I've taken this to the velocity list - http://mail-archives.apache.org/mod_mbox/velocity-dev/201008.mbox/%3c87ocdlps07@v35516.1blu.de%3e - and received the feedback that backslash escaping was not supported - and likely never has been - and you should either use single quotes inside the double quotes or use something like #set( $Q = '' ) #set ( $documentHeader = ?xml version= + $Q + 1.0 + $Q + ... I realize that it probably works for you right now using Velocity 1.5, that's why I used Improvement rather than bug as category. Still it may be worth to find a solution that works for the version of Velocity you want to use as well as future versions. -- 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-275) Figuring out duplicate class definitions using the Analyze goal
[ http://jira.codehaus.org/browse/MDEP-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=231536#action_231536 ] Brian Fox commented on MDEP-275: Your timing couldn't have been better. We were just discussing the need for this the other day to help diagnose potential conflicts when switching from Maven 2.x to Maven 3.x. I'll take a look and get this merged in. Figuring out duplicate class definitions using the Analyze goal --- Key: MDEP-275 URL: http://jira.codehaus.org/browse/MDEP-275 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: analyze Affects Versions: 2.1 Reporter: Petter Måhlén Assignee: Brian Fox Attachments: dependency-analyzer.diff, dependency-plugin.diff Hi, I've pretty frequently run into issues where changes to the library structure of some product (that is, changing the way that classes are grouped into libraries) leads to the same classes being defined in more than one place. This can lead to system-dependent problems, because different versions of the same class are being loaded by different systems. I was going to create a new goal for the dependency plugin to check for duplicate classes, but when I looked a bit closer at the analyze goal, it already had all the information needed to do that check as well, so I came up with some changes that add this functionality. The intended usage is something like: mvn dependency:analyze -DcheckDuplicateClasses I get the feeling that I might want to add the ability to exclude certain packages (that I might be comfortable are safe to have duplicates of), so I added this option too: mvn dependency:analyze -DcheckDuplicateClasses -DexcludePrefixes=org., net.sf.cglib, javax.xml, junit. The output looks something like: [WARNING] Duplicate class definitions found: [WARNING]com.shopzilla.common.data.ObjectFactory defined in: [WARNING] com.shopzilla.site.url.c14n:model:jar:1.4:compile [WARNING] com.shopzilla.common.data:data-model-schema:jar:1.11:compile [WARNING]com.shopzilla.site.category.CategoryProvider defined in: [WARNING] com.shopzilla.site2.sasClient:sas-client-core:jar:5.47:compile [WARNING] com.shopzilla.site2.service:common-web:jar:5.50:compile A couple of notes: - I was unable to get configuration (setting checkDuplicateClasses, etc.) using the pom to work, but I think that might be due to lack of understanding on my part. - I don't fully understand the effect of calling compileProject() during unit tests, but I think it may be sufficient to call it only once for the duplicateClasses project, during setUp(). That would speed up the unit tests. - I haven't added duplicate class definition checking to the AnalyzeReportMojo, because I wanted to get some feedback on whether this addition was felt to be valuable before spending any time on that. - A lot of the unit test dummy code in the attached diff files needs cleaning up, but again I wanted to wait with that until hearing whether this might be useful to others. - I made an API change in the ProjectDependencyAnalyzer interface, which might be an issue if there are other implementations than the default one. That change was only needed to support the 'exclude package' feature, which might not be super-important. Cheers, Petter -- 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
