[jira] Created: (MSHADE-82) Add the ability to deploy a reduced pom in place of the original
Add the ability to deploy a reduced pom in place of the original - Key: MSHADE-82 URL: http://jira.codehaus.org/browse/MSHADE-82 Project: Maven 2.x Shade Plugin Issue Type: Improvement Affects Versions: 1.3.3 Reporter: Christophe Lallement shade plugin is very useful to merge some jar into one. It can be used when we have a *terminal* pom (i mean a pom where no other pom can depend). sometime we want to have a project packaged with it's dependencies into one (for ex. because we use only a few class of a dep. or to avoid conflict) and deploy for other projects that can add dependencies on it. Shade plugin works very fine until the generation of jar and reduced pom. So at this stage *we can deploy merging jar but not the reduced pom*. I looking for other plugin / maven tricks to do this task but doesn't find anything. *Is this task can be done into the shade plugin ?* Thx Christopje -- 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-265) Add classifier option for dependency:get
[ http://jira.codehaus.org/browse/MDEP-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Salmaan Zaidi updated MDEP-265: --- Attachment: MDEP-265-include-artifact-string.diff Add classifier option for dependency:get Key: MDEP-265 URL: http://jira.codehaus.org/browse/MDEP-265 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: Andreas Kohn Assignee: Brian Fox Attachments: MDEP-265-include-artifact-string.diff, MDEP-265.diff The dependency:get mojo is really helpful, but it currently seems to be unable to get an artifact that uses a non-default classifier. Please add a classifier configuration option for the get mojo. -- 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-265) Add classifier option for dependency:get
[ http://jira.codehaus.org/browse/MDEP-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=228146#action_228146 ] David Boden commented on MDEP-265: -- Please note that the MDEP-265-include-artifact-string.diff patch supersedes the MDEP-265.diff patch and includes support for specifying the classifier as part of the artifact string as well as using the classifier attribute. Add classifier option for dependency:get Key: MDEP-265 URL: http://jira.codehaus.org/browse/MDEP-265 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: Andreas Kohn Assignee: Brian Fox Attachments: MDEP-265-include-artifact-string.diff, MDEP-265.diff The dependency:get mojo is really helpful, but it currently seems to be unable to get an artifact that uses a non-default classifier. Please add a classifier configuration option for the get mojo. -- 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-265) Add classifier option for dependency:get
[ http://jira.codehaus.org/browse/MDEP-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=228148#action_228148 ] Andreas Kohn commented on MDEP-265: --- If i read the MDEP-265-include-artifact-string.diff correctly than a classifier specified as part of the artifact will overwrite a classifier specified via classifier? This is fine, I just wonder whether this should be made explicit in the documentation somehow? Add classifier option for dependency:get Key: MDEP-265 URL: http://jira.codehaus.org/browse/MDEP-265 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: Andreas Kohn Assignee: Brian Fox Attachments: MDEP-265-include-artifact-string.diff, MDEP-265.diff The dependency:get mojo is really helpful, but it currently seems to be unable to get an artifact that uses a non-default classifier. Please add a classifier configuration option for the get mojo. -- 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: (WAGON-310) download from Aix directories or files fails
download from Aix directories or files fails
Key: WAGON-310
URL: http://jira.codehaus.org/browse/WAGON-310
Project: Maven Wagon
Issue Type: Bug
Components: wagon-ssh
Affects Versions: 1.0-beta-3
Environment: maven 2.0.11/2.2.1 from Linux to Aix power5
Reporter: alain dheygere
Downloading of files or directories fails from Aix power5 system.
When I try to download files from Aix system (using a ssh tunnel, I don't think
this is the problem), files are copied with wildcard * in the Linux local
server.
pom.xml:
...
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdwagon-maven-plugin/artifactId
configuration
serverIdssh/serverId
/configuration
...
goals
goaldownload/goal
/goals
configuration
fromDirtmp//fromDir
toDir${project.basedir}/target/toDir
includest*/includes
urlscp://${target.server.name}:${target.server.port}/url
/configuration
...
traces:
-
[INFO] Executed tasks
[DEBUG] Configuring mojo
'org.codehaus.mojo:wagon-maven-plugin:1.0-beta-3:download' --
[DEBUG] (f) caseSensitive = true
[DEBUG] (f) fromDir = tmp/adheygere
[DEBUG] (f) includes = t*
[DEBUG] (f) project = MavenProject: com.amabis.www.Amalib:Aix:2.1 @
/fs10/home/adheygere/maven-2.2/CVSROOT/Amalib.new/Aix/pom.xml
[DEBUG] (f) serverId = ssh
[DEBUG] (f) settings = org.apache.maven.settings.setti...@1c70315
[DEBUG] (f) skip = false
[DEBUG] (f) toDir =
/fs10/home/adheygere/maven-2.2/CVSROOT/Amalib.new/Aix/target
[DEBUG] (f) url = scp://localhost:8182
[DEBUG] -- end configuration --
[INFO] [wagon:download {execution: download}]
Using private key: /home/adheygere/.ssh/id_rsa
scp://localhost:8182 - Session: Opened
[INFO] Scanning remote file system: scp://localhost:8182 ...
Executing command: ls /tmp/adheygere/toto*/
Executing command: ls /tmp/adheygere/turlututu*/
[INFO] Downloading scp://localhost:8182/tmp/adheygere/toto* to
/fs10/home/adheygere/maven-2.2/CVSROOT/Amalib.new/Aix/target/toto* ...
Executing command: scp -p -f /tmp/adheygere/toto*
Remote file permissions: 0777
Remote file size: 5
Remote filename: toto
attempting to create parent directories for destination: toto*
Downloading: tmp/adheygere/toto* from scp://localhost:8182
#
Transfer finished. 5 bytes copied in 0.157 seconds
[INFO] Downloading scp://localhost:8182/tmp/adheygere/turlututu* to
/fs10/home/adheygere/maven-2.2/CVSROOT/Amalib.new/Aix/target/turlututu* ...
Executing command: scp -p -f /tmp/adheygere/turlututu*
Remote file permissions: 0777
Remote file size: 10
Remote filename: turlututu
attempting to create parent directories for destination: turlututu*
Downloading: tmp/adheygere/turlututu* from scp://localhost:8182
#
Transfer finished. 10 bytes copied in 0.155 seconds
scp://localhost:8182 - Session: Disconnecting
scp://localhost:8182 - Session: Disconnected
-
In the pom.xml, when using includes**includes file path are wrong
traces:
[INFO] Executed tasks
[DEBUG] Configuring mojo
'org.codehaus.mojo:wagon-maven-plugin:1.0-beta-3:download' --
[DEBUG] (f) caseSensitive = true
[DEBUG] (f) fromDir = tmp/adheygere/maven/Amalib/Aix/target/classes/
[DEBUG] (f) includes = **
[DEBUG] (f) project = MavenProject: com.amabis.www.Amalib:Aix:2.1 @
/fs10/home/adheygere/maven-2.2/CVSROOT/Amalib.new/Aix/pom.xml
[DEBUG] (f) serverId = ssh
[DEBUG] (f) settings = org.apache.maven.settings.setti...@1453d72
[DEBUG] (f) skip = false
[DEBUG] (f) toDir =
/fs10/home/adheygere/maven-2.2/CVSROOT/Amalib.new/Aix/target
[DEBUG] (f) url = scp://localhost:8182
[DEBUG] -- end configuration --
[INFO] [wagon:download {execution: download}]
Using private key: /home/adheygere/.ssh/id_rsa
scp://localhost:8182 - Session: Opened
[INFO] Scanning remote file system: scp://localhost:8182 ...
Executing command: ls
/tmp/adheygere/maven/Amalib/Aix/target/classes/LICENSE.txt/
Executing command: ls
/tmp/adheygere/maven/Amalib/Aix/target/classes/LICENSE.txt//tmp/adheygere/maven/Amalib/Aix/target/classes/LICENSE.txt/
Executing command: ls /tmp/adheygere/maven/Amalib/Aix/target/classes/NOTICE.txt/
Executing command: ls
/tmp/adheygere/maven/Amalib/Aix/target/classes/NOTICE.txt//tmp/adheygere/maven/Amalib/Aix/target/classes/NOTICE.txt/
Executing command: ls /tmp/adheygere/maven/Amalib/Aix/target/classes/README.txt/
Executing command: ls
/tmp/adheygere/maven/Amalib/Aix/target/classes/README.txt//tmp/adheygere/maven/Amalib/Aix/target/classes/README.txt/
Executing command: ls /tmp/adheygere/maven/Amalib/Aix/target/classes/amalib.ini/
Executing command: ls
[jira] Commented: (MANTRUN-147) Flag to turn on Ant debug mode(s)
[ http://jira.codehaus.org/browse/MANTRUN-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=228151#action_228151 ] Paul Gier commented on MANTRUN-147: --- The antrun plugin should turn on debug mode when Maven debug mode is on. Do you need more control than this? Flag to turn on Ant debug mode(s) - Key: MANTRUN-147 URL: http://jira.codehaus.org/browse/MANTRUN-147 Project: Maven 2.x Antrun Plugin Issue Type: New Feature Affects Versions: 1.4 Reporter: John Casey It'd be useful in debugging antrun executions if we could turn on a flag to indicate which debug/verbose mode to enable for the Ant execution. -- 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: (MANTRUN-148) The basedir property is not changed when called from an imported file.
[
http://jira.codehaus.org/browse/MANTRUN-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=228152#action_228152
]
Paul Gier commented on MANTRUN-148:
---
The attached test-auto-compile plugin does not build. There is no java source
to create a mojo.
The basedir property is not changed when called from an imported file.
---
Key: MANTRUN-148
URL: http://jira.codehaus.org/browse/MANTRUN-148
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Environment: Windows XP professional edition
Reporter: Sander Rensen
Attachments: settings.xml, Temp.zip, test-auto-compile.zip
Dear Maven developers,
I want to call an ant script from maven using mojos. The issue I am facing is
that the basedir property does not change the moment this property is used
within an imported file. This needs to happen as the basedir from the
imported file is allocated in a different directory then the directory I am
calling the maven mojo from. Let me explain with an example I have attached.
1. Please first extract the zip file test-auto-compile.zip. Install the mojo
plugin (mvn clean install).
2. Make sure in the maven repository the settings xml file is changed. I have
attached this file separately. I have included a
pluginGrouptest-auto-compile/pluginGroup in the settings.xml file.
3. Make sure the files ant-sca-package.xml and ant-sca-compile.xml are copied
in C:/Temp. For this please extract the zip file Temp.zip.
4. run the test-auto-compile project typing: mvn testcompile:testcompile.
5. The error is: Cannot find
D:\SopraGroup\Development\PoC\Mavin\test-auto-compile/ant-sca-compil
e.xml imported from C:\Temp\ant-sca-package.xml.
The file ant-sca-package.xml is imported from the build.xml file. This file
ant-sca-package.xml imports the ant-sca-compile file. This file is imported
using: import file=${basedir}/ant-sca-compile.xml/
The basedir should be the directory from where the ant-sca-package is
imported. In this case c:/Temp. However it tries to find the
ant-sca-compile.xml file in the maven directory as his basedir.
When I am calling the same ant script directly from ant then the basedir
changes and the ant script is completed successfully.
The solution to this issue is very simple by changing the import statement in
the ant-sca-compile file. However I am not aloud to change this file!!
I hope you can assist with this bug.
Many Thanks
Sander Rensen
--
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: (MANTRUN-148) The basedir property is not changed when called from an imported file.
[
http://jira.codehaus.org/browse/MANTRUN-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=228154#action_228154
]
Sander Rensen commented on MANTRUN-148:
---
Hi Paul,
Thanks for coming back to me. The example I have provided does not include any
Java code. The mojo only calls an Ant task. I have tried a new mvn clean
install from the extracted test-auto-compile folder and my build is successful.
Can you please let me know the error you are receiving?
Many Thanks
Sander
The basedir property is not changed when called from an imported file.
---
Key: MANTRUN-148
URL: http://jira.codehaus.org/browse/MANTRUN-148
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Environment: Windows XP professional edition
Reporter: Sander Rensen
Attachments: settings.xml, Temp.zip, test-auto-compile.zip
Dear Maven developers,
I want to call an ant script from maven using mojos. The issue I am facing is
that the basedir property does not change the moment this property is used
within an imported file. This needs to happen as the basedir from the
imported file is allocated in a different directory then the directory I am
calling the maven mojo from. Let me explain with an example I have attached.
1. Please first extract the zip file test-auto-compile.zip. Install the mojo
plugin (mvn clean install).
2. Make sure in the maven repository the settings xml file is changed. I have
attached this file separately. I have included a
pluginGrouptest-auto-compile/pluginGroup in the settings.xml file.
3. Make sure the files ant-sca-package.xml and ant-sca-compile.xml are copied
in C:/Temp. For this please extract the zip file Temp.zip.
4. run the test-auto-compile project typing: mvn testcompile:testcompile.
5. The error is: Cannot find
D:\SopraGroup\Development\PoC\Mavin\test-auto-compile/ant-sca-compil
e.xml imported from C:\Temp\ant-sca-package.xml.
The file ant-sca-package.xml is imported from the build.xml file. This file
ant-sca-package.xml imports the ant-sca-compile file. This file is imported
using: import file=${basedir}/ant-sca-compile.xml/
The basedir should be the directory from where the ant-sca-package is
imported. In this case c:/Temp. However it tries to find the
ant-sca-compile.xml file in the maven directory as his basedir.
When I am calling the same ant script directly from ant then the basedir
changes and the ant script is completed successfully.
The solution to this issue is very simple by changing the import statement in
the ant-sca-compile file. However I am not aloud to change this file!!
I hope you can assist with this bug.
Many Thanks
Sander Rensen
--
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-4727) Allow ordering plugin execution via id/
Allow ordering plugin execution via id/
-
Key: MNG-4727
URL: http://jira.codehaus.org/browse/MNG-4727
Project: Maven 2 3
Issue Type: Improvement
Affects Versions: 2.2.1
Reporter: Wim Deblauwe
I would like to be able to deterministically order the execution of plugins
bound to the same lifecycle phase. I have a project where I need to execute the
antrun plugin, then the install4j-maven-plugin, again the antrun plugin and
finally the rpm-maven-plugin.
I would like to be able to do this:
{code:xml}
plugin
artifactIdmaven-antrun-plugin/artifactId
version1.4/version
executions
execution
idstep-1-extract-tomcat6x/id
phasepackage/phase
goalsgoalrun/goal/goals
configuration
...
/configuration
/execution
execution
idstep-3-extract-install4j-tar-gz-file/id
phasepackage/phase
goalsgoalrun/goal/goals
configuration
...
/configuration
/execution
/executions
/plugin
plugin
groupIdcom.google.code.maven-install4j/groupId
artifactIdmaven-install4j-plugin/artifactId
version0.2-mvn-2.2.1/version
executions
execution
idstep-2-build-installers/id
phasepackage/phase
goalsgoalcompile/goal/goals
/execution
/executions
configuration
...
/configuration
/plugin
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdrpm-maven-plugin/artifactId
version2.1-alpha-1/version
executions
execution
idstep-4-create-rpm/id
phasepackage/phase
goalsgoalattached-rpm/goal/goals
/execution
/executions
configuration
...
/configuration
/plugin
{code}
When defined like this, the execution order should be:
# step-1-extract-tomcat6x
# step-2-build-installers
# step-3-extract-install4j-tar-gz-file
# step-4-create-rpm
With the current maven (2.2.1), you can do this if you order your plugins in
the pom.xml correctly and you don't need the same plugin twice. Depending on
the {{id/}} (with natural sorting on String) would allow to declare the same
plugin twice.
An alternative might be to add an additional element to {{execution/}}, like
{{order/}} or something that only accepts a number.
--
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-4727) Allow ordering plugin execution via id/
[
http://jira.codehaus.org/browse/MNG-4727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4727.
--
Resolution: Duplicate
Assignee: Benjamin Bentmann
Allow ordering plugin execution via id/
-
Key: MNG-4727
URL: http://jira.codehaus.org/browse/MNG-4727
Project: Maven 2 3
Issue Type: Improvement
Affects Versions: 2.2.1
Reporter: Wim Deblauwe
Assignee: Benjamin Bentmann
I would like to be able to deterministically order the execution of plugins
bound to the same lifecycle phase. I have a project where I need to execute
the antrun plugin, then the install4j-maven-plugin, again the antrun plugin
and finally the rpm-maven-plugin.
I would like to be able to do this:
{code:xml}
plugin
artifactIdmaven-antrun-plugin/artifactId
version1.4/version
executions
execution
idstep-1-extract-tomcat6x/id
phasepackage/phase
goalsgoalrun/goal/goals
configuration
...
/configuration
/execution
execution
idstep-3-extract-install4j-tar-gz-file/id
phasepackage/phase
goalsgoalrun/goal/goals
configuration
...
/configuration
/execution
/executions
/plugin
plugin
groupIdcom.google.code.maven-install4j/groupId
artifactIdmaven-install4j-plugin/artifactId
version0.2-mvn-2.2.1/version
executions
execution
idstep-2-build-installers/id
phasepackage/phase
goalsgoalcompile/goal/goals
/execution
/executions
configuration
...
/configuration
/plugin
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdrpm-maven-plugin/artifactId
version2.1-alpha-1/version
executions
execution
idstep-4-create-rpm/id
phasepackage/phase
goalsgoalattached-rpm/goal/goals
/execution
/executions
configuration
...
/configuration
/plugin
{code}
When defined like this, the execution order should be:
# step-1-extract-tomcat6x
# step-2-build-installers
# step-3-extract-install4j-tar-gz-file
# step-4-create-rpm
With the current maven (2.2.1), you can do this if you order your plugins in
the pom.xml correctly and you don't need the same plugin twice. Depending on
the {{id/}} (with natural sorting on String) would allow to declare the
same plugin twice.
An alternative might be to add an additional element to {{execution/}},
like {{order/}} or something that only accepts a number.
--
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-4727) Allow ordering plugin execution via id/
[
http://jira.codehaus.org/browse/MNG-4727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=228157#action_228157
]
Wim Deblauwe commented on MNG-4727:
---
Is there somebody who can give me a clue on where to look in the 2.2.x codebase
to implement this? I suppose the plugin definitions are added to a
{{Collection}} somewhere. If I could change that into a TreeSet for example
with sorting on the id, this would do the trick I suppose.
As I know nothing of the Maven internals, maybe it is implemented totally
different, that makes this hard to do?
Allow ordering plugin execution via id/
-
Key: MNG-4727
URL: http://jira.codehaus.org/browse/MNG-4727
Project: Maven 2 3
Issue Type: Improvement
Affects Versions: 2.2.1
Reporter: Wim Deblauwe
Assignee: Benjamin Bentmann
I would like to be able to deterministically order the execution of plugins
bound to the same lifecycle phase. I have a project where I need to execute
the antrun plugin, then the install4j-maven-plugin, again the antrun plugin
and finally the rpm-maven-plugin.
I would like to be able to do this:
{code:xml}
plugin
artifactIdmaven-antrun-plugin/artifactId
version1.4/version
executions
execution
idstep-1-extract-tomcat6x/id
phasepackage/phase
goalsgoalrun/goal/goals
configuration
...
/configuration
/execution
execution
idstep-3-extract-install4j-tar-gz-file/id
phasepackage/phase
goalsgoalrun/goal/goals
configuration
...
/configuration
/execution
/executions
/plugin
plugin
groupIdcom.google.code.maven-install4j/groupId
artifactIdmaven-install4j-plugin/artifactId
version0.2-mvn-2.2.1/version
executions
execution
idstep-2-build-installers/id
phasepackage/phase
goalsgoalcompile/goal/goals
/execution
/executions
configuration
...
/configuration
/plugin
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdrpm-maven-plugin/artifactId
version2.1-alpha-1/version
executions
execution
idstep-4-create-rpm/id
phasepackage/phase
goalsgoalattached-rpm/goal/goals
/execution
/executions
configuration
...
/configuration
/plugin
{code}
When defined like this, the execution order should be:
# step-1-extract-tomcat6x
# step-2-build-installers
# step-3-extract-install4j-tar-gz-file
# step-4-create-rpm
With the current maven (2.2.1), you can do this if you order your plugins in
the pom.xml correctly and you don't need the same plugin twice. Depending on
the {{id/}} (with natural sorting on String) would allow to declare the
same plugin twice.
An alternative might be to add an additional element to {{execution/}},
like {{order/}} or something that only accepts a number.
--
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-3522) Cannot define execution order explicitly
[
http://jira.codehaus.org/browse/MNG-3522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=228158#action_228158
]
Wim Deblauwe commented on MNG-3522:
---
Voted for this one. I really need it. See MNG-4727 for my usecase.
Cannot define execution order explicitly
Key: MNG-3522
URL: http://jira.codehaus.org/browse/MNG-3522
Project: Maven 2 3
Issue Type: New Feature
Components: Plugins and Lifecycle
Affects Versions: 2.0.9
Reporter: Thomas Diesler
Fix For: Issues to be reviewed for 3.x
In this example antrun:run is excuted after dependency:copy-dependencies by
virtue of plugin order. Preferable would be an explicit order definition. For
example, a plugin could export a 'phase-id' that another uses in its 'phase'
element.
{code:xml}
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
executions
execution
idcopy-dependencies/id
phasepackage/phase
goals
goalcopy-dependencies/goal
/goals
configuration
outputDirectory${project.build.directory}/thirdparty/outputDirectory
stripVersiontrue/stripVersion
/configuration
/execution
/executions
/plugin
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasepackage/phase
goals
goalrun/goal
/goals
configuration
tasks
ant antfile=ant/build-concat.xml/
/tasks
/configuration
/execution
/executions
/plugin
/plugins
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4727) Allow ordering plugin execution via id/
[
http://jira.codehaus.org/browse/MNG-4727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wim Deblauwe updated MNG-4727:
--
Attachment: plugin_execution_order.patch
Added a patch for {{DefaultLifecyleExecutor.java}} that allows the above. It is
a bit hackish because you need to start your {{id}} with step- to have the
sorting kick in. I did this to avoid as much other issues as possible if you
don't want this sorting.
I just tried it on a project of mine and it works perfectly. If you run maven
with debug info, it will print out the order.
Allow ordering plugin execution via id/
-
Key: MNG-4727
URL: http://jira.codehaus.org/browse/MNG-4727
Project: Maven 2 3
Issue Type: Improvement
Affects Versions: 2.2.1
Reporter: Wim Deblauwe
Assignee: Benjamin Bentmann
Attachments: plugin_execution_order.patch
I would like to be able to deterministically order the execution of plugins
bound to the same lifecycle phase. I have a project where I need to execute
the antrun plugin, then the install4j-maven-plugin, again the antrun plugin
and finally the rpm-maven-plugin.
I would like to be able to do this:
{code:xml}
plugin
artifactIdmaven-antrun-plugin/artifactId
version1.4/version
executions
execution
idstep-1-extract-tomcat6x/id
phasepackage/phase
goalsgoalrun/goal/goals
configuration
...
/configuration
/execution
execution
idstep-3-extract-install4j-tar-gz-file/id
phasepackage/phase
goalsgoalrun/goal/goals
configuration
...
/configuration
/execution
/executions
/plugin
plugin
groupIdcom.google.code.maven-install4j/groupId
artifactIdmaven-install4j-plugin/artifactId
version0.2-mvn-2.2.1/version
executions
execution
idstep-2-build-installers/id
phasepackage/phase
goalsgoalcompile/goal/goals
/execution
/executions
configuration
...
/configuration
/plugin
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdrpm-maven-plugin/artifactId
version2.1-alpha-1/version
executions
execution
idstep-4-create-rpm/id
phasepackage/phase
goalsgoalattached-rpm/goal/goals
/execution
/executions
configuration
...
/configuration
/plugin
{code}
When defined like this, the execution order should be:
# step-1-extract-tomcat6x
# step-2-build-installers
# step-3-extract-install4j-tar-gz-file
# step-4-create-rpm
With the current maven (2.2.1), you can do this if you order your plugins in
the pom.xml correctly and you don't need the same plugin twice. Depending on
the {{id/}} (with natural sorting on String) would allow to declare the
same plugin twice.
An alternative might be to add an additional element to {{execution/}},
like {{order/}} or something that only accepts a number.
--
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-4727) Allow ordering plugin execution via id/
[
http://jira.codehaus.org/browse/MNG-4727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=228161#action_228161
]
Wim Deblauwe edited comment on MNG-4727 at 7/13/10 8:15 AM:
Added a patch for {{DefaultLifecyleExecutor.java}} that allows the above (based
on the maven-2.2.x branch). It is a bit hackish because you need to start your
{{id}} with step- to have the sorting kick in. I did this to avoid as much
other issues as possible if you don't want this sorting.
I just tried it on a project of mine and it works perfectly. If you run maven
with debug info, it will print out the order.
was (Author: festerwim):
Added a patch for {{DefaultLifecyleExecutor.java}} that allows the above.
It is a bit hackish because you need to start your {{id}} with step- to
have the sorting kick in. I did this to avoid as much other issues as possible
if you don't want this sorting.
I just tried it on a project of mine and it works perfectly. If you run maven
with debug info, it will print out the order.
Allow ordering plugin execution via id/
-
Key: MNG-4727
URL: http://jira.codehaus.org/browse/MNG-4727
Project: Maven 2 3
Issue Type: Improvement
Affects Versions: 2.2.1
Reporter: Wim Deblauwe
Assignee: Benjamin Bentmann
Attachments: plugin_execution_order.patch
I would like to be able to deterministically order the execution of plugins
bound to the same lifecycle phase. I have a project where I need to execute
the antrun plugin, then the install4j-maven-plugin, again the antrun plugin
and finally the rpm-maven-plugin.
I would like to be able to do this:
{code:xml}
plugin
artifactIdmaven-antrun-plugin/artifactId
version1.4/version
executions
execution
idstep-1-extract-tomcat6x/id
phasepackage/phase
goalsgoalrun/goal/goals
configuration
...
/configuration
/execution
execution
idstep-3-extract-install4j-tar-gz-file/id
phasepackage/phase
goalsgoalrun/goal/goals
configuration
...
/configuration
/execution
/executions
/plugin
plugin
groupIdcom.google.code.maven-install4j/groupId
artifactIdmaven-install4j-plugin/artifactId
version0.2-mvn-2.2.1/version
executions
execution
idstep-2-build-installers/id
phasepackage/phase
goalsgoalcompile/goal/goals
/execution
/executions
configuration
...
/configuration
/plugin
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdrpm-maven-plugin/artifactId
version2.1-alpha-1/version
executions
execution
idstep-4-create-rpm/id
phasepackage/phase
goalsgoalattached-rpm/goal/goals
/execution
/executions
configuration
...
/configuration
/plugin
{code}
When defined like this, the execution order should be:
# step-1-extract-tomcat6x
# step-2-build-installers
# step-3-extract-install4j-tar-gz-file
# step-4-create-rpm
With the current maven (2.2.1), you can do this if you order your plugins in
the pom.xml correctly and you don't need the same plugin twice. Depending on
the {{id/}} (with natural sorting on String) would allow to declare the
same plugin twice.
An alternative might be to add an additional element to {{execution/}},
like {{order/}} or something that only accepts a number.
--
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-3522) Cannot define execution order explicitly
[
http://jira.codehaus.org/browse/MNG-3522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=228158#action_228158
]
Wim Deblauwe edited comment on MNG-3522 at 7/13/10 8:15 AM:
Voted for this one. I really need it. See MNG-4727 for my usecase and a patch
against maven-2.2.x that allows this.
was (Author: festerwim):
Voted for this one. I really need it. See MNG-4727 for my usecase.
Cannot define execution order explicitly
Key: MNG-3522
URL: http://jira.codehaus.org/browse/MNG-3522
Project: Maven 2 3
Issue Type: New Feature
Components: Plugins and Lifecycle
Affects Versions: 2.0.9
Reporter: Thomas Diesler
Fix For: Issues to be reviewed for 3.x
In this example antrun:run is excuted after dependency:copy-dependencies by
virtue of plugin order. Preferable would be an explicit order definition. For
example, a plugin could export a 'phase-id' that another uses in its 'phase'
element.
{code:xml}
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
executions
execution
idcopy-dependencies/id
phasepackage/phase
goals
goalcopy-dependencies/goal
/goals
configuration
outputDirectory${project.build.directory}/thirdparty/outputDirectory
stripVersiontrue/stripVersion
/configuration
/execution
/executions
/plugin
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasepackage/phase
goals
goalrun/goal
/goals
configuration
tasks
ant antfile=ant/build-concat.xml/
/tasks
/configuration
/execution
/executions
/plugin
/plugins
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPIR-150) the dependency report ignores mirrors
[
http://jira.codehaus.org/browse/MPIR-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=228186#action_228186
]
Prashant Bhate commented on MPIR-150:
--
Thanks a lot for this patch, Now site deployment would be much quicker.
it would be nice if {{url.openStream();}}
{code}
InputStream in =null;
try
{
in = url.openStream();
{code}
can be replaced with
{code}
//Define constant TIMEOUT with pre set timeout
InputStream in =null;
try
{
URLConnection conn = url.openConnection();
conn.setConnectTimeout(TIMEOUT);
conn.setReadTimeout(TIMEOUT);
in = conn.getInputStream();
{code}
{{url.openStream();}} is a blocking call that makes caller wait forever
the dependency report ignores mirrors
-
Key: MPIR-150
URL: http://jira.codehaus.org/browse/MPIR-150
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Bug
Components: dependencies
Affects Versions: 2.1.1
Reporter: Brian Fox
Assignee: Olivier Lamy
Fix For: 2.2
Attachments: MPIR-150.patch
The dependencies report takes forever and running debug i can see it's
hitting the same repos over and over and bypassing my repository manager.
--
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-664) Wrong classpath entry ordering for source and test folder
Wrong classpath entry ordering for source and test folder - Key: MECLIPSE-664 URL: http://jira.codehaus.org/browse/MECLIPSE-664 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.8 Environment: MacOS 10.6.3, Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_15 Reporter: Roman Pichlik The plugin sorts the source and the test folder in reverse order (not alphabetical) to .classpath file, so test folder as first and source folder as second. It makes using of a project very uncomfortable, because Eclipse generates the project layout where the source folder appears as the first entry in Package explorer by default. The plugin behavior has been changed, because older versions used to work correctly. -- 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-578) Changing goals during perform produce strange comportment
Changing goals during perform produce strange comportment
-
Key: MRELEASE-578
URL: http://jira.codehaus.org/browse/MRELEASE-578
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.0
Reporter: fabrice
Attachments: consoleText[1]
I have a Multi Module Maven project.
I personalise a profil especially for realising snapshots
Test14StandardModules
Test14standardmoduleear
Test14standardmodulewar
Test14StandardModuleBusiness
The ear - war - business
Each of them inherit from the Test14StandardModules
In the parent pom I have the profile bellow :
profile
idalmerys-release-profile/id
build
plugins
plugin
inheritedtrue/inherited
artifactIdmaven-release-plugin/artifactId
version2.0/version
configuration
preparationGoalsclean
verify/preparationGoals
useReleaseProfilefalse/useReleaseProfile
goalsantrun:run scm:checkin deploy
/goals
arguments-Dmessage=Release.properties
autocommit -Palmerys-release-profile/arguments
/configuration
/plugin
plugin
inheritedtrue/inherited
artifactIdmaven-antrun-plugin/artifactId
version1.3/version
configuration
tasks
echoCOPY
RELEASE.PROPERTIES/echo
copy
file=${WORKSPACE}/release.properties
tofile=${WORKSPACE}/.release.properties-save /
/tasks
/configuration
/plugin
plugin
inheritedtrue/inherited
artifactIdmaven-scm-plugin/artifactId
version1.3/version
configuration
includes.release.properties-save/includes
connectionTypedeveloperConnection/connectionType
workingDirectory${WORKSPACE}/workingDirectory
/configuration
/plugin
/plugins
/build
/profile
I release with the command bellow :
-Dresume=false release:prepare release:perform -P almerys-release-profile -e
It failed because the business released jar is not found.
the console output is attached
When I change the goals perform antrun:run scm:checkin deploy to deploy
antrun:run scm:checkin it works.
It seems that the perform goal run the two first goals on each module and apply
the last only on the parent pom.
Strange ?
--
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-4728) Allow repository to be disabled through settings.xml
Allow repository to be disabled through settings.xml Key: MNG-4728 URL: http://jira.codehaus.org/browse/MNG-4728 Project: Maven 2 3 Issue Type: Wish Components: Settings Affects Versions: 3.0-beta-1 Reporter: Paul Benedict Priority: Minor Sometimes our snapshot repository is down for maintenance but each build of Maven tries to download from it. This is understandable since the repository is defined in our parent POM, but the network delays introduced are too long. I recommend adding an enabled tag to repository so a repository can remain defined but optionally enabled/disabled during the build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4728) Allow repository to be disabled through settings.xml
[ http://jira.codehaus.org/browse/MNG-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=228201#action_228201 ] Benjamin Bentmann commented on MNG-4728: There is already an enabled flag for releases/snapshots, I don't see much value in adding yet another flag to complicate things. Allow repository to be disabled through settings.xml Key: MNG-4728 URL: http://jira.codehaus.org/browse/MNG-4728 Project: Maven 2 3 Issue Type: Wish Components: Settings Affects Versions: 3.0-beta-1 Reporter: Paul Benedict Priority: Minor Sometimes our snapshot repository is down for maintenance but each build of Maven tries to download from it. This is understandable since the repository is defined in our parent POM, but the network delays introduced are too long. I recommend adding an enabled tag to repository so a repository can remain defined but optionally enabled/disabled during the build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4728) Allow repository to be disabled through settings.xml
[ http://jira.codehaus.org/browse/MNG-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=228203#action_228203 ] Paul Benedict commented on MNG-4728: After I submitted the issue, I came to the same conclusion. However, the solution is indirect. Disabling both releases and snapshots gets what I want, but I had to mentally go around the bend to reach that conclusion. It's not obvious. Feel free to close the issue, however, if your opinion remains. Allow repository to be disabled through settings.xml Key: MNG-4728 URL: http://jira.codehaus.org/browse/MNG-4728 Project: Maven 2 3 Issue Type: Wish Components: Settings Affects Versions: 3.0-beta-1 Reporter: Paul Benedict Priority: Minor Sometimes our snapshot repository is down for maintenance but each build of Maven tries to download from it. This is understandable since the repository is defined in our parent POM, but the network delays introduced are too long. I recommend adding an enabled tag to repository so a repository can remain defined but optionally enabled/disabled during the build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4564) Location (and name) for settings-security.xml has changed in Maven 3
[ http://jira.codehaus.org/browse/MNG-4564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=228208#action_228208 ] Peter Lynch commented on MNG-4564: -- In case someone is needs to cross reference, this is fixed in version 1.3.3 of nexus-maven-plugin. Location (and name) for settings-security.xml has changed in Maven 3 Key: MNG-4564 URL: http://jira.codehaus.org/browse/MNG-4564 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.0-alpha-6 Environment: Windows XP SUN JDK 1.6.0_16 Reporter: Anders Hammar Assignee: Benjamin Bentmann Fix For: 3.0-alpha-7 Trying to encrypt server password (mvn --encrypt-password blabla) with Maven 3.0-alpha6 and having %USER_HOME%/.m2/settings-security.xml, I get a FileNotFoundException saying that %USER_HOME%/.settings-security.xml can't be found. Why has the name and location of this file change in Maven 3? It's not backwards compatible with Maven 2 as promised. -- 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-4728) Allow repository to be disabled through settings.xml
[ http://jira.codehaus.org/browse/MNG-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-4728. - Resolution: Won't Fix Assignee: Brett Porter I concur. I think the most obvious thing to do in this situation is run with -o. Allow repository to be disabled through settings.xml Key: MNG-4728 URL: http://jira.codehaus.org/browse/MNG-4728 Project: Maven 2 3 Issue Type: Wish Components: Settings Affects Versions: 3.0-beta-1 Reporter: Paul Benedict Assignee: Brett Porter Priority: Minor Sometimes our snapshot repository is down for maintenance but each build of Maven tries to download from it. This is understandable since the repository is defined in our parent POM, but the network delays introduced are too long. I recommend adding an enabled tag to repository so a repository can remain defined but optionally enabled/disabled during the build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MREPOSITORY-23) Wrong error message [INFO] project.scm.url must be present.
Wrong error message [INFO] project.scm.url must be present. - Key: MREPOSITORY-23 URL: http://jira.codehaus.org/browse/MREPOSITORY-23 Project: Maven 2.x Repository Plugin Issue Type: Bug Reporter: Cedric Beust When I tried to create a bundle, I got the following error: $ mvn repository:bundle-create [ERROR] BUILD ERROR [INFO] [INFO] project.scm.url must be present. Yet, my pom has this value: ... scm connectionhttp://github.com/cbeust/jcommander/connection The bug is the error message: what is missing is project.scm.connection, not url. Adding this tag fixed the problem: scm urlhttp://github.com/cbeust/jcommander/url connectionhttp://github.com/cbeust/jcommander/connection /scm -- 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: (MREPOSITORY-23) Wrong error message [INFO] project.scm.url must be present.
[ http://jira.codehaus.org/browse/MREPOSITORY-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=228225#action_228225 ] Cedric Beust commented on MREPOSITORY-23: - Bad paste, I meant: Yet, my pom has this value: ... scm urlhttp://github.com/cbeust/jcommander/url You get the idea. Wrong error message [INFO] project.scm.url must be present. - Key: MREPOSITORY-23 URL: http://jira.codehaus.org/browse/MREPOSITORY-23 Project: Maven 2.x Repository Plugin Issue Type: Bug Reporter: Cedric Beust When I tried to create a bundle, I got the following error: $ mvn repository:bundle-create [ERROR] BUILD ERROR [INFO] [INFO] project.scm.url must be present. Yet, my pom has this value: ... scm connectionhttp://github.com/cbeust/jcommander/connection The bug is the error message: what is missing is project.scm.connection, not url. Adding this tag fixed the problem: scm urlhttp://github.com/cbeust/jcommander/url connectionhttp://github.com/cbeust/jcommander/connection /scm -- 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-150) the dependency report ignores mirrors
[ http://jira.codehaus.org/browse/MPIR-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=228234#action_228234 ] Olivier Lamy commented on MPIR-150: --- please open a new issue for this. Thanks. the dependency report ignores mirrors - Key: MPIR-150 URL: http://jira.codehaus.org/browse/MPIR-150 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Components: dependencies Affects Versions: 2.1.1 Reporter: Brian Fox Assignee: Olivier Lamy Fix For: 2.2 Attachments: MPIR-150.patch The dependencies report takes forever and running debug i can see it's hitting the same repos over and over and bypassing my repository manager. -- 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: (MREPOSITORY-23) Wrong error message [INFO] project.scm.url must be present.
[ http://jira.codehaus.org/browse/MREPOSITORY-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MREPOSITORY-23. Resolution: Fixed Fix Version/s: 2.4 Assignee: Benjamin Bentmann Fixed in [r963866|http://svn.apache.org/viewvc?view=revisionrevision=963866]. Wrong error message [INFO] project.scm.url must be present. - Key: MREPOSITORY-23 URL: http://jira.codehaus.org/browse/MREPOSITORY-23 Project: Maven 2.x Repository Plugin Issue Type: Bug Reporter: Cedric Beust Assignee: Benjamin Bentmann Fix For: 2.4 When I tried to create a bundle, I got the following error: $ mvn repository:bundle-create [ERROR] BUILD ERROR [INFO] [INFO] project.scm.url must be present. Yet, my pom has this value: ... scm connectionhttp://github.com/cbeust/jcommander/connection The bug is the error message: what is missing is project.scm.connection, not url. Adding this tag fixed the problem: scm urlhttp://github.com/cbeust/jcommander/url connectionhttp://github.com/cbeust/jcommander/connection /scm -- 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: (MREPOSITORY-23) Wrong error message [INFO] project.scm.url must be present.
[ http://jira.codehaus.org/browse/MREPOSITORY-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MREPOSITORY-23: - Affects Version/s: 2.3 Wrong error message [INFO] project.scm.url must be present. - Key: MREPOSITORY-23 URL: http://jira.codehaus.org/browse/MREPOSITORY-23 Project: Maven 2.x Repository Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Cedric Beust Assignee: Benjamin Bentmann Fix For: 2.4 When I tried to create a bundle, I got the following error: $ mvn repository:bundle-create [ERROR] BUILD ERROR [INFO] [INFO] project.scm.url must be present. Yet, my pom has this value: ... scm connectionhttp://github.com/cbeust/jcommander/connection The bug is the error message: what is missing is project.scm.connection, not url. Adding this tag fixed the problem: scm urlhttp://github.com/cbeust/jcommander/url connectionhttp://github.com/cbeust/jcommander/connection /scm -- 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: (MREPOSITORY-21) 'project.scm.url must be present' error message typo - should be 'project.scm.connection must be present'
[ http://jira.codehaus.org/browse/MREPOSITORY-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MREPOSITORY-21. Resolution: Duplicate Assignee: Benjamin Bentmann 'project.scm.url must be present' error message typo - should be 'project.scm.connection must be present' - Key: MREPOSITORY-21 URL: http://jira.codehaus.org/browse/MREPOSITORY-21 Project: Maven 2.x Repository Plugin Issue Type: Bug Reporter: Paul Hammant Assignee: Benjamin Bentmann http://svn.apache.org/viewvc/maven/plugins/trunk/maven-repository-plugin/src/main/java/org/apache/maven/plugins/repository/BundleCreateMojo.java?revision=820163view=markup This is an error message twice in the source :- project.scm.url must be present cut/paste error I suspect. - Paul -- 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: (MREPOSITORY-22) repository:bundle-create ignores -f directive (different pom.xml file)
[ http://jira.codehaus.org/browse/MREPOSITORY-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MREPOSITORY-22: - Affects Version/s: 2.3 repository:bundle-create ignores -f directive (different pom.xml file) --- Key: MREPOSITORY-22 URL: http://jira.codehaus.org/browse/MREPOSITORY-22 Project: Maven 2.x Repository Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Paul Hammant MAVENUPLOAD-2738 details a case where the bundle creator attempted to make a bundle for JSR-330's TCK. To repo.. 1) svn checkout http://atinject.googlecode.com/svn/trunk/ atinject-read-only 2) cd atinject-read-only 3) mvn repository:bundle-create -f tck-pom.xml (example jar bundle's 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] Closed: (MREPOSITORY-22) repository:bundle-create ignores -f directive (different pom.xml file)
[ http://jira.codehaus.org/browse/MREPOSITORY-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MREPOSITORY-22. Resolution: Fixed Fix Version/s: 2.4 Assignee: Benjamin Bentmann Fixed in [r963891|http://svn.apache.org/viewvc?view=revisionrevision=963891]. repository:bundle-create ignores -f directive (different pom.xml file) --- Key: MREPOSITORY-22 URL: http://jira.codehaus.org/browse/MREPOSITORY-22 Project: Maven 2.x Repository Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Paul Hammant Assignee: Benjamin Bentmann Fix For: 2.4 MAVENUPLOAD-2738 details a case where the bundle creator attempted to make a bundle for JSR-330's TCK. To repo.. 1) svn checkout http://atinject.googlecode.com/svn/trunk/ atinject-read-only 2) cd atinject-read-only 3) mvn repository:bundle-create -f tck-pom.xml (example jar bundle's 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] Closed: (MREPOSITORY-20) 301 permanently moved (not following redirect)
[ http://jira.codehaus.org/browse/MREPOSITORY-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MREPOSITORY-20. Resolution: Duplicate Assignee: Benjamin Bentmann 301 permanently moved (not following redirect) -- Key: MREPOSITORY-20 URL: http://jira.codehaus.org/browse/MREPOSITORY-20 Project: Maven 2.x Repository Plugin Issue Type: Bug Affects Versions: 2.0, 2.1 Environment: maven 2.0.10 and 2.1.0 Reporter: Trenton Assignee: Benjamin Bentmann error: error reading /home/dimon/.m2/repository/org/apache/axis2/axis2- kernel/1.4.1/axis2-kernel-1.4.1.jar; error in opening zip file error: error reading /home/dimon/.m2/repository/org/apache/neethi/neethi/2.0.4/neethi-2.0.4.jar; error in opening zip file error: error reading /home/dimon/.m2/repository/org/apache/ws/commons/axiom/axiom-api/1.2.7/axiom- api-1.2.7.jar; error in opening zip file error: error reading /home/dimon/.m2/repository/org/apache/ws/commons/axiom/axiom-dom/1.2.7/axiom- dom-1.2.7.jar; error in opening zip file error: error reading /home/dimon/.m2/repository/org/codehaus/woodstox/wstx- asl/3.2.4/wstx-asl-3.2.4.jar; error in opening zip file error: error reading /home/dimon/.m2/repository/org/apache/geronimo/specs/geronimo-stax- api_1.0_spec/1.0.1/geronimo-stax-api_1.0_spec-1.0.1.jar; error in opening zip file error: error reading /home/dimon/.m2/repository/commons-io/commons- io/1.4/commons-io-1.4.jar; error in opening zip file where the content of those JARs is : !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title301 Moved Permanently/title /headbody h1Moved Permanently/h1 pThe document has moved a href=http://download.java.net/maven/1/org.apache.axis2/jars/axis2- kernel-1.4.1.jarhere/a./p hr addressApache Server at maven-repository.dev.java.net Port 443/address /body/html nuking files and re-running didn't help :( -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MANTTASKS-191) No explanation of how to use multiple Maven repositories to resolve dependencies
[ http://jira.codehaus.org/browse/MANTTASKS-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=228247#action_228247 ] Knut Forkalsrud commented on MANTTASKS-191: --- I did some debugging here, and it turns out the central repository comes from the pom, or more specifically pom.getRepositories() near line 187 of DependenciesTask.java. There is no repository element declared in pom.xml, so it must come from some implicit parent pom. No explanation of how to use multiple Maven repositories to resolve dependencies Key: MANTTASKS-191 URL: http://jira.codehaus.org/browse/MANTTASKS-191 Project: Maven 2.x Ant Tasks Issue Type: Bug Components: documentation Affects Versions: 2.1.0 Reporter: SebbASF There does not seem to be any documentation on how to use multiple repositories when resolving dependencies. -- 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-579) Branch fails with error message
Branch fails with error message Key: MRELEASE-579 URL: http://jira.codehaus.org/browse/MRELEASE-579 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.0 Environment: Mac OS X 10.6, git version 1.7.1 Reporter: Tommy Odom When attempting to run release:branch from my master branch I get an error message that the git commit failed. It appears that when I run mvn release:branch from my master branch that when it tries to execute the commit after modifying the POMs that it fails because none of the POMs were actually modified initially (nothing to change for git to create the branch). Since the initial commit for preparing the branch fails no branch is created and the POMs in the master branch are not modified for the new development version. Output: [INFO] Transforming 'Focal'... [DEBUG] No SCM translator found - skipping rewrite [INFO] Updating runtime-libs to 2.4.7-SNAPSHOT ... [INFO] Checking in modified POMs... [INFO] Executing: /bin/sh -c cd /Users/odom/release/focal git add -- pom.xml ... [INFO] Working directory: /Users/odom/release/focal [INFO] Executing: /bin/sh -c cd /Users/odom/release/focal git status [INFO] Working directory: /Users/odom/release/focal [DEBUG] # On branch master [DEBUG] # Untracked files: [DEBUG] # (use git add file... to include in what will be committed) [DEBUG] # [DEBUG] # pom.xml.releaseBackup ... [DEBUG] nothing added to commit but untracked files present (use git add to track) [INFO] Executing: /bin/sh -c cd /Users/odom/release/focal git commit --verbose -F /var/folders/3P/3PAWYpw+HQWPH0rThcSoQTQ/-Tmp-/maven-scm-549427758.commit pom.xml ... [INFO] Working directory: /Users/odom/release/focal [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Unable to commit files Provider message: The git-commit command failed. Command output: [INFO] [DEBUG] Trace org.apache.maven.BuildFailureException: Unable to commit files Provider message: The git-commit command failed. Command output: at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:699) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoFailureException: Unable to commit files Provider message: The git-commit command failed. Command output: at org.apache.maven.plugins.release.BranchReleaseMojo.execute(BranchReleaseMojo.java:186) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) ... 17 more Caused by: org.apache.maven.shared.release.scm.ReleaseScmCommandException: Unable to commit files Provider message: The git-commit command failed. Command output: at org.apache.maven.shared.release.phase.ScmCommitPhase.checkin(ScmCommitPhase.java:133) at org.apache.maven.shared.release.phase.ScmCommitPhase.execute(ScmCommitPhase.java:109) at org.apache.maven.shared.release.DefaultReleaseManager.branch(DefaultReleaseManager.java:389) at
