[jira] Created: (MRELEASE-560) Check for changed subprojects (in multimodule projects) and release only the projects which have changed
Check for changed subprojects (in multimodule projects) and release only the projects which have changed Key: MRELEASE-560 URL: http://jira.codehaus.org/browse/MRELEASE-560 Project: Maven 2.x Release Plugin Issue Type: Improvement Affects Versions: 2.1 Environment: Windows Vista, jdk1.6.0_18 Reporter: Peter Simon Attachments: releaseOnlyChangedProjects.patch This feature makes it possible for multimodule projects to configure if the subprojects that have no changes since the last release shell be released or not. By setting the argument -DreleaseOnlyChanged=true only the changed submodules will be released (default -DreleaseOnlyChanged=false). To compare the workingcopy with the last release, the poms are modified by adding a property lastReleaseRev which contains the revision of the last release. If this property doesn't exist (as it is for the first release) the project will be released. If only the changed subprojects shall be released, the different phases (f.ex. RewritePomsPhase) will be skipped for those projects. This patch also includes the patch for MRELEASE-550. -- 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=221437#action_221437
]
Dieter König commented on MNG-3228:
---
I have a similar problem. The activation of the profile in the parent pom is
defined as follows
activationfileexists${project.build.sourceDirectory}/java/exists/file/activation.
Because my pom-packaged project has no src/main/java-folder the profile is not
activated and it stays deactivated for modules too, even if the module has such
folder!
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:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[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=221437#action_221437
]
Dieter König edited comment on MNG-3228 at 5/17/10 6:50 AM:
I have a similar problem with maven 2.1.0. The activation of the profile in the
parent pom is defined as follows
activationfileexists${project.build.sourceDirectory}/java/exists/file/activation.
Because my pom-packaged project has no src/main/java-folder the profile is not
activated and it stays deactivated for modules too, even if the module has such
folder!
was (Author: amiddima):
I have a similar problem. The activation of the profile in the parent pom
is defined as follows
activationfileexists${project.build.sourceDirectory}/java/exists/file/activation.
Because my pom-packaged project has no src/main/java-folder the profile is not
activated and it stays deactivated for modules too, even if the module has such
folder!
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:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHANGES-199) changes:trac-report fails with [Fatal Error] :1:50: White spaces are required between publicId and systemId.
changes:trac-report fails with [Fatal Error] :1:50: White spaces are required between publicId and systemId. Key: MCHANGES-199 URL: http://jira.codehaus.org/browse/MCHANGES-199 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: trac-report Affects Versions: 2.3 Environment: Server: Trac 0.11.5 (with XML-RPC plugin 1.1.0) on Apache 2.2.12 Client: Apache Maven 2.2.0 (r788681; 2009-06-26 15:04:01+0200) Java version: 1.6.0_17 Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home Default locale: de_DE, platform encoding: MacRoman OS name: mac os x version: 10.6.3 arch: x86_64 Family: mac Reporter: Alexander Papaspyrou The changes plugin fails on changes:trac-report invocation (and as part of mvn site:site) with [Fatal Error] :1:50: White spaces are required between publicId and systemId. and later (end of build) with Embedded error: XmlRpc Error. Failed to parse servers response: White spaces are required between publicId and systemId. The XML-RPC installation in Trac is working fine (http://trac.localhost/trac/project/xmlrpc renders help pages; Eclipse Mylyn able to access), and XML_RPC/TICKET_VIEW/REPORT_VIEW permissions are granted to anonymous. Ideas? -- 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: (MGPG-17) password is specified, but still promting
[ http://jira.codehaus.org/browse/MGPG-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221465#action_221465 ] SebbASF commented on MGPG-17: - Just tried again with gpg (GnuPG) 1.4.10, and it works fine. I think the problem is that gpg2.exe (which may also be installed as gpg.exe) does not handle the passphrase-fd parameter in the same way as earlier versions of gpg. According to http://linux.die.net/man/1/gpg2 The --passphrase-fd option is only used by gpg2 if --batch is also specified. IMO GPG2 really ought to print a warning for this change in behaviour. The --batch option is also valid for earlier versions of gpg, so the solution is to add --batch when providing a password. Since GPG2 cannot get the password from fd0, it will start the gpg-agent which will then cache the password for a while. I think this explains why the prompt sometimes re-appears. A work-round is to ensure that the version of gpg found by Maven is not gpg2, but an earlier version. password is specified, but still promting - Key: MGPG-17 URL: http://jira.codehaus.org/browse/MGPG-17 Project: Maven 2.x GPG Plugin Issue Type: Bug Affects Versions: 1.0-alpha-4 Environment: Apache Maven 2.2.0 (r788681; 2009-06-26 08:04:01-0500) Java version: 1.6.0_15 Java home: /usr/lib/jvm/java-1.6.0-sun-1.6.0/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.27.29-0.1-default arch: i386 Family: unix gpg (GnuPG) 2.0.9 on OpenSUSE 11.1 Reporter: Albert Kurucz Using mvn verify -Dgpg.passphrase=thephrase with thephrase replaced with the real one. When it get to signing, it still promts. It is critical, because this prompt repeats with all the 100 modules of the project. Problem maybe related to updates/changes of gpg software. Related warning message: gpg: WARNING: --no-use-agent is an obsolete option - it has no effect can't connect to `/home/albert_kurucz/.gnupg/S.gpg-agent': No such file or directory -- 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-4677) Plugin configuration incorrectly inherited from parent pom
Plugin configuration incorrectly inherited from parent pom
--
Key: MNG-4677
URL: http://jira.codehaus.org/browse/MNG-4677
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.0-beta-1
Reporter: Ben Tatham
Until 3.0-beta-1 this was working correctly, but now when I run
release:perform, it runs the goals from the un-inherited plugin configuration
instead of the one in pluginManagement that should be inherited.
In this example, the release plugin on the project should run goals: deploy
nmx-pom:dependency, but instead it is running deploy nmx-pom:parent. The
latter is what the parent pom project itself runs on release.
It seems that maven is now ignoring the inheritedfalse/inherited flag, at
least in some cases.
This is confirmed by the effective pom as well (see below). Note that the
effective pom in m2eclipse (that must still use the embedded maven instead of
the external one I setup in Eclipse Preferences) has it correct.
The release goals are all setup by the parent pom, which contains this:
...
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.0-beta-9/version
inheritedtrue/inherited
configuration
tagBasehttp://svn/repos/libraries/java/${project.artifactId}/tags/tagBase
useReleaseProfilefalse/useReleaseProfile
!-- goals to run during release:perform (removed site-deploy from
default settings) --
goalsdeploy ca.nanometrics.maven:nmx-pom-plugin:dependency/goals
arguments-Dpom.update.skip=${pom.update.skip}
-Dhudson.url=${hudson.url}
-Dhudson.jobName=${hudson.jobName}
-Dhudson.buildNumber=${hudson.buildNumber}/arguments
/configuration
/plugin
/pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.0-beta-9/version
inheritedfalse/inherited
configuration
tagBasehttp://svn/repos/tools/maven/common-pom/tags/tagBase
useReleaseProfilefalse/useReleaseProfile
goalsdeploy
ca.nanometrics.maven:nmx-pom-plugin:${nmx-pom-plugin.version}:parent/goals
arguments-Dpom.update.skip=${pom.update.skip}
-Dhudson.url=${hudson.url}
-Dhudson.jobName=${hudson.jobName}
-Dhudson.buildNumber=${hudson.buildNumber}/arguments
/configuration
/plugin
/build
The effective pom of the project itself, using 3.0-beta-1 has:
...
plugin
artifactIdmaven-release-plugin/artifactId
version2.0-beta-9/version
inheritedtrue/inherited
configuration
tagBasehttp://svn/repos/libraries/java/apollo-workstation/tags/tagBase
useReleaseProfilefalse/useReleaseProfile
goalsdeploy ca.nanometrics.maven:nmx-pom-plugin:dependency/goals
arguments-Dpom.update.skip=false -Dhudson.url=
-Dhudson.jobName= -Dhudson.buildNumber=/arguments
/configuration
/plugin
/plugins
/pluginManagement
plugins
plugin
artifactIdmaven-release-plugin/artifactId
version2.0-beta-9/version
inheritedfalse/inherited
configuration
tagBasehttp://svn/repos/libraries/java/apollo/workstation/tags/tagBase
useReleaseProfilefalse/useReleaseProfile
goalsdeploy ca.nanometrics.maven:nmx-pom-plugin:1.3.3:parent/goals
arguments-Dpom.update.skip=false -Dhudson.url=
-Dhudson.jobName=
-Dhudson.buildNumber=/arguments
/configuration
/plugin
...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-526) release:prepare 2.0 goal tags at the wrong level, tagging project/ instead of project/trunk
[
http://jira.codehaus.org/browse/MRELEASE-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221490#action_221490
]
James Blewitt commented on MRELEASE-526:
There is a bug in the way the release plugin calculates the path to use as the
tag base directory. We have also had this problem and have modified the release
plugin (locally) to solve the problem. The cause of the problem is a little bit
tricky to explain, but I'll try my best:
*The trigger for this problem is as follows:*
Suppose we have projects A, B, C and D
{noformat}
A
|-B
|-C
\-D
{noformat}
* Projects B, C and D are all in the modules list of project A.
* Projects C and D have A as parent.
* Project B has no parent (or a parent other than A).
Because project B does not depend on A, it may appear before A in the reactor
build order. This can easily be tested for by looking at the Reactor build
order that appears when you do release:prepare. Usually you would expect
project A to be the first entry in this list.
*The program fault:*
The faulty code is in the maven-release-manager (a module used by the
maven-release-helper).
The file *org.apache.maven.shared.release.util.ReleaseUtil* in method
*getCommonBasedir* is where the error lies.
This method should find the base directory shared by all projects in the
reactor. This directory will be used as the base directory from which to
perform the tag.
It works by looking at all paths for all projects in the reactor and finding
the prefix that is common to all path strings.
E.g.
c:/path/to/projectA-1.5
c:/path/to/projectB-2.1
c:/path/to/projectC-1.0
The common prefix would be c:/path/to/project. Because this is not a valid
path (there is no project directory) it cuts off the string from the last /
leaving c:/path/to.
Returning to our example above: we would have the following input for this
method:
c:/path/to/projectA
c:/path/to/projectA/projectB
c:/path/to/projectA/projectC
c:/path/to/projectA/projectD
Because the method needs to return c:/path/to/projectA (and not c/path/to)
as the base directory, the algorithm adds an additional / to the end of paths
to ensure that the common suffix is a valid path (i.e. doesn't get shortened
as in the first example).
This works fine, but as soon as the project order looks like the following it
doesn't work correctly:
c:/path/to/projectA/projectB
c:/path/to/projectA
c:/path/to/projectA/projectC
c:/path/to/projectA/projectD
This is exactly the sequence that you get when B doesn't have A for a parent
(the trigger condition).
The algorithm fails to append / to the second path and the returned path is
c:/path/to instead of c:/path/to/projectA and this is then used as the base
directory for the tag. This is why the generated tag is one level too high in
the directory tree.
*The fix:*
This method at the moment is as follows:
{noformat}
public static String getCommonBasedir( List reactorProjects, char separator )
{
String basedir = null;
for ( Iterator i = reactorProjects.iterator(); i.hasNext(); )
{
MavenProject p = (MavenProject) i.next();
// we can only normalize paths with /
String dir = FileUtils.normalize( p.getBasedir().getPath().replace(
'\\', '/' ) );
if ( basedir == null )
{
basedir = dir;
}
else
{
// always end in / so that we know what is a path and what is a
partial directory name in the next call
if ( !basedir.endsWith( / ) )
{
basedir = basedir + /;
}
basedir = StringUtils.getCommonPrefix( new String[]{dir,
basedir} );
if ( !basedir.endsWith( / ) )
{
basedir = basedir.substring( 0, basedir.lastIndexOf( / )
);
}
}
}
if ( basedir != null )
{
if ( basedir.endsWith( / ) basedir.length() 1 )
{
basedir = basedir.substring( 0, basedir.length() - 1 );
}
basedir = basedir.replace( '/', separator );
}
return basedir;
}
{noformat}
It can be changed to the following, which correctly appends / to the end of
both basedir AND dir, which solves the problem.
{noformat}
public static String getCommonBasedir(List reactorProjects, char separator)
{
String basedir = null;
for (Iterator i = reactorProjects.iterator(); i.hasNext();) {
MavenProject p = (MavenProject) i.next();
// we can only normalize paths with /
String dir =
FileUtils.normalize(p.getBasedir().getPath().replace('\\', '/'));
// always end in / so that we know what is a path and what is a
partial directory name in the next call
if
[jira] Created: (MSTAGE-14) DefaultRepositoryCopier rename script does not check move command exit codes
DefaultRepositoryCopier rename script does not check move command exit codes Key: MSTAGE-14 URL: http://jira.codehaus.org/browse/MSTAGE-14 Project: Maven 2.x Stage Plugin Issue Type: Improvement Affects Versions: 1.0-alpha-2 Reporter: Francis De Brabandere Only if the last move command fails will the plugin fail. This because the exit code for unix scipts is the one from the last command. Better would be to use something like this: #!/bin/sh touch test.txt \ rm test.txt \ rm test2.txt \ - fails here and won't continue touch test2.txt \ rm test2.txt this script will fail even if the last 2 commands would succeed (those will not even run) I know this failing is something that is not common but still possible. We actually had this issue and it took quite some time to find out why certain builds failed and others not (depended on what the last mv command was). -- 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-356) depreate the automated release profile
[ http://jira.codehaus.org/browse/MRELEASE-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221499#action_221499 ] Peter Lynch commented on MRELEASE-356: -- Can someone include a link here to a mailing list discussion or similar that states that the release profile will be removed or modified in an upcoming Maven release, 3.x or otherwise? depreate the automated release profile -- Key: MRELEASE-356 URL: http://jira.codehaus.org/browse/MRELEASE-356 Project: Maven 2.x Release Plugin Issue Type: Task Components: perform Reporter: Brett Porter the release profile is being removed from the super POM in Maven 2.1-alpha-1, so the release plugin should pre-emptively start ensuring users do this themselves -- 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: (MDEP-250) Add a skip paramater to dependency:unpack
[ http://jira.codehaus.org/browse/MDEP-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Khai Do updated MDEP-250: - Attachment: MDEP-250-patch.txt Attached is a patch for the skip flag. It will work for both copy and unpack goals. Please consider including this in the next release. Thanks. Here the pom.xml: project [...] build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId configuration skip[ true or false ]/skip artifactItems artifactItem groupId[ groupId ]/groupId artifactId[ artifactId ]/artifactId version[ version ]/version type[ packaging ]/type /artifactItem /artifactItems /configuration /plugin /plugins /build [...] /project Add a skip paramater to dependency:unpack - Key: MDEP-250 URL: http://jira.codehaus.org/browse/MDEP-250 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: unpack Affects Versions: 2.1 Environment: Windows XP Reporter: Jim McCaskey Assignee: Brian Fox Attachments: MDEP-250-patch.txt We would like to have a skip paramater for dependency:unpack. This would cause the unpack to be skipped if true. We are currently working around the lack of this with profiles. The jetspeed plugin has a skip option that we have found some uses for, but jetspeed is not as robust as the dependency plugin (specifically with multi-module builds). We would prefer to use the core modules anyway. Here is a link to the jetspeed configuration page: http://portals.apache.org/jetspeed-2/maven/jetspeed-maven-plugins.html#Configuration_and_usage_of_the_jetspeed-unpack:unpack_Maven_Plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAR-136) Add @threadSafe support
Add @threadSafe support --- Key: MJAR-136 URL: http://jira.codehaus.org/browse/MJAR-136 Project: Maven 2.x Jar Plugin Issue Type: Improvement Affects Versions: 2.3 Reporter: Kristian Rosenvold Maven jar plugin is threadSafe when running with plexus-io = 1.0, plexus-archiver =1.0 and maven-archiver =2.4.1. UPgrade libs accordingly and mark mojos -- 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: (MNG-4677) [regression] Plugin configuration incorrectly inherited from parent pom
[
http://jira.codehaus.org/browse/MNG-4677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4677:
---
Summary: [regression] Plugin configuration incorrectly inherited from
parent pom (was: Plugin configuration incorrectly inherited from parent pom)
[regression] Plugin configuration incorrectly inherited from parent pom
---
Key: MNG-4677
URL: http://jira.codehaus.org/browse/MNG-4677
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.0-beta-1
Reporter: Ben Tatham
Until 3.0-beta-1 this was working correctly, but now when I run
release:perform, it runs the goals from the un-inherited plugin configuration
instead of the one in pluginManagement that should be inherited.
In this example, the release plugin on the project should run goals: deploy
nmx-pom:dependency, but instead it is running deploy nmx-pom:parent. The
latter is what the parent pom project itself runs on release.
It seems that maven is now ignoring the inheritedfalse/inherited flag, at
least in some cases.
This is confirmed by the effective pom as well (see below). Note that the
effective pom in m2eclipse (that must still use the embedded maven instead of
the external one I setup in Eclipse Preferences) has it correct.
The release goals are all setup by the parent pom, which contains this:
...
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.0-beta-9/version
inheritedtrue/inherited
configuration
tagBasehttp://svn/repos/libraries/java/${project.artifactId}/tags/tagBase
useReleaseProfilefalse/useReleaseProfile
!-- goals to run during release:perform (removed site-deploy
from default settings) --
goalsdeploy
ca.nanometrics.maven:nmx-pom-plugin:dependency/goals
arguments-Dpom.update.skip=${pom.update.skip}
-Dhudson.url=${hudson.url}
-Dhudson.jobName=${hudson.jobName}
-Dhudson.buildNumber=${hudson.buildNumber}/arguments
/configuration
/plugin
/pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.0-beta-9/version
inheritedfalse/inherited
configuration
tagBasehttp://svn/repos/tools/maven/common-pom/tags/tagBase
useReleaseProfilefalse/useReleaseProfile
goalsdeploy
ca.nanometrics.maven:nmx-pom-plugin:${nmx-pom-plugin.version}:parent/goals
arguments-Dpom.update.skip=${pom.update.skip}
-Dhudson.url=${hudson.url}
-Dhudson.jobName=${hudson.jobName}
-Dhudson.buildNumber=${hudson.buildNumber}/arguments
/configuration
/plugin
/build
The effective pom of the project itself, using 3.0-beta-1 has:
...
plugin
artifactIdmaven-release-plugin/artifactId
version2.0-beta-9/version
inheritedtrue/inherited
configuration
tagBasehttp://svn/repos/libraries/java/apollo-workstation/tags/tagBase
useReleaseProfilefalse/useReleaseProfile
goalsdeploy
ca.nanometrics.maven:nmx-pom-plugin:dependency/goals
arguments-Dpom.update.skip=false -Dhudson.url=
-Dhudson.jobName= -Dhudson.buildNumber=/arguments
/configuration
/plugin
/plugins
/pluginManagement
plugins
plugin
artifactIdmaven-release-plugin/artifactId
version2.0-beta-9/version
inheritedfalse/inherited
configuration
tagBasehttp://svn/repos/libraries/java/apollo/workstation/tags/tagBase
useReleaseProfilefalse/useReleaseProfile
goalsdeploy
ca.nanometrics.maven:nmx-pom-plugin:1.3.3:parent/goals
arguments-Dpom.update.skip=false -Dhudson.url=
-Dhudson.jobName=
-Dhudson.buildNumber=/arguments
/configuration
/plugin
...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4677) [regression] Plugin configuration incorrectly inherited from parent pom
[
http://jira.codehaus.org/browse/MNG-4677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4677.
--
Resolution: Fixed
Fix Version/s: 3.0-beta-2
Assignee: Benjamin Bentmann
Fixed in [r945294|http://svn.apache.org/viewvc?view=revisionrevision=945294].
[regression] Plugin configuration incorrectly inherited from parent pom
---
Key: MNG-4677
URL: http://jira.codehaus.org/browse/MNG-4677
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.0-beta-1
Reporter: Ben Tatham
Assignee: Benjamin Bentmann
Fix For: 3.0-beta-2
Until 3.0-beta-1 this was working correctly, but now when I run
release:perform, it runs the goals from the un-inherited plugin configuration
instead of the one in pluginManagement that should be inherited.
In this example, the release plugin on the project should run goals: deploy
nmx-pom:dependency, but instead it is running deploy nmx-pom:parent. The
latter is what the parent pom project itself runs on release.
It seems that maven is now ignoring the inheritedfalse/inherited flag, at
least in some cases.
This is confirmed by the effective pom as well (see below). Note that the
effective pom in m2eclipse (that must still use the embedded maven instead of
the external one I setup in Eclipse Preferences) has it correct.
The release goals are all setup by the parent pom, which contains this:
...
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.0-beta-9/version
inheritedtrue/inherited
configuration
tagBasehttp://svn/repos/libraries/java/${project.artifactId}/tags/tagBase
useReleaseProfilefalse/useReleaseProfile
!-- goals to run during release:perform (removed site-deploy
from default settings) --
goalsdeploy
ca.nanometrics.maven:nmx-pom-plugin:dependency/goals
arguments-Dpom.update.skip=${pom.update.skip}
-Dhudson.url=${hudson.url}
-Dhudson.jobName=${hudson.jobName}
-Dhudson.buildNumber=${hudson.buildNumber}/arguments
/configuration
/plugin
/pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.0-beta-9/version
inheritedfalse/inherited
configuration
tagBasehttp://svn/repos/tools/maven/common-pom/tags/tagBase
useReleaseProfilefalse/useReleaseProfile
goalsdeploy
ca.nanometrics.maven:nmx-pom-plugin:${nmx-pom-plugin.version}:parent/goals
arguments-Dpom.update.skip=${pom.update.skip}
-Dhudson.url=${hudson.url}
-Dhudson.jobName=${hudson.jobName}
-Dhudson.buildNumber=${hudson.buildNumber}/arguments
/configuration
/plugin
/build
The effective pom of the project itself, using 3.0-beta-1 has:
...
plugin
artifactIdmaven-release-plugin/artifactId
version2.0-beta-9/version
inheritedtrue/inherited
configuration
tagBasehttp://svn/repos/libraries/java/apollo-workstation/tags/tagBase
useReleaseProfilefalse/useReleaseProfile
goalsdeploy
ca.nanometrics.maven:nmx-pom-plugin:dependency/goals
arguments-Dpom.update.skip=false -Dhudson.url=
-Dhudson.jobName= -Dhudson.buildNumber=/arguments
/configuration
/plugin
/plugins
/pluginManagement
plugins
plugin
artifactIdmaven-release-plugin/artifactId
version2.0-beta-9/version
inheritedfalse/inherited
configuration
tagBasehttp://svn/repos/libraries/java/apollo/workstation/tags/tagBase
useReleaseProfilefalse/useReleaseProfile
goalsdeploy
ca.nanometrics.maven:nmx-pom-plugin:1.3.3:parent/goals
arguments-Dpom.update.skip=false -Dhudson.url=
-Dhudson.jobName=
-Dhudson.buildNumber=/arguments
/configuration
/plugin
...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-619) The surefire plugin should generate the test classpath
[ http://jira.codehaus.org/browse/SUREFIRE-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed SUREFIRE-619. -- Resolution: Fixed The surefire plugin should generate the test classpath -- Key: SUREFIRE-619 URL: http://jira.codehaus.org/browse/SUREFIRE-619 Project: Maven Surefire Issue Type: Improvement Components: classloading, Maven Surefire Plugin Affects Versions: 2.5 Reporter: Paul Gier Assignee: Paul Gier Fix For: 2.6 I believe the surefire plugin would be improved if it generated the test classpath internally instead of getting the test classpath from MavenProject. This would allow the user better control over what is included in the classpath, and would actually simplify parts of the code for building the classpath. The risk associated with this change is that the default surefire classpath could end up being different than the test classpath in MavenProject. However, I think that as long as the surefire plugin classpath generation is well documented, this won't cause a problem for users. -- 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: (MJAR-136) Add @threadSafe support
[ http://jira.codehaus.org/browse/MJAR-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MJAR-136: Fix Version/s: 2.3.1 Assignee: Kristian Rosenvold Fixed in r945289 Add @threadSafe support --- Key: MJAR-136 URL: http://jira.codehaus.org/browse/MJAR-136 Project: Maven 2.x Jar Plugin Issue Type: Improvement Affects Versions: 2.3 Reporter: Kristian Rosenvold Assignee: Kristian Rosenvold Fix For: 2.3.1 Maven jar plugin is threadSafe when running with plexus-io = 1.0, plexus-archiver =1.0 and maven-archiver =2.4.1. UPgrade libs accordingly and mark mojos -- 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: (MJAR-136) Add @threadSafe support
[ http://jira.codehaus.org/browse/MJAR-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MJAR-136. --- Resolution: Fixed Add @threadSafe support --- Key: MJAR-136 URL: http://jira.codehaus.org/browse/MJAR-136 Project: Maven 2.x Jar Plugin Issue Type: Improvement Affects Versions: 2.3 Reporter: Kristian Rosenvold Assignee: Kristian Rosenvold Fix For: 2.3.1 Maven jar plugin is threadSafe when running with plexus-io = 1.0, plexus-archiver =1.0 and maven-archiver =2.4.1. UPgrade libs accordingly and mark mojos -- 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: (MJAR-137) Avoid possible data corruption issues and deadlocks
Avoid possible data corruption issues and deadlocks --- Key: MJAR-137 URL: http://jira.codehaus.org/browse/MJAR-137 Project: Maven 2.x Jar Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Kristian Rosenvold Priority: Critical Issues that could cause deadlocks on all platforms (but especially 64 bit) and corruption of archives on non-windows platforms have been identified in these libraries. These can be fixed by upgrading plexus-is = 1.0, plexus-utils = 2.0.5, plexus-archiver = 1.0 and maven-archiver = 2.4.1 -- 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: (MJAR-137) Avoid possible data corruption issues and deadlocks
[ http://jira.codehaus.org/browse/MJAR-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MJAR-137. --- Resolution: Fixed Fix Version/s: 2.3.1 Assignee: Kristian Rosenvold Avoid possible data corruption issues and deadlocks --- Key: MJAR-137 URL: http://jira.codehaus.org/browse/MJAR-137 Project: Maven 2.x Jar Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Kristian Rosenvold Assignee: Kristian Rosenvold Priority: Critical Fix For: 2.3.1 Issues that could cause deadlocks on all platforms (but especially 64 bit) and corruption of archives on non-windows platforms have been identified in these libraries. These can be fixed by upgrading plexus-is = 1.0, plexus-utils = 2.0.5, plexus-archiver = 1.0 and maven-archiver = 2.4.1 -- 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: (MEAR-127) Avoid possible data corruption issues and deadlocks
[ http://jira.codehaus.org/browse/MEAR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MEAR-127: Priority: Critical (was: Major) Avoid possible data corruption issues and deadlocks --- Key: MEAR-127 URL: http://jira.codehaus.org/browse/MEAR-127 Project: Maven 2.x Ear Plugin Issue Type: Bug Affects Versions: 2.4.1 Reporter: Kristian Rosenvold Priority: Critical Fix For: 2.4.2 Issues that could cause deadlocks on all platforms (but especially 64 bit) and corruption of archives on non-windows platforms have been identified in these libraries. These can be fixed by upgrading plexus-is = 1.0, plexus-utils = 2.0.5, plexus-archiver = 1.0 and maven-archiver = 2.4.1 -- 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: (MEAR-127) Avoid possible data corruption issues and deadlocks
[ http://jira.codehaus.org/browse/MEAR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MEAR-127. --- Resolution: Fixed Fix Version/s: 2.4.2 Assignee: Kristian Rosenvold Avoid possible data corruption issues and deadlocks --- Key: MEAR-127 URL: http://jira.codehaus.org/browse/MEAR-127 Project: Maven 2.x Ear Plugin Issue Type: Bug Affects Versions: 2.4.1 Reporter: Kristian Rosenvold Assignee: Kristian Rosenvold Priority: Critical Fix For: 2.4.2 Issues that could cause deadlocks on all platforms (but especially 64 bit) and corruption of archives on non-windows platforms have been identified in these libraries. These can be fixed by upgrading plexus-is = 1.0, plexus-utils = 2.0.5, plexus-archiver = 1.0 and maven-archiver = 2.4.1 -- 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: (MEAR-127) Avoid possible data corruption issues and deadlocks
Avoid possible data corruption issues and deadlocks --- Key: MEAR-127 URL: http://jira.codehaus.org/browse/MEAR-127 Project: Maven 2.x Ear Plugin Issue Type: Bug Affects Versions: 2.4.1 Reporter: Kristian Rosenvold Issues that could cause deadlocks on all platforms (but especially 64 bit) and corruption of archives on non-windows platforms have been identified in these libraries. These can be fixed by upgrading plexus-is = 1.0, plexus-utils = 2.0.5, plexus-archiver = 1.0 and maven-archiver = 2.4.1 -- 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: (MECLIPSE-655) does not correctly resolve SNAPSHOTS from CI server with projects in workspace because versions do not match
does not correctly resolve SNAPSHOTS from CI server with projects in workspace because versions do not match Key: MECLIPSE-655 URL: http://jira.codehaus.org/browse/MECLIPSE-655 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.8 Environment: Apache Maven 2.1.0 (r755702; 2009-03-18 15:10:27-0400) Java version: 1.5.0_16 Reporter: Jim Sellers Attachments: maven-eclipse-snapshot-issue.txt Scenario: 1) Check out a library into your workspace, in SNAPSHOT mode. e.g. the version is 2.0-SNAPSHOT. 2) This project is being built by a CI server, using the standard snapshot artifact naming convention. e.g. 2.0-20100513.210009-65 3) In project in workspace that uses the library, when you run eclipse:eclipse, in the .classpath file it will link to the jar in the .m2/repository location. In the log you'll see a message like: [INFO] Artifact com.example:MyLibrary:jar:2.0-SNAPSHOT already available as a workspace project, but with different version. Expected: 2.0-20100513.210009-65, found: 2.0-SNAPSHOT The weird issues: W1) The difficult part is that if in the library you run a mvn install command first, and then in the other project run mvn eclipse:eclipse, it will correctly depend on your project in the workspace. W2) After doing W1, if the next day you re-run mvn eclipse:eclipse in the non-library project, it will then resolve to the artifact built in the CI server and no longer link the project to the library in the workspace. The workaround: Each day run mvn install in the library before running mvn eclipse:eclipse in the other project. The solution (no patch yet, can't make it through the firewall at work): Instead of using org.apache.maven.artifact.Artifact#getVersion(), getBaseVersion() should be used instead. In the AbstractIdeSupportMojo#doDependencyResolution() method, near the bottom where it passing in the version, it should use the getBaseVersion() http://maven.apache.org/plugins/maven-eclipse-plugin/xref/org/apache/maven/plugin/ide/AbstractIdeSupportMojo.html#685 In the EclipsePlugin#isAvailableAsAWorkspaceProject( Artifact artifact ) method, it should compare the version in the workspace to the baseVersion http://maven.apache.org/plugins/maven-eclipse-plugin/xref/org/apache/maven/plugin/eclipse/EclipsePlugin.html#1941 -- 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: (MJAR-136) Add @threadSafe support for maven3
[ http://jira.codehaus.org/browse/MJAR-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MJAR-136: Summary: Add @threadSafe support for maven3 (was: Add @threadSafe support) Add @threadSafe support for maven3 -- Key: MJAR-136 URL: http://jira.codehaus.org/browse/MJAR-136 Project: Maven 2.x Jar Plugin Issue Type: Improvement Affects Versions: 2.3 Reporter: Kristian Rosenvold Assignee: Kristian Rosenvold Fix For: 2.3.1 Maven jar plugin is threadSafe when running with plexus-io = 1.0, plexus-archiver =1.0 and maven-archiver =2.4.1. UPgrade libs accordingly and mark mojos -- 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: (MCOMPILER-127) Mark compiler plugin as @threadSafe for maven3
[ http://jira.codehaus.org/browse/MCOMPILER-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MCOMPILER-127: - Summary: Mark compiler plugin as @threadSafe for maven3 (was: Mark compiler plugin as @threadSafe) Mark compiler plugin as @threadSafe for maven3 -- Key: MCOMPILER-127 URL: http://jira.codehaus.org/browse/MCOMPILER-127 Project: Maven 2.x Compiler Plugin Issue Type: Improvement Affects Versions: 2.3 Reporter: Kristian Rosenvold Assignee: Kristian Rosenvold Fix For: 2.3.1 The compiler plugin is threadSafe and needs to be marked as such. Code inspection performed and over 70.000 concurrent builds on CI back this up. -- 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: (MINSTALL-75) Add @threadSafe support for maven3
[ http://jira.codehaus.org/browse/MINSTALL-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MINSTALL-75: --- Summary: Add @threadSafe support for maven3 (was: Add @threadSafe) Add @threadSafe support for maven3 -- Key: MINSTALL-75 URL: http://jira.codehaus.org/browse/MINSTALL-75 Project: Maven 2.x Install Plugin Issue Type: New Feature Affects Versions: 2.3 Reporter: Kristian Rosenvold Assignee: Kristian Rosenvold Fix For: 2.3.1 The install plugin is threadSafe and should be marked as such. Please note that this does not mean MNG-2802 is solved. -- 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] Work started: (SUREFIRE-592) Refactor plugins to remove duplicate code
[ http://jira.codehaus.org/browse/SUREFIRE-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SUREFIRE-592 started by Stephen Connolly. Refactor plugins to remove duplicate code - Key: SUREFIRE-592 URL: http://jira.codehaus.org/browse/SUREFIRE-592 Project: Maven Surefire Issue Type: Improvement Affects Versions: 2.5 Reporter: Stephen Connolly Assignee: Stephen Connolly Fix For: 2.6 After the addition of maven-failsafe-plugin there is now a fair bit of duplicate code between failsafe and surefire plugins. This code needs to be refactored into a single base class -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-592) Refactor plugins to remove duplicate code
[ http://jira.codehaus.org/browse/SUREFIRE-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221531#action_221531 ] Stephen Connolly commented on SUREFIRE-592: --- There has been a bit of discussion and the consensus view at the time is to keep the plugins separate but find a way for having the common code shared. I have made some progress on making the common code shared, I still have a little bit more refactoring to tidy things up some more before I am ready to mark this issue resolved Refactor plugins to remove duplicate code - Key: SUREFIRE-592 URL: http://jira.codehaus.org/browse/SUREFIRE-592 Project: Maven Surefire Issue Type: Improvement Affects Versions: 2.5 Reporter: Stephen Connolly Assignee: Stephen Connolly Fix For: 2.6 After the addition of maven-failsafe-plugin there is now a fair bit of duplicate code between failsafe and surefire plugins. This code needs to be refactored into a single base class -- 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-576) Have the abiltiy to remove a dependency from the test classpath (at least optional ones
[ http://jira.codehaus.org/browse/SUREFIRE-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed SUREFIRE-576. -- Resolution: Fixed Fixed in [r945404|http://svn.apache.org/viewvc?view=revisionrevision=945404]. Have the abiltiy to remove a dependency from the test classpath (at least optional ones --- Key: SUREFIRE-576 URL: http://jira.codehaus.org/browse/SUREFIRE-576 Project: Maven Surefire Issue Type: New Feature Components: classloading, Maven Surefire Plugin Reporter: Hardy Ferentschik Assignee: Paul Gier Fix For: 2.6 -- 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-598) run maven test with customized classpath
[ http://jira.codehaus.org/browse/SUREFIRE-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed SUREFIRE-598. -- Resolution: Fixed Due to SUREFIRE-576, this was re-implemented in a more generic way. There are now two new parameters, one to remove individual dependencies by groupId:artifactId, and the other parameter to remove dependencies by scope. Fixed in [r945404|http://svn.apache.org/viewvc?view=revisionrevision=945404] run maven test with customized classpath Key: SUREFIRE-598 URL: http://jira.codehaus.org/browse/SUREFIRE-598 Project: Maven Surefire Issue Type: New Feature Components: Maven Surefire Plugin Affects Versions: 2.5 Reporter: A Assignee: Paul Gier Fix For: 2.6 Attachments: surefire.diff I have modified the plug-in to allow customizing the classpath used when running tests. The idea is that sometimes one needs to know everything works with the libraries as shipped with another project that is using (and includes) the maven project currently under tests. But at the moment one cannot override the maven test classpath. I hope this functionality will be useful to others tasked to test releases of big projects bundling lots of smaller projects and willing to make sure the smaller projects are still operating flawlessly in this environment. So I'm attaching a patch against trunk r898286 that I hope to be included in future maven-surefire-plugin releases. There are two configurable additional parameters - ignoreClasspathElements and debugClasspath. The former one selects what to remove from the original maven test classpath and the second outputs classpath information to the INFO level so one doesn't need to dig into the DEBUG output and/or TEST-X.xml Basically how I use it is like: 1. ignoreClasspathElements=runtime (remove runtime artifacts from test classpath) 2. additionalClasspathElements=all jars from the big project 3. debugClasspath=true (so I can easily verify classpath elements are what I expect them to be) There are two more options for ignoreClasspathElements - none and all. First is the default so classpath is what it has always used to be. Latter is to nuke the whole test classpath in case somebody needs full control and wants to specify even the test scoped classpath elements. I've put @since 2.5.1 but that of course is not something I insist on. Please change it to whatever fits best your release rules. -- 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: (MGPG-23) Allow gpg executable name and path to be specified
Allow gpg executable name and path to be specified -- Key: MGPG-23 URL: http://jira.codehaus.org/browse/MGPG-23 Project: Maven 2.x GPG Plugin Issue Type: Improvement Affects Versions: 1.0 Reporter: SebbASF It would be useful to be able to specify the gpg executable name via a property. It would also sometimes be useful to be able to specify the full path to the 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: (MRELEASE-356) depreate the automated release profile
[ http://jira.codehaus.org/browse/MRELEASE-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=221554#action_221554 ] Brett Porter commented on MRELEASE-356: --- it appears to have been added back in Maven 3 as well, but still with the deprecation note. Probably would be changed for Maven 3.1 so that it can be tied to the POM model version. depreate the automated release profile -- Key: MRELEASE-356 URL: http://jira.codehaus.org/browse/MRELEASE-356 Project: Maven 2.x Release Plugin Issue Type: Task Components: perform Reporter: Brett Porter the release profile is being removed from the super POM in Maven 2.1-alpha-1, so the release plugin should pre-emptively start ensuring users do this themselves -- 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-4678) CLI: AbstractConsoleDownloadMonitor, BatchModeDownloadMonitor output download progress to STDOUT
CLI: AbstractConsoleDownloadMonitor, BatchModeDownloadMonitor output download
progress to STDOUT
Key: MNG-4678
URL: http://jira.codehaus.org/browse/MNG-4678
Project: Maven 2 3
Issue Type: Bug
Components: Command Line
Affects Versions: 2.2.1
Reporter: Dimitry Voytenko
The code looks about like this:
public void transferInitiated( TransferEvent transferEvent )
{
String message = transferEvent.getRequestType() ==
TransferEvent.REQUEST_PUT ? Uploading : Downloading;
String url = transferEvent.getWagon().getRepository().getUrl();
// TODO: can't use getLogger() because this isn't currently
instantiated as a component
System.out.println( message + : + url + / +
transferEvent.getResource().getName() );
}
Not sure why Log instance cannot be obtained here, but this really messes up
any code that would need to filter STDOUT.
--
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
