[jira] (MNG-4188) Add a 'finally' phase.
[
https://jira.codehaus.org/browse/MNG-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339852#comment-339852
]
Charlie Mordant commented on MNG-4188:
--
What about a plugin xml element?
plugin
idmyPluginWhoNeedToExecuteAnOtherIfItFails/id
finallyRefs
finnallyRefmyPluginOrExecutionIdWhichMuchBeExecutedIfBuildFailsAndThatWeHaveNotReachedItsConventionalRunPhase/finnallyRef
/finallyRefs
...
/plugin
plugin
idmyPluginOrExecutionIdWhichMuchBeExecutedIfBuildFailsAndThatWeHaveNotReachedItsConventionalRunPhase/id
...
/plugin
Add a 'finally' phase.
--
Key: MNG-4188
URL: https://jira.codehaus.org/browse/MNG-4188
Project: Maven 2 3
Issue Type: Wish
Components: Plugins and Lifecycle
Affects Versions: Issues to be reviewed for 3.x
Reporter: Christian Schulte
Priority: Minor
Fix For: Issues to be reviewed for 3.x
When Maven executes a lifecycle, it does not execute any phases succeeding a
failing phase. It would be great if Maven supports a 'finally' phase, which
is guaranteed to run regardless of the state of the lifecycle just like a
Java 'finally' block. The use case I would need such a phase for is the
following:
{code}
profile
idsourceforge-shell/id
activation
activeByDefaultfalse/activeByDefault
/activation
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
dependencies
dependency
groupIdorg.apache.ant/groupId
artifactIdant-jsch/artifactId
version1.7.1/version
/dependency
/dependencies
executions
execution
idcreate-sourceforge-shell/id
phasevalidate/phase
goals
goalrun/goal
/goals
configuration
tasks
sshexec host=shell.sourceforge.net
username=${sf.username},${sf.project} password=${sf.password}
command=create timeout=30 /
/tasks
/configuration
/execution
execution
idcreate-sourceforge-shell-site/id
phasepre-site/phase
goals
goalrun/goal
/goals
configuration
tasks
sshexec host=shell.sourceforge.net
username=${sf.username},${sf.project} password=${sf.password}
command=create timeout=30 /
/tasks
/configuration
/execution
execution
idshutdown-sourceforge-shell/id
phasedeploy/phase
goals
goalrun/goal
/goals
configuration
tasks
sshexec host=shell.sourceforge.net
username=${sf.username},${sf.project} password=${sf.password}
command=shutdown timeout=30 /
echo message=Sleeping for 1 minute waiting for shutdown
of shell. /
sleep minutes=1 /
/tasks
/configuration
/execution
execution
idshutdown-sourceforge-shell-site/id
phasesite-deploy/phase
goals
goalrun/goal
/goals
configuration
tasks
sshexec host=shell.sourceforge.net
username=${sf.username},${sf.project} password=${sf.password}
command=shutdown timeout=30 /
echo message=Sleeping for 1 minute waiting for shutdown
of shell. /
sleep minutes=1 /
/tasks
/configuration
/execution
/executions
/plugin
/plugins
/build
/profile
{code}
I am currently using this profile when deploying to sourceforge. The problem
is, that the shell won't get shutdown, whenever a build fails. It needs to
get shutdown, so that a build for another SF project can succeed. In the
example above, the two executions 'shutdown-sourceforge-shell' and
'shutdown-sourceforge-shell-site' could be bound to a 'finally' phase and
could shutdown the shell regardless of the outcome of the build.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4188) Add a 'finally' phase.
[
https://jira.codehaus.org/browse/MNG-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339852#comment-339852
]
Charlie Mordant edited comment on MNG-4188 at 1/23/14 3:15 AM:
---
What about a plugin xml element?
{quote}
plugin
idmyPluginWhoNeedToExecuteAnOtherIfItFails/id
finallyRefs
finnallyRefmyPluginOrExecutionIdWhichMuchBeExecutedIfBuildFailsAndThatWeHaveNotReachedItsConventionalRunPhase/finnallyRef
/finallyRefs
...
/plugin
plugin
idmyPluginOrExecutionIdWhichMuchBeExecutedIfBuildFailsAndThatWeHaveNotReachedItsConventionalRunPhase/id
...
/plugin
{quote}
was (Author: tcharl):
What about a plugin xml element?
plugin
idmyPluginWhoNeedToExecuteAnOtherIfItFails/id
finallyRefs
finnallyRefmyPluginOrExecutionIdWhichMuchBeExecutedIfBuildFailsAndThatWeHaveNotReachedItsConventionalRunPhase/finnallyRef
/finallyRefs
...
/plugin
plugin
idmyPluginOrExecutionIdWhichMuchBeExecutedIfBuildFailsAndThatWeHaveNotReachedItsConventionalRunPhase/id
...
/plugin
Add a 'finally' phase.
--
Key: MNG-4188
URL: https://jira.codehaus.org/browse/MNG-4188
Project: Maven 2 3
Issue Type: Wish
Components: Plugins and Lifecycle
Affects Versions: Issues to be reviewed for 3.x
Reporter: Christian Schulte
Priority: Minor
Fix For: Issues to be reviewed for 3.x
When Maven executes a lifecycle, it does not execute any phases succeeding a
failing phase. It would be great if Maven supports a 'finally' phase, which
is guaranteed to run regardless of the state of the lifecycle just like a
Java 'finally' block. The use case I would need such a phase for is the
following:
{code}
profile
idsourceforge-shell/id
activation
activeByDefaultfalse/activeByDefault
/activation
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
dependencies
dependency
groupIdorg.apache.ant/groupId
artifactIdant-jsch/artifactId
version1.7.1/version
/dependency
/dependencies
executions
execution
idcreate-sourceforge-shell/id
phasevalidate/phase
goals
goalrun/goal
/goals
configuration
tasks
sshexec host=shell.sourceforge.net
username=${sf.username},${sf.project} password=${sf.password}
command=create timeout=30 /
/tasks
/configuration
/execution
execution
idcreate-sourceforge-shell-site/id
phasepre-site/phase
goals
goalrun/goal
/goals
configuration
tasks
sshexec host=shell.sourceforge.net
username=${sf.username},${sf.project} password=${sf.password}
command=create timeout=30 /
/tasks
/configuration
/execution
execution
idshutdown-sourceforge-shell/id
phasedeploy/phase
goals
goalrun/goal
/goals
configuration
tasks
sshexec host=shell.sourceforge.net
username=${sf.username},${sf.project} password=${sf.password}
command=shutdown timeout=30 /
echo message=Sleeping for 1 minute waiting for shutdown
of shell. /
sleep minutes=1 /
/tasks
/configuration
/execution
execution
idshutdown-sourceforge-shell-site/id
phasesite-deploy/phase
goals
goalrun/goal
/goals
configuration
tasks
sshexec host=shell.sourceforge.net
username=${sf.username},${sf.project} password=${sf.password}
command=shutdown timeout=30 /
echo message=Sleeping for 1 minute waiting for shutdown
of shell. /
sleep minutes=1 /
/tasks
/configuration
/execution
/executions
/plugin
/plugins
/build
/profile
{code}
I am currently using this profile when deploying to sourceforge. The problem
is, that the shell won't get shutdown, whenever a build fails. It needs to
get shutdown, so that a build for another SF project can succeed. In the
example above, the two executions
[jira] (MNG-4188) Add a 'finally' phase.
[
https://jira.codehaus.org/browse/MNG-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339852#comment-339852
]
Charlie Mordant edited comment on MNG-4188 at 1/23/14 3:16 AM:
---
What about a plugin xml element?
{code}
plugin
idmyPluginWhoNeedToExecuteAnOtherIfItFails/id
finallyRefs
finnallyRefmyPluginOrExecutionIdWhichMuchBeExecutedIfBuildFailsAndThatWeHaveNotReachedItsConventionalRunPhase/finnallyRef
/finallyRefs
...
/plugin
plugin
idmyPluginOrExecutionIdWhichMuchBeExecutedIfBuildFailsAndThatWeHaveNotReachedItsConventionalRunPhase/id
...
/plugin
{code}
was (Author: tcharl):
What about a plugin xml element?
{quote}
plugin
idmyPluginWhoNeedToExecuteAnOtherIfItFails/id
finallyRefs
finnallyRefmyPluginOrExecutionIdWhichMuchBeExecutedIfBuildFailsAndThatWeHaveNotReachedItsConventionalRunPhase/finnallyRef
/finallyRefs
...
/plugin
plugin
idmyPluginOrExecutionIdWhichMuchBeExecutedIfBuildFailsAndThatWeHaveNotReachedItsConventionalRunPhase/id
...
/plugin
{quote}
Add a 'finally' phase.
--
Key: MNG-4188
URL: https://jira.codehaus.org/browse/MNG-4188
Project: Maven 2 3
Issue Type: Wish
Components: Plugins and Lifecycle
Affects Versions: Issues to be reviewed for 3.x
Reporter: Christian Schulte
Priority: Minor
Fix For: Issues to be reviewed for 3.x
When Maven executes a lifecycle, it does not execute any phases succeeding a
failing phase. It would be great if Maven supports a 'finally' phase, which
is guaranteed to run regardless of the state of the lifecycle just like a
Java 'finally' block. The use case I would need such a phase for is the
following:
{code}
profile
idsourceforge-shell/id
activation
activeByDefaultfalse/activeByDefault
/activation
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
dependencies
dependency
groupIdorg.apache.ant/groupId
artifactIdant-jsch/artifactId
version1.7.1/version
/dependency
/dependencies
executions
execution
idcreate-sourceforge-shell/id
phasevalidate/phase
goals
goalrun/goal
/goals
configuration
tasks
sshexec host=shell.sourceforge.net
username=${sf.username},${sf.project} password=${sf.password}
command=create timeout=30 /
/tasks
/configuration
/execution
execution
idcreate-sourceforge-shell-site/id
phasepre-site/phase
goals
goalrun/goal
/goals
configuration
tasks
sshexec host=shell.sourceforge.net
username=${sf.username},${sf.project} password=${sf.password}
command=create timeout=30 /
/tasks
/configuration
/execution
execution
idshutdown-sourceforge-shell/id
phasedeploy/phase
goals
goalrun/goal
/goals
configuration
tasks
sshexec host=shell.sourceforge.net
username=${sf.username},${sf.project} password=${sf.password}
command=shutdown timeout=30 /
echo message=Sleeping for 1 minute waiting for shutdown
of shell. /
sleep minutes=1 /
/tasks
/configuration
/execution
execution
idshutdown-sourceforge-shell-site/id
phasesite-deploy/phase
goals
goalrun/goal
/goals
configuration
tasks
sshexec host=shell.sourceforge.net
username=${sf.username},${sf.project} password=${sf.password}
command=shutdown timeout=30 /
echo message=Sleeping for 1 minute waiting for shutdown
of shell. /
sleep minutes=1 /
/tasks
/configuration
/execution
/executions
/plugin
/plugins
/build
/profile
{code}
I am currently using this profile when deploying to sourceforge. The problem
is, that the shell won't get shutdown, whenever a build fails. It needs to
get shutdown, so that a build for another SF project can succeed. In the
example above, the two executions
[jira] (MNG-4188) Add a 'finally' phase.
[
https://jira.codehaus.org/browse/MNG-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339852#comment-339852
]
Charlie Mordant edited comment on MNG-4188 at 1/23/14 3:17 AM:
---
What about a plugin xml element?
{code}
plugin
idmyPluginWhoNeedToExecuteAnOtherIfItFails/id
finallyRefs
finnallyRefmyPluginOrExecutionIdWhichMuchBeExecutedIfBuildFailsAndThatWeHaveNotReachedItsPhase/finnallyRef
/finallyRefs
...
/plugin
plugin
idmyPluginOrExecutionIdWhichMuchBeExecutedIfBuildFailsAndThatWeHaveNotReachedItsPhase/id
...
/plugin
{code}
was (Author: tcharl):
What about a plugin xml element?
{code}
plugin
idmyPluginWhoNeedToExecuteAnOtherIfItFails/id
finallyRefs
finnallyRefmyPluginOrExecutionIdWhichMuchBeExecutedIfBuildFailsAndThatWeHaveNotReachedItsConventionalRunPhase/finnallyRef
/finallyRefs
...
/plugin
plugin
idmyPluginOrExecutionIdWhichMuchBeExecutedIfBuildFailsAndThatWeHaveNotReachedItsConventionalRunPhase/id
...
/plugin
{code}
Add a 'finally' phase.
--
Key: MNG-4188
URL: https://jira.codehaus.org/browse/MNG-4188
Project: Maven 2 3
Issue Type: Wish
Components: Plugins and Lifecycle
Affects Versions: Issues to be reviewed for 3.x
Reporter: Christian Schulte
Priority: Minor
Fix For: Issues to be reviewed for 3.x
When Maven executes a lifecycle, it does not execute any phases succeeding a
failing phase. It would be great if Maven supports a 'finally' phase, which
is guaranteed to run regardless of the state of the lifecycle just like a
Java 'finally' block. The use case I would need such a phase for is the
following:
{code}
profile
idsourceforge-shell/id
activation
activeByDefaultfalse/activeByDefault
/activation
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
dependencies
dependency
groupIdorg.apache.ant/groupId
artifactIdant-jsch/artifactId
version1.7.1/version
/dependency
/dependencies
executions
execution
idcreate-sourceforge-shell/id
phasevalidate/phase
goals
goalrun/goal
/goals
configuration
tasks
sshexec host=shell.sourceforge.net
username=${sf.username},${sf.project} password=${sf.password}
command=create timeout=30 /
/tasks
/configuration
/execution
execution
idcreate-sourceforge-shell-site/id
phasepre-site/phase
goals
goalrun/goal
/goals
configuration
tasks
sshexec host=shell.sourceforge.net
username=${sf.username},${sf.project} password=${sf.password}
command=create timeout=30 /
/tasks
/configuration
/execution
execution
idshutdown-sourceforge-shell/id
phasedeploy/phase
goals
goalrun/goal
/goals
configuration
tasks
sshexec host=shell.sourceforge.net
username=${sf.username},${sf.project} password=${sf.password}
command=shutdown timeout=30 /
echo message=Sleeping for 1 minute waiting for shutdown
of shell. /
sleep minutes=1 /
/tasks
/configuration
/execution
execution
idshutdown-sourceforge-shell-site/id
phasesite-deploy/phase
goals
goalrun/goal
/goals
configuration
tasks
sshexec host=shell.sourceforge.net
username=${sf.username},${sf.project} password=${sf.password}
command=shutdown timeout=30 /
echo message=Sleeping for 1 minute waiting for shutdown
of shell. /
sleep minutes=1 /
/tasks
/configuration
/execution
/executions
/plugin
/plugins
/build
/profile
{code}
I am currently using this profile when deploying to sourceforge. The problem
is, that the shell won't get shutdown, whenever a build fails. It needs to
get shutdown, so that a build for another SF project can succeed. In the
example above, the two executions 'shutdown-sourceforge-shell' and
[jira] (MNG-3397) [RFC] change the POM to use attributes
[ https://jira.codehaus.org/browse/MNG-3397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339860#comment-339860 ] Jifeng Zhang commented on MNG-3397: --- It would be great to have this feature. At least 50% of the lines of my poms are the dependencies section. With the support of using attributes, the dependency section will be reduced at least 70% in length and more easy to read. For example, from 4 lines: dependency groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.16/version /dependency to one line: dependency groupId=org.apache.maven.plugins artifactId=maven-surefire-plugin version=2.16/ [RFC] change the POM to use attributes -- Key: MNG-3397 URL: https://jira.codehaus.org/browse/MNG-3397 Project: Maven 2 3 Issue Type: Bug Components: POM Affects Versions: 2.0.8 Reporter: Brett Porter Fix For: Issues to be reviewed for 4.x -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3397) [RFC] change the POM to use attributes
[
https://jira.codehaus.org/browse/MNG-3397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339860#comment-339860
]
Jifeng Zhang edited comment on MNG-3397 at 1/23/14 5:21 AM:
It would be great to have this feature. At least 50% of the lines of my poms is
the dependencies section. With the support of using attributes, the dependency
section will be reduced at least 70% in lines and more easy to read.
For example, from 4 lines:
{code:xml}
dependency
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version2.16/version
/dependency
{code}
to just one line:
{code:xml}
dependency groupId=org.apache.maven.plugins
artifactId=maven-surefire-plugin version=2.16/
{code}
was (Author: jifeng.zhang):
It would be great to have this feature. At least 50% of the lines of my
poms are the dependencies section. With the support of using attributes, the
dependency section will be reduced at least 70% in length and more easy to read.
For example, from 4 lines:
dependency
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version2.16/version
/dependency
to one line:
dependency groupId=org.apache.maven.plugins
artifactId=maven-surefire-plugin version=2.16/
[RFC] change the POM to use attributes
--
Key: MNG-3397
URL: https://jira.codehaus.org/browse/MNG-3397
Project: Maven 2 3
Issue Type: Bug
Components: POM
Affects Versions: 2.0.8
Reporter: Brett Porter
Fix For: Issues to be reviewed for 4.x
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5533) M2 vs M3
[ https://jira.codehaus.org/browse/MNG-5533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5533. -- Resolution: Won't Fix M2 vs M3 Key: MNG-5533 URL: https://jira.codehaus.org/browse/MNG-5533 Project: Maven 2 3 Issue Type: Improvement Components: Class Loading, Command Line, Documentation: General, General Affects Versions: Issues to be reviewed for 3.x Environment: Windows Reporter: Martin Spamer Priority: Critical Maven 3 uses the M2 environment variable. Surely it would be more reasonable to update this to M3 to allow sensible migration. e.g M2=C:\Program Files\Apache Software Foundation\apache-maven-2.2.1\bin M2_HOME=C:\Program Files\Apache Software Foundation\apache-maven-2.2.1 M3=C:\Program Files\Apache Software Foundation\apache-maven-3.1.1\bin M3_HOME=C:\Program Files\Apache Software Foundation\apache-maven-3.1.1 MAVEN=%M2% or MAVEN=%M3% PATH=%MAVEN%;%PATH% -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5533) M2 vs M3
[ https://jira.codehaus.org/browse/MNG-5533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339879#comment-339879 ] Jason van Zyl commented on MNG-5533: The scripts are fine they way they are, and what Jörg Schaible outlines is perfectly fine. I use 8 versions of Maven simultaneously without issue. M2 vs M3 Key: MNG-5533 URL: https://jira.codehaus.org/browse/MNG-5533 Project: Maven 2 3 Issue Type: Improvement Components: Class Loading, Command Line, Documentation: General, General Affects Versions: Issues to be reviewed for 3.x Environment: Windows Reporter: Martin Spamer Priority: Critical Maven 3 uses the M2 environment variable. Surely it would be more reasonable to update this to M3 to allow sensible migration. e.g M2=C:\Program Files\Apache Software Foundation\apache-maven-2.2.1\bin M2_HOME=C:\Program Files\Apache Software Foundation\apache-maven-2.2.1 M3=C:\Program Files\Apache Software Foundation\apache-maven-3.1.1\bin M3_HOME=C:\Program Files\Apache Software Foundation\apache-maven-3.1.1 MAVEN=%M2% or MAVEN=%M3% PATH=%MAVEN%;%PATH% -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5539) Profile plugin execution order is not preserved when merging into default PluginContainer
[
https://jira.codehaus.org/browse/MNG-5539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339878#comment-339878
]
Jason van Zyl commented on MNG-5539:
Please read
https://cwiki.apache.org/confluence/display/MAVEN/Submitting+Issue+for+Maven's+Core
Profile plugin execution order is not preserved when merging into default
PluginContainer
-
Key: MNG-5539
URL: https://jira.codehaus.org/browse/MNG-5539
Project: Maven 2 3
Issue Type: Bug
Components: Plugins and Lifecycle, POM, Profiles
Affects Versions: 3.0.5, 3.1.0
Reporter: David Eckel
Priority: Minor
The order of execution of plugins within a profile unexpectedly depends upon
the order of plugin definitions outside of the profile if the profile
references those same plugins, even if they do not specify executions in the
same phase. In the following example pom snippet, when run with 'mvn
validate', 'plugin-B-in-profile' will execute first, then
'plugin-A-in-profile', when the opposite execution - the order in which they
were defined - was desired.
{code:xml}
build
plugins
!-- if you swap the order of these two plugins or remove one, the
order of the profile plugin execution will change --
plugin
artifactIdmaven-jar-plugin/artifactId
/plugin
plugin
artifactIdmaven-antrun-plugin/artifactId
/plugin
/plugins
/build
profiles
profile
activation
activeByDefaulttrue/activeByDefault
/activation
build
plugins
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
idplugin-A-in-profile/id
phasevalidate/phase
goals
goalrun/goal
/goals
/execution
/executions
/plugin
plugin
artifactIdmaven-clean-plugin/artifactId
executions
execution
idplugin-B-in-profile/id
phasevalidate/phase
goals
goalclean/goal
/goals
/execution
/executions
/plugin
!-- Removing this plugin declaration will cause above
plugins to run in a different order --
plugin
artifactIdmaven-jar-plugin/artifactId
/plugin
/plugins
/build
/profile
/profiles
{code}
See
{{org.apache.maven.model.profile.DefaultProfileInjector$ProfileModelMerger.mergePluginContainer_Plugins()}}.
It's unclear to me if this algorithm is intentional to aggregate all plugin
definitions in the same way that you cannot declare the same plugin more than
once in a given PluginContainer, or if profiles should always have their
execution order respected, regardless of plugin definitions outside of the
profile.
This may be a similar or the same issue as MNG-5478, but it's unclear due to
lack of information.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5561) Plugin relocation looses configuration
[
https://jira.codehaus.org/browse/MNG-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339877#comment-339877
]
Jason van Zyl commented on MNG-5561:
Please read:
https://cwiki.apache.org/confluence/display/MAVEN/Submitting+Issue+for+Maven's+Core
Plugin relocation looses configuration
--
Key: MNG-5561
URL: https://jira.codehaus.org/browse/MNG-5561
Project: Maven 2 3
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 3.1.1
Reporter: Julien CARSIQUE
Hi,
Applying a relocation on a plugin seems to loose its configuration.
In the following sample, I relocated nuxeo-distribution-tools to
ant-assembly-maven-plugin and the missing configured parameter is
buildFile. The relocation itself went well but the execution fails because
of a missing parameter.
{code:title=~/.m2/repository/org/nuxeo/build/nuxeo-distribution-tools/2.0-SNAPSHOT/nuxeo-distribution-tools-2.0-SNAPSHOT.pom}
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdorg.nuxeo.build/groupId
artifactIdnuxeo-distribution-tools/artifactId
version2.0-SNAPSHOT/version
packagingmaven-plugin/packaging
nameNuxeo Distribution Build/name
descriptionAssemble Nuxeo distributions/description
distributionManagement
relocation
artifactIdant-assembly-maven-plugin/artifactId
/relocation
/distributionManagement
/project{code}
{code:title=executed POM extract}
build
plugins
plugin
groupIdorg.nuxeo.build/groupId
!-- With relocation --
artifactIdnuxeo-distribution-tools/artifactId
!-- Without relocation --
!-- artifactIdant-assembly-maven-plugin/artifactId --
executions
execution
idassemble/id
phasepackage/phase
configuration
!-- The missing parameter in case of relocation --
buildFilesrc/main/assemble/assembly.xml/buildFile
/configuration
goals
goalbuild/goal
/goals
/execution
/executions
/plugin
/plugins
/build
{code}
Here is the diff between an mvn package -X with nuxeo-distribution-tools
(ie: with relocation; line starting with ) and another one with
ant-assembly-maven-plugin (ie: without relocation; line starting with ):
{noformat} [DEBUG] Dependency collection stats:
{ConflictMarker.analyzeTime=1, ConflictMarker.markTime=0,
ConflictMarker.nodeCount=72, ConflictIdSorter.graphTime=0,
ConflictIdSorter.topsortTime=0, ConflictIdSorter.conflictIdCount=34,
ConflictIdSorter.conflictIdCycleCount=0, ConflictResolver.totalTime=1,
ConflictResolver.conflictItemCount=71,
DefaultDependencyCollector.collectTime=10,
DefaultDependencyCollector.transformTime=2}
[DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=1,
ConflictMarker.markTime=0, ConflictMarker.nodeCount=72,
ConflictIdSorter.graphTime=0, ConflictIdSorter.topsortTime=0,
ConflictIdSorter.conflictIdCount=34,
ConflictIdSorter.conflictIdCycleCount=0, ConflictResolver.totalTime=2,
ConflictResolver.conflictItemCount=71,
DefaultDependencyCollector.collectTime=65,
DefaultDependencyCollector.transformTime=3}
---
[DEBUG] Created new class realm
pluginorg.nuxeo.build:nuxeo-distribution-tools:2.0-SNAPSHOT
[DEBUG] Importing foreign packages into class realm
pluginorg.nuxeo.build:nuxeo-distribution-tools:2.0-SNAPSHOT
[DEBUG] Created new class realm
pluginorg.nuxeo.build:ant-assembly-maven-plugin:2.0-SNAPSHOT
[DEBUG] Importing foreign packages into class realm
pluginorg.nuxeo.build:ant-assembly-maven-plugin:2.0-SNAPSHOT
---
[DEBUG] Populating class realm
pluginorg.nuxeo.build:nuxeo-distribution-tools:2.0-SNAPSHOT
[DEBUG] Populating class realm
pluginorg.nuxeo.build:ant-assembly-maven-plugin:2.0-SNAPSHOT
---
[DEBUG] Configuring mojo
org.nuxeo.build:ant-assembly-maven-plugin:2.0-SNAPSHOT:build from plugin
realm
ClassRealm[pluginorg.nuxeo.build:nuxeo-distribution-tools:2.0-SNAPSHOT,
parent: sun.misc.Launcher$AppClassLoader@591ce4fe]
[DEBUG] Configuring mojo
org.nuxeo.build:ant-assembly-maven-plugin:2.0-SNAPSHOT:build from plugin
realm
ClassRealm[pluginorg.nuxeo.build:ant-assembly-maven-plugin:2.0-SNAPSHOT,
parent: sun.misc.Launcher$AppClassLoader@77fe0d66]
---
[DEBUG] (f) buildFile =
/home/julien/ws-ssd/nuxeo/nuxeo-distribution/nuxeo-distribution-resources/src/main/assemble/assembly.xml{noformat}
The last line highlights the missing parameter.
Indeed, it seems that in case of a relocation, all the Parameter
[jira] (MNG-5522) properties project.parent.xxx not supported under Linux
[
https://jira.codehaus.org/browse/MNG-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339882#comment-339882
]
Jason van Zyl commented on MNG-5522:
Please read
https://cwiki.apache.org/confluence/display/MAVEN/Submitting+Issue+for+Maven's+Core
properties project.parent.xxx not supported under Linux
---
Key: MNG-5522
URL: https://jira.codehaus.org/browse/MNG-5522
Project: Maven 2 3
Issue Type: Bug
Components: Bootstrap Build, POM
Affects Versions: 3.0.5
Environment: Few Linuxes tested, work under Windows
Reporter: Pavel
Initially it was there:
https://jira.codehaus.org/browse/MRM-1772#comment-333654 . But It is maven
problem itself.
It is reproducible on two our Linux machines (Fedora and Gentoo), so it may
be Linux relative. On all our colleagues on windows it does not reproduced.
Some details.
Parent pom among others have:
{code}
version1.5.300-SNAPSHOT/version
nameimus/name
...
properties
spring.version2.5.6/spring.version
spring3.version3.2.2.RELEASE/spring3.version
mule.version2.1.1/mule.version
aspectj.version1.7.0/aspectj.version
source.encodingwindows-1251/source.encoding
maven.test.includenone/maven.test.include
maven.compiler.source1.7/maven.compiler.source
maven.compiler.target1.7/maven.compiler.target
rootProjectPath${basedir}/rootProjectPath
rootProjectPath1QWERTY/rootProjectPath1
/properties
{code}
First child module:
{code}
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
version1.1/version
executions
execution
phasevalidate/phase
goals
goalrun/goal
/goals
configuration
tasks
echo[project.parent.rootProjectPath]:
${project.parent.rootProjectPath}/echo
echo[project.parent.getRootProjectPath()]:
${project.parent.getRootProjectPath()}/echo
echo[project.parent.rootProjectPath1]:
${project.parent.rootProjectPath1}/echo
echo[project.parent.spring3.version]:
${project.parent.spring3.version}/echo
echo[project.parent.properties.spring3.version]:
${project.parent.properties.spring3.version}/echo
echo[project.parent.properties.rootProjectPath]:
${project.parent.properties.rootProjectPath}/echo
echo[project.parent.properties.rootProjectPath1]:
${project.parent.properties.rootProjectPath1}/echo
echo[project.parent.name]: ${project.parent.name}/echo
echo[project.parent.properties]: ${project.parent.properties}/echo
/tasks
/configuration
/execution
/executions
/plugin
/plugins
/build
{code}
*In out I see what project.parent.name resolved and even
project.parent.properties, but not any property in collection (f.e.
project.parent.rootProjectPath or project.parent.properties.rootProjectPath)
as it should [by documentation|http://maven.apache.org/pom.html#Properties]*:
{code}
[INFO] --- maven-antrun-plugin:1.1:run (default) @ antinform-lib-parent ---
[INFO] Executing tasks
[echo] [project.parent.rootProjectPath]:
${project.parent.rootProjectPath}
[echo] [project.parent.getRootProjectPath()]:
${project.parent.getRootProjectPath()}
[echo] [project.parent.rootProjectPath1]:
${project.parent.rootProjectPath1}
[echo] [project.parent.spring3.version]:
${project.parent.spring3.version}
[echo] [project.parent.properties.spring3.version]:
[jira] (MNG-5527) Relocation does not work for imported poms
[
https://jira.codehaus.org/browse/MNG-5527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339880#comment-339880
]
Jason van Zyl commented on MNG-5527:
Please read
https://cwiki.apache.org/confluence/display/MAVEN/Submitting+Issue+for+Maven's+Core
Relocation does not work for imported poms
--
Key: MNG-5527
URL: https://jira.codehaus.org/browse/MNG-5527
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Environment: maven-3.1.0
Fedora 18 x86_64
Reporter: Matous Jobanek
Consider the following scenario:
{code:xml}
project
modelVersion4.0.0/modelVersion
groupIdold.groupId.bom/groupId
artifactIdmy-artifactId-bom/artifactId
version1.0/version
packagingpom/packaging
distributionManagement
relocation
groupIdnew.groupId.bom/groupId
artifactIdmy-artifactId-bom/artifactId
version2.0/version
/relocation
/distributionManagement
/project
{code}
{code:xml}
project
modelVersion4.0.0/modelVersion
groupIdmy.project.groupId/groupId
artifactIdmy-project/artifactId
version1.0/version
packagingwar/packaging
dependencyManagement
dependencies
dependency
groupIdold.groupId.bom/groupId
artifactIdmy-artifactId-bom/artifactId
version1.0/version
typepom/type
scopeimport/scope
/dependency
/dependencies
/dependencyManagement
...
/project
{code}
The expected result according to [1]:
During building the my-project it should print the WARNING with the
information about the relocation and it should be automatically redirected
from old.groupId.bom:my-artifactId-bom:1.0 to
new.groupId.bom:my-artifactId-bom:2.0 and use dependencies from the new pom.
Actual results:
There is no WARNING and no redirection to the new pom and maven is trying to
obtain dependencies from the old pom (old.groupId.bom:my-artifactId-bom:1.0).
Nevertheless, when the pom is declared as a normal dependency (not in the
dependencyManagement part) it works without any problem - it prints the
WARNING and redirects to the new pom, but this is not the case we are using.
[1] http://maven.apache.org/guides/mini/guide-relocation.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5526) parent with 'RELEASE' version not resolved when only maven-metadata-local.xml (with a SNAPSHOT pom) file available in the local nexus repo
[ https://jira.codehaus.org/browse/MNG-5526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339881#comment-339881 ] Jason van Zyl commented on MNG-5526: Please read https://cwiki.apache.org/confluence/display/MAVEN/Submitting+Issue+for+Maven's+Core parent with 'RELEASE' version not resolved when only maven-metadata-local.xml (with a SNAPSHOT pom) file available in the local nexus repo -- Key: MNG-5526 URL: https://jira.codehaus.org/browse/MNG-5526 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Affects Versions: 3.0.3, 3.0.4, 3.0.5 Reporter: Nico De Groote Priority: Critical Attachments: artifact_pom.xml, parent-pom.xml We have a parent pom project containing all infrastructure + plugin version to be used by all our projects. We always point to the RELEASE of this parent pom for our projects. However when there is only a maven-metadata-local.xml in our local nexus repo, we get the following error. Non-resolvable parent POM: Failed to resolve version for be.company:parent:pom:RELEASE and 'parent.relativePath' points at wrong local POM @ line 3, column 11 - [Help 2] org.apache.maven.model.resolution.UnresolvableModelException: Failed to resolve version for be.company:parent:pom:RELEASE at org.apache.maven.project.ProjectModelResolver.resolveModel(ProjectModelResolver.java:159) at org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:819) at org.apache.maven.model.building.DefaultModelBuilder.readParent(DefaultModelBuilder.java:670) at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:308) at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:232) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:386) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:355) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:319) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:632) at org.apache.maven.DefaultMaven.getProjectsForMavenReactor(DefaultMaven.java:581) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:233) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.sonatype.aether.resolution.ArtifactResolutionException: Failed to resolve version for be.company:parent:pom:RELEASE at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:541) at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:220) at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:197) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:323) at org.apache.maven.project.ProjectModelResolver.resolveModel(ProjectModelResolver.java:155) ... 22 more Caused by: org.sonatype.aether.resolution.VersionResolutionException: Failed to resolve version for be.company:parent:pom:RELEASE at org.apache.maven.repository.internal.DefaultVersionResolver.resolveVersion(DefaultVersionResolver.java:273) at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:276) ... 26 more When we remove this meta-data-local.xml file, all works fine again. It also works fine if there are already som maven-metadata-nexus.xml files available I could reproduce this by using the following pom projects (see attachments), and following these steps: 1) deploy a version
[jira] (MNG-5517) Supporting semver like syntax for version tag
[ https://jira.codehaus.org/browse/MNG-5517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5517: --- Fix Version/s: Issues to be reviewed for 4.x Supporting semver like syntax for version tag --- Key: MNG-5517 URL: https://jira.codehaus.org/browse/MNG-5517 Project: Maven 2 3 Issue Type: Improvement Components: Dependencies, POM Reporter: Vijay Dharap Priority: Minor Fix For: Issues to be reviewed for 4.x node js and its corresponding package manager - npm - follows semvar notation to depict the dependencies. The supported syntax variations for version specification can be seen here. https://github.com/isaacs/node-semver#ranges I find their syntax to be much more intuitive and subsequently user friendly than what is followed in current maven dependency version tag (http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-project-dependencies.html#pom-relationships-sect-version-ranges). Hope we can make the pom xml little more user friendly by adapting similar version specification syntax. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5514) Global filter delimiters
[
https://jira.codehaus.org/browse/MNG-5514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-5514.
--
Resolution: Won't Fix
Global filter delimiters
Key: MNG-5514
URL: https://jira.codehaus.org/browse/MNG-5514
Project: Maven 2 3
Issue Type: Improvement
Components: POM
Affects Versions: 3.1.0
Environment: n/a
Reporter: Trevor Baker
In the maven-resources-plugin configuration we can specify which delimiters
are used. For example, I can configure it to only accept $\{\*} tokens. I do
this because the @*@ tokens sometimes conflicts with email addresses in the
file being filtering. I'd like to have this be applied across all plugins
that use filtering.
However, with the maven-war-plugin it doesn't use the
maven-resources-plugin's configuration for the delimiters and only uses the
standard default tokens: $\{\*} and @*@. Now the maven-war-plugin can be
enhanced to take in delimiters in it's configuration (see MWAR-225), which
should happen.
But ideally there should be a common markup in the pom for delimiters like
there is for filters. Then the various plugins can use these global
delimiters or override them in their own configuration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5514) Global filter delimiters
[
https://jira.codehaus.org/browse/MNG-5514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339883#comment-339883
]
Jason van Zyl commented on MNG-5514:
Trying to get every plugin to adhere to this is not likely to work and I think
each plugin can document what it wishes to use as delimiters. I also wouldn't
want to force plugin implementers to try and conform to this as the particular
engines they use may not support it. If you want to have a common set of
delimiters and you know the plugins that you use will accept these parameters
then you can use simple properties in the POM.
Global filter delimiters
Key: MNG-5514
URL: https://jira.codehaus.org/browse/MNG-5514
Project: Maven 2 3
Issue Type: Improvement
Components: POM
Affects Versions: 3.1.0
Environment: n/a
Reporter: Trevor Baker
In the maven-resources-plugin configuration we can specify which delimiters
are used. For example, I can configure it to only accept $\{\*} tokens. I do
this because the @*@ tokens sometimes conflicts with email addresses in the
file being filtering. I'd like to have this be applied across all plugins
that use filtering.
However, with the maven-war-plugin it doesn't use the
maven-resources-plugin's configuration for the delimiters and only uses the
standard default tokens: $\{\*} and @*@. Now the maven-war-plugin can be
enhanced to take in delimiters in it's configuration (see MWAR-225), which
should happen.
But ideally there should be a common markup in the pom for delimiters like
there is for filters. Then the various plugins can use these global
delimiters or override them in their own configuration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5512) Deploy uses passwords that failed decryption; retries even if login fails
[ https://jira.codehaus.org/browse/MNG-5512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339884#comment-339884 ] Jason van Zyl commented on MNG-5512: Please read https://cwiki.apache.org/confluence/display/MAVEN/Submitting+Issue+for+Maven's+Core Deploy uses passwords that failed decryption; retries even if login fails - Key: MNG-5512 URL: https://jira.codehaus.org/browse/MNG-5512 Project: Maven 2 3 Issue Type: Bug Reporter: SebbASF [See MDEPLOY-130 which was closed as being an issue in Maven core] If passwords have been encrypted, deploy fails to notice if the password decryption failed. Furthermore, it carries on trying to login even after a login failure. This is true even if the decryption succeeded but the password was incorrect or no encryption was used and the password is incorrect. This is bad as it can result in lockout due to the multiple failed logins - deploy needs to login several times - and may cause unnecessary work for system admins. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5511) Can't override a profile setting in a plugin's dependency
[
https://jira.codehaus.org/browse/MNG-5511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339885#comment-339885
]
Jason van Zyl commented on MNG-5511:
Please read
https://cwiki.apache.org/confluence/display/MAVEN/Submitting+Issue+for+Maven's+Core
Can't override a profile setting in a plugin's dependency
-
Key: MNG-5511
URL: https://jira.codehaus.org/browse/MNG-5511
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.0.4
Environment: OS X 10.8.3
Reporter: David Hay
We are trying to use the mojo cobertura plugin in our project. However, it
won't run on my Mac Book Pro (OS X, 10.8.3) as Apple very kindly decided to
move tools.jar and embed it into classes.jar in a completely different
directory.
The plugin depends on cobertura, which defines the following property in its
mac profile:
profile
idOSXProfile/id
activation
os
familymac/family
/os
/activation
properties
toolsjar${java.home}/../lib/tools.jar/toolsjar
/properties
/profile
and the accompanying dependency:
dependency
groupIdcom.sun/groupId
artifactIdtools/artifactId
version0/version
scopesystem/scope
systemPath${toolsjar}/systemPath
/dependency
This is wrong for Mac OS 10.8.3 running Java 6 on two counts - the lib
directory is at ${java.home}/lib and the tools.jar doesn't exist in the lib
directory as apple decided to put those clases in
${java.home}/../Classes/classes.jar.
I therefore need to be able to override the toolsjar setting, but nothing
I've tried works.
I have tried adding my own profile and setting toolsjar appropriately, but
it seems to be ignored. I also tried specifying it on the command line, and
again, it complains it can't find ../lib/tools.jar.
This is a show-stopper for us.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-410) Private Key from settings.xml ignored on SSH upload-single
Robert Novotny created WAGON-410:
Summary: Private Key from settings.xml ignored on SSH upload-single
Key: WAGON-410
URL: https://jira.codehaus.org/browse/WAGON-410
Project: Maven Wagon
Issue Type: Bug
Components: wagon-ssh
Affects Versions: 2.6
Environment: Windows 8
org.codehaus.mojo:wagon-maven-plugin:1.0-beta-4
Reporter: Robert Novotny
Priority: Critical
When uploading a WAR file via scp:// on wagon-maven plugin combined with
{{wagon-ssh:2.6}} extension seems to ignore the {{privateKey}} setting from
Maven {{settings.xml}} (the {{server}} section). The SCP server ignores the
certificate and asks for user password to the SCP account.
This does not happen with wagon-ssh:2.5
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHECKSTYLE-207) file handle leak - leading to failed builds
James Nord created MCHECKSTYLE-207: -- Summary: file handle leak - leading to failed builds Key: MCHECKSTYLE-207 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-207 Project: Maven Checkstyle Plugin Issue Type: Bug Environment: Linux Reporter: James Nord The plugin sets the classpath to load as a URLClassloader populated with all the URLs to the projects dependencies (jars) and output folders. However the URLClassloader is never closed (only available in JDK1.7+) and for a large multi-module project with a large number of dependencies this leak can seriously add up (which if gc doesn't kick in at the right moment) will lead to random failures due to java.io.IOException: error=24, Too many open files. see http://svn.apache.org/viewvc/maven/plugins/tags/maven-checkstyle-plugin-2.11/src/main/java/org/apache/maven/plugin/checkstyle/DefaultCheckstyleExecutor.java?revision=1540890view=markup Line 162 where the URLClassloader is created - but never cleaned up. The fix is relatively trivial if it is only to be fixed for 1.7+ JVMs (and use reflection if need to be compatable with 1.7). Otherwise a custom classloader will be needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5561) Plugin relocation looses configuration
[
https://jira.codehaus.org/browse/MNG-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=338679#comment-338679
]
Julien CARSIQUE edited comment on MNG-5561 at 1/23/14 10:52 AM:
Reproduction test case:
{code}git clone http://github.com/nuxeo/ant-assembly-maven-plugin
cd ant-assembly-maven-plugin
mvn clean integration-test -DskipTests=true -DdebugITs=true
-Dinvoker.test=test1,test-MNG-5561{code}
Both tests are identical except that test-MNG-5561 uses
nuxeo-distribution-tools relocated to ant-assembly-maven-plugin.
test-MNG-5561 fails with a {{FileNotFoundException:
.../target/it/test-MNG-5561/build.xml (Aucun fichier ou dossier de ce type)}}
since the {{build.xml}} file is expected to be at
{{.../target/it/test-MNG-5561/src/build.xml}} as stated by the {{buildFile}}
configuration parameter.
We can see that with the relocation, the default value is used for the
parameter instead of the one configured in the POM.
was (Author: jcarsique):
Reproduction test case:
{code}mkdir -p
~/.m2/repository/org/nuxeo/build/nuxeo-distribution-tools/2.0-SNAPSHOT/
cat
~/.m2/repository/org/nuxeo/build/nuxeo-distribution-tools/2.0-SNAPSHOT/nuxeo-distribution-tools-2.0-SNAPSHOT.pom
EOF
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdorg.nuxeo.build/groupId
artifactIdnuxeo-distribution-tools/artifactId
version2.0-SNAPSHOT/version
packagingmaven-plugin/packaging
nameNuxeo Distribution Build/name
descriptionAssemble Nuxeo distributions/description
distributionManagement
relocation
artifactIdant-assembly-maven-plugin/artifactId
/relocation
/distributionManagement
/project
EOF
git clone http://github.com/nuxeo/ant-assembly-maven-plugin
cd ant-assembly-maven-plugin
mvn clean integration-test -DskipTests=true -DdebugITs=true
-Dinvoker.test=test1,test-MNG-5561{code}
Both tests are identical except that test-MNG-5561 uses
nuxeo-distribution-tools relocated to ant-assembly-maven-plugin.
test-MNG-5561 fails with a {{FileNotFoundException:
.../target/it/test-MNG-5561/build.xml (Aucun fichier ou dossier de ce type)}}
since the {{build.xml}} file is expected to be at
{{.../target/it/test-MNG-5561/src/build.xml}} as stated by the {{buildFile}}
configuration parameter.
We can see that with the relocation, the default value is used for the
parameter instead of the one configured in the POM.
Plugin relocation looses configuration
--
Key: MNG-5561
URL: https://jira.codehaus.org/browse/MNG-5561
Project: Maven 2 3
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 3.1.1
Reporter: Julien CARSIQUE
Hi,
Applying a relocation on a plugin seems to loose its configuration.
In the following sample, I relocated nuxeo-distribution-tools to
ant-assembly-maven-plugin and the missing configured parameter is
buildFile. The relocation itself went well but the execution fails because
of a missing parameter.
{code:title=~/.m2/repository/org/nuxeo/build/nuxeo-distribution-tools/2.0-SNAPSHOT/nuxeo-distribution-tools-2.0-SNAPSHOT.pom}
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdorg.nuxeo.build/groupId
artifactIdnuxeo-distribution-tools/artifactId
version2.0-SNAPSHOT/version
packagingmaven-plugin/packaging
nameNuxeo Distribution Build/name
descriptionAssemble Nuxeo distributions/description
distributionManagement
relocation
artifactIdant-assembly-maven-plugin/artifactId
/relocation
/distributionManagement
/project{code}
{code:title=executed POM extract}
build
plugins
plugin
groupIdorg.nuxeo.build/groupId
!-- With relocation --
artifactIdnuxeo-distribution-tools/artifactId
!-- Without relocation --
!-- artifactIdant-assembly-maven-plugin/artifactId --
executions
execution
idassemble/id
phasepackage/phase
configuration
!-- The missing parameter in case of relocation --
buildFilesrc/main/assemble/assembly.xml/buildFile
/configuration
goals
goalbuild/goal
/goals
/execution
/executions
/plugin
/plugins
/build
{code}
Here is the diff between an mvn package -X with nuxeo-distribution-tools
(ie: with relocation; line starting with ) and another one
[jira] (MNG-5561) Plugin relocation looses configuration
[
https://jira.codehaus.org/browse/MNG-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339889#comment-339889
]
Julien CARSIQUE commented on MNG-5561:
--
Done. I've updated the above comment since I simplified the reproduction case.
I'm not sure to understand what you want.
The reproduction case is the integration test test-MNG-5561 included in
http://github.com/nuxeo/ant-assembly-maven-plugin. Did you encounter any issue
while running it?
You wrote that The preferred way of providing an example project is Github
repository . Do you want me to create an almost empty project raising the
same issue?
Plugin relocation looses configuration
--
Key: MNG-5561
URL: https://jira.codehaus.org/browse/MNG-5561
Project: Maven 2 3
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 3.1.1
Reporter: Julien CARSIQUE
Hi,
Applying a relocation on a plugin seems to loose its configuration.
In the following sample, I relocated nuxeo-distribution-tools to
ant-assembly-maven-plugin and the missing configured parameter is
buildFile. The relocation itself went well but the execution fails because
of a missing parameter.
{code:title=~/.m2/repository/org/nuxeo/build/nuxeo-distribution-tools/2.0-SNAPSHOT/nuxeo-distribution-tools-2.0-SNAPSHOT.pom}
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdorg.nuxeo.build/groupId
artifactIdnuxeo-distribution-tools/artifactId
version2.0-SNAPSHOT/version
packagingmaven-plugin/packaging
nameNuxeo Distribution Build/name
descriptionAssemble Nuxeo distributions/description
distributionManagement
relocation
artifactIdant-assembly-maven-plugin/artifactId
/relocation
/distributionManagement
/project{code}
{code:title=executed POM extract}
build
plugins
plugin
groupIdorg.nuxeo.build/groupId
!-- With relocation --
artifactIdnuxeo-distribution-tools/artifactId
!-- Without relocation --
!-- artifactIdant-assembly-maven-plugin/artifactId --
executions
execution
idassemble/id
phasepackage/phase
configuration
!-- The missing parameter in case of relocation --
buildFilesrc/main/assemble/assembly.xml/buildFile
/configuration
goals
goalbuild/goal
/goals
/execution
/executions
/plugin
/plugins
/build
{code}
Here is the diff between an mvn package -X with nuxeo-distribution-tools
(ie: with relocation; line starting with ) and another one with
ant-assembly-maven-plugin (ie: without relocation; line starting with ):
{noformat} [DEBUG] Dependency collection stats:
{ConflictMarker.analyzeTime=1, ConflictMarker.markTime=0,
ConflictMarker.nodeCount=72, ConflictIdSorter.graphTime=0,
ConflictIdSorter.topsortTime=0, ConflictIdSorter.conflictIdCount=34,
ConflictIdSorter.conflictIdCycleCount=0, ConflictResolver.totalTime=1,
ConflictResolver.conflictItemCount=71,
DefaultDependencyCollector.collectTime=10,
DefaultDependencyCollector.transformTime=2}
[DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=1,
ConflictMarker.markTime=0, ConflictMarker.nodeCount=72,
ConflictIdSorter.graphTime=0, ConflictIdSorter.topsortTime=0,
ConflictIdSorter.conflictIdCount=34,
ConflictIdSorter.conflictIdCycleCount=0, ConflictResolver.totalTime=2,
ConflictResolver.conflictItemCount=71,
DefaultDependencyCollector.collectTime=65,
DefaultDependencyCollector.transformTime=3}
---
[DEBUG] Created new class realm
pluginorg.nuxeo.build:nuxeo-distribution-tools:2.0-SNAPSHOT
[DEBUG] Importing foreign packages into class realm
pluginorg.nuxeo.build:nuxeo-distribution-tools:2.0-SNAPSHOT
[DEBUG] Created new class realm
pluginorg.nuxeo.build:ant-assembly-maven-plugin:2.0-SNAPSHOT
[DEBUG] Importing foreign packages into class realm
pluginorg.nuxeo.build:ant-assembly-maven-plugin:2.0-SNAPSHOT
---
[DEBUG] Populating class realm
pluginorg.nuxeo.build:nuxeo-distribution-tools:2.0-SNAPSHOT
[DEBUG] Populating class realm
pluginorg.nuxeo.build:ant-assembly-maven-plugin:2.0-SNAPSHOT
---
[DEBUG] Configuring mojo
org.nuxeo.build:ant-assembly-maven-plugin:2.0-SNAPSHOT:build from plugin
realm
ClassRealm[pluginorg.nuxeo.build:nuxeo-distribution-tools:2.0-SNAPSHOT,
parent: sun.misc.Launcher$AppClassLoader@591ce4fe]
[DEBUG] Configuring mojo
org.nuxeo.build:ant-assembly-maven-plugin:2.0-SNAPSHOT:build from plugin
realm
[jira] (MNG-5506) Master override of checksumPolicy
[ https://jira.codehaus.org/browse/MNG-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339891#comment-339891 ] Jason van Zyl commented on MNG-5506: So there are the command line parameters: -C,--strict-checksums Fail the build if checksums don't match -c,--lax-checksums Warn if checksums don't match This is how you would catch it globally And you can control the checksum policy in your POM by enumerating your repositories and controlling the policy with a property. But you cannot catch control them transitively without using the CLI parameter, or using a mirror pointing to a repository manager and controlling the policy there. So I believe you have what you need to control the policy globally. Master override of checksumPolicy - Key: MNG-5506 URL: https://jira.codehaus.org/browse/MNG-5506 Project: Maven 2 3 Issue Type: Sub-task Reporter: Marcin Wisnicki There should be a property usable both from command line and pom to override checksumPolicy for all repositories. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5506) Master override of checksumPolicy
[ https://jira.codehaus.org/browse/MNG-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5506. -- Resolution: Not A Bug Master override of checksumPolicy - Key: MNG-5506 URL: https://jira.codehaus.org/browse/MNG-5506 Project: Maven 2 3 Issue Type: Sub-task Reporter: Marcin Wisnicki There should be a property usable both from command line and pom to override checksumPolicy for all repositories. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5505) Support system scope for additional dependencies of plugins
[ https://jira.codehaus.org/browse/MNG-5505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5505. -- Resolution: Won't Fix Support system scope for additional dependencies of plugins --- Key: MNG-5505 URL: https://jira.codehaus.org/browse/MNG-5505 Project: Maven 2 3 Issue Type: Bug Reporter: Marcin Wisnicki Sometimes I want to quickly test something with a jars outside maven and it would be nice if I could simply add it as system scope of e.g. exec plugin. Currently such dependencies are completely ignored. Yes I know you would rather have me wasting time with install-file. If you feel a need to punish me and other users with similar use cases then print a huge warning about non-portable build etc. but please don't be such a classpath nazi and let us live our lives the way we want. Thanks! Alternatively, is it possible to make a plugin that could manipulate another plugin's classpath (not silently installing jars into local repo) ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5505) Support system scope for additional dependencies of plugins
[ https://jira.codehaus.org/browse/MNG-5505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339893#comment-339893 ] Jason van Zyl commented on MNG-5505: For testing plugins you should make a separate integration test and you can either set the dependencies section of the plugin in the test. We have many examples of testing plugins that work in a portable way without runtime manipulation of the classpath or use the system scope dependencies (which are going away). Support system scope for additional dependencies of plugins --- Key: MNG-5505 URL: https://jira.codehaus.org/browse/MNG-5505 Project: Maven 2 3 Issue Type: Bug Reporter: Marcin Wisnicki Sometimes I want to quickly test something with a jars outside maven and it would be nice if I could simply add it as system scope of e.g. exec plugin. Currently such dependencies are completely ignored. Yes I know you would rather have me wasting time with install-file. If you feel a need to punish me and other users with similar use cases then print a huge warning about non-portable build etc. but please don't be such a classpath nazi and let us live our lives the way we want. Thanks! Alternatively, is it possible to make a plugin that could manipulate another plugin's classpath (not silently installing jars into local repo) ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5501) Prerequisites don't work against Maven-3.1.0
[
https://jira.codehaus.org/browse/MNG-5501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-5501.
--
Resolution: Not A Bug
Prerequisites don't work against Maven-3.1.0
Key: MNG-5501
URL: https://jira.codehaus.org/browse/MNG-5501
Project: Maven 2 3
Issue Type: Bug
Components: POM
Affects Versions: 3.0.4, 3.0.5, 3.1.0
Reporter: Michael Semb Wever
adding
{code}prerequisitesmaven3.1.0/maven/prerequisites{code}
does not stop the project from being built with mvn-3.0.4 or mvn-3.0.5
Is Prerequisites suppose to work or not?
Because there is no sign of it being deprecated throughout the documentation.
(I don't want to use the enforcer plugin).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5501) Prerequisites don't work against Maven-3.1.0
[
https://jira.codehaus.org/browse/MNG-5501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339894#comment-339894
]
Jason van Zyl commented on MNG-5501:
The prerequisite field is to stop plugins that use this field from running in
an inappropriate version of Maven. Probably not clearly documented. But, yes,
this is what the enforcer plugin is for.
Prerequisites don't work against Maven-3.1.0
Key: MNG-5501
URL: https://jira.codehaus.org/browse/MNG-5501
Project: Maven 2 3
Issue Type: Bug
Components: POM
Affects Versions: 3.0.4, 3.0.5, 3.1.0
Reporter: Michael Semb Wever
adding
{code}prerequisitesmaven3.1.0/maven/prerequisites{code}
does not stop the project from being built with mvn-3.0.4 or mvn-3.0.5
Is Prerequisites suppose to work or not?
Because there is no sign of it being deprecated throughout the documentation.
(I don't want to use the enforcer plugin).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5493) Concurrency exception in Maven core while using parallel build
[ https://jira.codehaus.org/browse/MNG-5493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339896#comment-339896 ] Jason van Zyl commented on MNG-5493: Please read https://cwiki.apache.org/confluence/display/MAVEN/Submitting+Issue+for+Maven's+Core The POMs are all read before the build executes concurrently. So it's hard to diagnose without a sample. If the assembly plugin is modifying these properties at runtime that's probabably not good. Concurrency exception in Maven core while using parallel build -- Key: MNG-5493 URL: https://jira.codehaus.org/browse/MNG-5493 Project: Maven 2 3 Issue Type: Bug Components: Deployment, Errors, General, Plugins and Lifecycle Affects Versions: 3.0.3, 3.0.5 Reporter: Pengfei Zhang My project uses parallel build for my deployment job in Hudson. From time to time, the build failed because of the following ConcurrencyModificationException. This apparently is not a plugin-in bug. Instead, it is a deeper issue in the core. I checked the source code, I think the Properties should be replaced by a concurrentHashMap. Accordingt to the java doc of Properties, it cannot support concurrency. org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.4:single (make-assembly) on project ssm-viewer-spread: Execution make-assembly of goal org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167) at org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution make-assembly of goal org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 13 more Caused by: java.util.ConcurrentModificationException at java.util.Hashtable$Enumerator.next(Hashtable.java:1200) at java.util.Hashtable.putAll(Hashtable.java:614) at org.apache.maven.project.DefaultProjectBuildingRequest.setSystemProperties(DefaultProjectBuildingRequest.java:166) at org.apache.maven.project.DefaultMavenProjectBuilder.toRequest(DefaultMavenProjectBuilder.java:79) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:229) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:251) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:258) at org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:162) at org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:124) at org.apache.maven.plugin.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:76) at org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:183) at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:436) at org.apache.maven -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5491) Resolve artifact failed because of using repo url instead of repo ID
[
https://jira.codehaus.org/browse/MNG-5491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339897#comment-339897
]
Jason van Zyl commented on MNG-5491:
Please read
https://cwiki.apache.org/confluence/display/MAVEN/Submitting+Issue+for+Maven's+Core
Resolve artifact failed because of using repo url instead of repo ID
-
Key: MNG-5491
URL: https://jira.codehaus.org/browse/MNG-5491
Project: Maven 2 3
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.0.5
Environment: On several systems as Linux Redhat and Windows Vista
Reporter: David Fradin
Attachments: settings.xml
We have develop a MOJO that downloads a list of artefacts and makes that
operations on them. It works in Maven 3.0.3 but failed in Maven 3.0.5 on
resolveArtifact method. It seems to be a regression on Maven 3.0.5 (we don't
test on Maven 3.0.4).
In attached file, find our settings.xml (we have remove internal information).
You can see we have a plugin repository ID and a repository ID that use the
same URL repository.
When we use our plugin, Maven downloads its dependencies and for example
download javax.xml.stream:stax-api:jar:1.0-2 (it makes the same problem on
all common artifacts).
On local repository, we can see in
cat repository/javax/xml/stream/stax-api/1.0-2/_maven.repositories :
#NOTE: This is an internal implementation file, its format can be changed
without prior notice.
#Wed Jul 03 13:30:47 CEST 2013
stax-api-1.0-2.jarplugin-repository=
stax-api-1.0-2.pomplugin-repository=
Then Maven execute our plugin that has to download a list of artifacts.
But it failed to download javax.xml.stream:stax-api:jar:1.0-2
Reason is that javax.xml.stream:stax-api:jar:1.0-2 is present on local
repository, so it found by Maven but when it tests if it is up-to-date it
failed because this file comes from another repository.
Explanation :
Class : DefaultArtifactResolver
Method : private ListArtifactResult resolve( RepositorySystemSession
session,
Collection? extends
ArtifactRequest requests )
Call
Class : DefaultUpdateCheckManager
Method :public void checkArtifact( RepositorySystemSession session,
UpdateCheckArtifact, ArtifactTransferException check )
{
[...]
if ( isAlreadyUpdated( session.getData(), updateKey ) )
updateKey contains repository.getUrl() and not repository.getID()
So isAlreadyUpdated answers yes because artefact as already been downloaded
from this URL.
But when Maven reads _maven.repositories, it sees that repository ID
public-repository is not here so the plugin is considered as unavailable.
So we have an artifact that is present in local repository but considered as
unavailable by resolve and present by isAlreadyUpdated.
So artifact is never updated so the repository ID is not added to
_maven.repositories
Is it clear ?
I hope...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5490) Add support for lifecycle activation for profiles
[
https://jira.codehaus.org/browse/MNG-5490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339898#comment-339898
]
Jason van Zyl commented on MNG-5490:
I honestly can't tell what you're trying to accomplish.
Add support for lifecycle activation for profiles
---
Key: MNG-5490
URL: https://jira.codehaus.org/browse/MNG-5490
Project: Maven 2 3
Issue Type: Improvement
Components: Profiles
Affects Versions: 2.2.1
Environment: Windows 7
Reporter: Gregory Baumgardner
Priority: Minor
I have the following scenario: Initialization step is done in the default
lifecycle initialize phase which sets properties that are used in later
build phases. Unfortunately, the same properties need set in the clean
lifecycle in order to use them in the clean phase. There is no way to easily
run the same execution of plugins without duplication. However, it turns out
very easy to manipulate the phase attribute in the following way:
profile
iddefault-phase/id
activation
property
name!clean-all/name
/property
/activation
properties
init-phaseinitialize/init-phase
/properties
/profile
profile
idclean-phase/id
activation
property
nameclean-all/name
/property
/activation
properties
init-phasepre-clean/init-phase
/properties
/profile
profile
idplugin-config/id
activation
property
namejava.version/name !-- Always on --
/property
/activation
build
plugins
plugin
... !-- Whatever plugin --
executions
execution
idinitialize properties/id
goalsgoal!--The goal --/goal/goals
phase${init-phase}/phase
configuration
!-- The plugin config to use --
/configuration
/execution
/executions
/plugin
...
/plugins
/build
/profile
This will run the initialize step under initialize phase for default
lifecycle and under pre-clean phase for clean lifecycle provided that the
config information falls after the property set in a profile. However, the
one issue I have with this is that it requires you to run Maven with
-Dclean-all property on the command line. It would be even better if there
was an activation for lifecycle that could be set to default, clean,
site, etc. Then, the activation can occur when that specific lifecycle is
invoked during the build. As far as I can tell, there is no other way to
determine this information.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5489) Startup doesn't fail gracefully if shell CWD is in non-existent dir.
[
https://jira.codehaus.org/browse/MNG-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-5489.
--
Resolution: Cannot Reproduce
Startup doesn't fail gracefully if shell CWD is in non-existent dir.
Key: MNG-5489
URL: https://jira.codehaus.org/browse/MNG-5489
Project: Maven 2 3
Issue Type: Bug
Components: Bootstrap Build, Command Line
Affects Versions: 3.0.4
Reporter: Ondrej Zizka
A sequence of commands which ends up executing maven from a formerly existing
dir produces the error below.
{code}
cd target/classes
mvn clean ## From other console
mvn build
{code}
{code}
ondra@lenovo:~/work/AS/Migration/git-repo/target/as-dist$ mvn deploy
-DskipTests
shell-init: error retrieving current directory: getcwd: cannot access parent
directories: No such file or directory
pwd: error retrieving current directory: getcwd: cannot access parent
directories: No such file or directory
pwd: error retrieving current directory: getcwd: cannot access parent
directories: No such file or directory
chdir: error retrieving current directory: getcwd: cannot access parent
directories: No such file or directory
chdir: error retrieving current directory: getcwd: cannot access parent
directories: No such file or directory
malloc: ../../bash/builtins/../../bash/builtins/cd.def:501: assertion botched
free: start and end chunk sizes differ
Aborting...Aborted (core dumped)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5505) Support system scope for additional dependencies of plugins
[ https://jira.codehaus.org/browse/MNG-5505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339899#comment-339899 ] Marcin Wisnicki commented on MNG-5505: -- That is a lot of work compared to simply adding few lines of xml for system dependency and I'm already wasting way too much time with maven compared to similar systems for other languages :( Support system scope for additional dependencies of plugins --- Key: MNG-5505 URL: https://jira.codehaus.org/browse/MNG-5505 Project: Maven 2 3 Issue Type: Bug Reporter: Marcin Wisnicki Sometimes I want to quickly test something with a jars outside maven and it would be nice if I could simply add it as system scope of e.g. exec plugin. Currently such dependencies are completely ignored. Yes I know you would rather have me wasting time with install-file. If you feel a need to punish me and other users with similar use cases then print a huge warning about non-portable build etc. but please don't be such a classpath nazi and let us live our lives the way we want. Thanks! Alternatively, is it possible to make a plugin that could manipulate another plugin's classpath (not silently installing jars into local repo) ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5488) Add support for comment metadata for POM Elements
[
https://jira.codehaus.org/browse/MNG-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339900#comment-339900
]
Jason van Zyl commented on MNG-5488:
This is not a deficiency with the XML the POM uses inherently. It is the tools
that destroy the comments or reformat them. Many people have started using
tools like DecentXML which doesn't interfere with comments. I do not believe
the POM elements need comment fields. We just need to start using tools that
don't destroy comments.
Add support for comment metadata for POM Elements
-
Key: MNG-5488
URL: https://jira.codehaus.org/browse/MNG-5488
Project: Maven 2 3
Issue Type: Improvement
Affects Versions: 3.0.5
Reporter: Lennart Jorelid
h1. Lack of model metadata is a problem!
The Maven model APIs today do not handle XML comments (at all, and in a
uniform manner).
Comments and explanations to human beings are (or should be) an integral
and important part of any larger POMs - just like the ability to comment
source code is important to usability and improved understanding.
Comments/metadata can ensure that people understand *why* a particular
plugin/configuration/property was provided, what role it has in the
reactor and how it should be changed/managed in child projects.
The fact that POM element metadata such as XML comments is not a first-class
citizen of the Maven model must be considered a deficiency, since larger POMs
[typically root poms] can be daunting or confusing to read and understand.
So if POMs are processed (reordered, laundered, synthesized, whatever) using
Maven's APIs, comments are either removed or impossible to add.
h2. Alteration suggestions
I suggest some alterations to the Maven model:
# Add state holding an optional comment to all elements in the Maven model
# If non-null, the comments should be inserted in a uniform and
pretty-printed way, i.e:
## Standard intendation
## Standard handling of XML comment delimiters
## Pom tools should not [by default]Â reformat/mess up comments carefully
crafted by developers - be clear about this in documentation to tool devs
h2. Examples
We are developers, and should really not need examples on why commenting
source code or configuration is important. However, the two smallish samples
below should be sufficient to convey the gist of my idea here.
{code:xml}
!--
Provides Plantuml integration into site deployments.
Why: Convert Plantuml (*.puml) documents to png images, for use in site
documentation.
Used: Site lifecycle, mvn site.
--
plugin
groupIdcom.github.jeluard/groupId
artifactIdplantuml-maven-plugin/artifactId
version7954/version
{code}
... or, perhaps a better example ...
{code:xml}
properties
...
!--
Override this property only in the root reactor POM of each sub-reactor
project, to ensure that the site staging, site deployment, issue
management and CI integration works properly.
--
reactor.namenazgul_core/reactor.name
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5488) Add support for comment metadata for POM Elements
[
https://jira.codehaus.org/browse/MNG-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-5488.
--
Resolution: Not A Bug
Add support for comment metadata for POM Elements
-
Key: MNG-5488
URL: https://jira.codehaus.org/browse/MNG-5488
Project: Maven 2 3
Issue Type: Improvement
Affects Versions: 3.0.5
Reporter: Lennart Jorelid
h1. Lack of model metadata is a problem!
The Maven model APIs today do not handle XML comments (at all, and in a
uniform manner).
Comments and explanations to human beings are (or should be) an integral
and important part of any larger POMs - just like the ability to comment
source code is important to usability and improved understanding.
Comments/metadata can ensure that people understand *why* a particular
plugin/configuration/property was provided, what role it has in the
reactor and how it should be changed/managed in child projects.
The fact that POM element metadata such as XML comments is not a first-class
citizen of the Maven model must be considered a deficiency, since larger POMs
[typically root poms] can be daunting or confusing to read and understand.
So if POMs are processed (reordered, laundered, synthesized, whatever) using
Maven's APIs, comments are either removed or impossible to add.
h2. Alteration suggestions
I suggest some alterations to the Maven model:
# Add state holding an optional comment to all elements in the Maven model
# If non-null, the comments should be inserted in a uniform and
pretty-printed way, i.e:
## Standard intendation
## Standard handling of XML comment delimiters
## Pom tools should not [by default]Â reformat/mess up comments carefully
crafted by developers - be clear about this in documentation to tool devs
h2. Examples
We are developers, and should really not need examples on why commenting
source code or configuration is important. However, the two smallish samples
below should be sufficient to convey the gist of my idea here.
{code:xml}
!--
Provides Plantuml integration into site deployments.
Why: Convert Plantuml (*.puml) documents to png images, for use in site
documentation.
Used: Site lifecycle, mvn site.
--
plugin
groupIdcom.github.jeluard/groupId
artifactIdplantuml-maven-plugin/artifactId
version7954/version
{code}
... or, perhaps a better example ...
{code:xml}
properties
...
!--
Override this property only in the root reactor POM of each sub-reactor
project, to ensure that the site staging, site deployment, issue
management and CI integration works properly.
--
reactor.namenazgul_core/reactor.name
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5490) Add support for lifecycle activation for profiles
[
https://jira.codehaus.org/browse/MNG-5490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339901#comment-339901
]
Gregory Baumgardner commented on MNG-5490:
--
Ok, let me break it down simply. You can do write two separate profiles with
two separate executions to do a common task that is to be done for both clean
and default lifecycles. In my case, I am running an Ant script to run some
pre-script and set properties. One execution of the antrun plugin is bound to
initialize phase, and the other is in pre-clean. This works fine, but it would
be so much nicer to only define one single profile with one single execution
that is bound to a variable phase controlled by a property, like ${init-phase}
shown above. I have this working, but you must set the init-phase property
differently, depending on whether the lifecycle is clean or the default. This
is, as far as I can tell, impossible in the POM. So, it would be cool to have
an activation option to specify the lifecycle, in order to define two extra
profiles whose purpose is to set the property.
Add support for lifecycle activation for profiles
---
Key: MNG-5490
URL: https://jira.codehaus.org/browse/MNG-5490
Project: Maven 2 3
Issue Type: Improvement
Components: Profiles
Affects Versions: 2.2.1
Environment: Windows 7
Reporter: Gregory Baumgardner
Priority: Minor
I have the following scenario: Initialization step is done in the default
lifecycle initialize phase which sets properties that are used in later
build phases. Unfortunately, the same properties need set in the clean
lifecycle in order to use them in the clean phase. There is no way to easily
run the same execution of plugins without duplication. However, it turns out
very easy to manipulate the phase attribute in the following way:
profile
iddefault-phase/id
activation
property
name!clean-all/name
/property
/activation
properties
init-phaseinitialize/init-phase
/properties
/profile
profile
idclean-phase/id
activation
property
nameclean-all/name
/property
/activation
properties
init-phasepre-clean/init-phase
/properties
/profile
profile
idplugin-config/id
activation
property
namejava.version/name !-- Always on --
/property
/activation
build
plugins
plugin
... !-- Whatever plugin --
executions
execution
idinitialize properties/id
goalsgoal!--The goal --/goal/goals
phase${init-phase}/phase
configuration
!-- The plugin config to use --
/configuration
/execution
/executions
/plugin
...
/plugins
/build
/profile
This will run the initialize step under initialize phase for default
lifecycle and under pre-clean phase for clean lifecycle provided that the
config information falls after the property set in a profile. However, the
one issue I have with this is that it requires you to run Maven with
-Dclean-all property on the command line. It would be even better if there
was an activation for lifecycle that could be set to default, clean,
site, etc. Then, the activation can occur when that specific lifecycle is
invoked during the build. As far as I can tell, there is no other way to
determine this information.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5506) Master override of checksumPolicy
[ https://jira.codehaus.org/browse/MNG-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339902#comment-339902 ] Marcin Wisnicki commented on MNG-5506: -- Why strict-checksums isn't default policy ? Master override of checksumPolicy - Key: MNG-5506 URL: https://jira.codehaus.org/browse/MNG-5506 Project: Maven 2 3 Issue Type: Sub-task Reporter: Marcin Wisnicki There should be a property usable both from command line and pom to override checksumPolicy for all repositories. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5485) ClassRealmAdapter.getParent() handles null parents incorrectly
[
https://jira.codehaus.org/browse/MNG-5485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339903#comment-339903
]
Jason van Zyl commented on MNG-5485:
This code is now all deprecated in ClassWorlds and will be removed in the next
major release.
ClassRealmAdapter.getParent() handles null parents incorrectly
--
Key: MNG-5485
URL: https://jira.codehaus.org/browse/MNG-5485
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.0.5
Environment: Java 1.6.0_30, Windows XP Professional 2002 SP3
Reporter: Stefan Fromm
Here is the code from plexus classworlds 2.4.x.
{noformat}
public ClassRealm getParent()
{
return ClassRealmAdapter.getInstance( realm.getParentRealm() );
}
public ClassRealm getParentRealm()
{
return ClassRealmAdapter.getInstance( realm.getParentRealm() );
}
public static ClassRealmAdapter getInstance(
org.codehaus.plexus.classworlds.realm.ClassRealm newRealm )
{
ClassRealmAdapter adapter = new ClassRealmAdapter( newRealm );
return adapter;
}
{noformat}
If the parent of the backend realm is {{null}}, then there is returned a new
{{ClassRealmAdapter}} instead of {{null}}. Calling methods on the returned
{{ClassRealmAdapter}} produces NPEs.
I think, that {{getParent()}} and {{getParentRealm()}} could be patched like
this:
{noformat}
public ClassRealm getParentRealm()
{
return realm.getParentRealm() != null
? ClassRealmAdapter.getInstance( realm.getParentRealm())
: null;
}
public ClassRealm getParent()
{
return getParentRealm();
}
{noformat}
Or should {{null}} be handled in {{ClassRealmAdapter.getInstance()}}?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5485) ClassRealmAdapter.getParent() handles null parents incorrectly
[
https://jira.codehaus.org/browse/MNG-5485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-5485.
--
Resolution: Won't Fix
ClassRealmAdapter.getParent() handles null parents incorrectly
--
Key: MNG-5485
URL: https://jira.codehaus.org/browse/MNG-5485
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.0.5
Environment: Java 1.6.0_30, Windows XP Professional 2002 SP3
Reporter: Stefan Fromm
Here is the code from plexus classworlds 2.4.x.
{noformat}
public ClassRealm getParent()
{
return ClassRealmAdapter.getInstance( realm.getParentRealm() );
}
public ClassRealm getParentRealm()
{
return ClassRealmAdapter.getInstance( realm.getParentRealm() );
}
public static ClassRealmAdapter getInstance(
org.codehaus.plexus.classworlds.realm.ClassRealm newRealm )
{
ClassRealmAdapter adapter = new ClassRealmAdapter( newRealm );
return adapter;
}
{noformat}
If the parent of the backend realm is {{null}}, then there is returned a new
{{ClassRealmAdapter}} instead of {{null}}. Calling methods on the returned
{{ClassRealmAdapter}} produces NPEs.
I think, that {{getParent()}} and {{getParentRealm()}} could be patched like
this:
{noformat}
public ClassRealm getParentRealm()
{
return realm.getParentRealm() != null
? ClassRealmAdapter.getInstance( realm.getParentRealm())
: null;
}
public ClassRealm getParent()
{
return getParentRealm();
}
{noformat}
Or should {{null}} be handled in {{ClassRealmAdapter.getInstance()}}?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5483) Non-resolvable import POM when building offline
[
https://jira.codehaus.org/browse/MNG-5483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339904#comment-339904
]
Jason van Zyl commented on MNG-5483:
Please read
https://cwiki.apache.org/confluence/display/MAVEN/Submitting+Issue+for+Maven%27s+Core
Non-resolvable import POM when building offline
---
Key: MNG-5483
URL: https://jira.codehaus.org/browse/MNG-5483
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.1.0-alpha-1
Reporter: Arnaud Heritier
Priority: Critical
In our projects we are massively using import of dependencies management to
avoid to redefine the versions of all our components.
Example : https://github.com/exoplatform/platform-public-distributions/
This project is using right now some dependencies coming from a JBoss staging
repository. To build it I activate a profile declared in my settings.
With Maven 3.0.5 due to MNG-5185 I need to declare the profile for every
build to don't let maven reject dependencies in staging which are already in
my local repository (that's a shame but this is another issue already
discussed in the dev list).
But with Maven 3.0.5 if I put Maven in offline mode, there is no problem to
build the project (it will use my local copy of artifacts in staging)
With Maven 3.1.0-alpha-1 I have the same behavior due to MNG-5185 BUT I
cannot use anymore the offline mode too. Local artifacts coming from staging
aren't used by Maven :( :
{code}
arnaud@imac-arnaud:~/Code/eXo/platform-public-distributions (git:master $%)$
mvn clean install -o
[INFO] Scanning for projects...
[ERROR] The build could not read 1 project - [Help 1]
[ERROR]
[ERROR] The project
org.exoplatform.platform.distributions:plf-public-distributions:4.0.x-SNAPSHOT
(/Users/arnaud/Code/eXo/platform-public-distributions/pom.xml) has 143 errors
[ERROR] Non-resolvable import POM: Cannot access exo-mirror
(https://repository.exoplatform.org/public) in offline mode and the artifact
org.exoplatform.jcr:jcr-parent:pom:1.15.4-GA has not been downloaded from it
before. @ org.exoplatform.commons:commons:4.0.x-SNAPSHOT,
/Users/arnaud/.m2/repository/org/exoplatform/commons/commons/4.0.x-SNAPSHOT/commons-4.0.x-SNAPSHOT.pom,
line 263, column 19 - [Help 2]
[ERROR] Non-resolvable import POM: Cannot access exo-mirror
(https://repository.exoplatform.org/public) in offline mode and the artifact
org.exoplatform.ws:ws-parent:pom:2.3.4-GA has not been downloaded from it
before. @ org.exoplatform.commons:commons:4.0.x-SNAPSHOT,
/Users/arnaud/.m2/repository/org/exoplatform/commons/commons/4.0.x-SNAPSHOT/commons-4.0.x-SNAPSHOT.pom,
line 271, column 19 - [Help 2]
[ERROR] Non-resolvable import POM: Cannot access exo-mirror
(https://repository.exoplatform.org/public) in offline mode and the artifact
org.exoplatform.core:core-parent:pom:2.5.4-GA has not been downloaded from it
before. @ org.exoplatform.commons:commons:4.0.x-SNAPSHOT,
/Users/arnaud/.m2/repository/org/exoplatform/commons/commons/4.0.x-SNAPSHOT/commons-4.0.x-SNAPSHOT.pom,
line 279, column 19 - [Help 2]
[ERROR] Non-resolvable import POM: Cannot access exo-mirror
(https://repository.exoplatform.org/public) in offline mode and the artifact
org.exoplatform.kernel:kernel-parent:pom:2.4.4-GA has not been downloaded
from it before. @ org.exoplatform.commons:commons:4.0.x-SNAPSHOT,
/Users/arnaud/.m2/repository/org/exoplatform/commons/commons/4.0.x-SNAPSHOT/commons-4.0.x-SNAPSHOT.pom,
line 287, column 19 - [Help 2]
[ERROR] Non-resolvable import POM: Cannot access exo-mirror
(https://repository.exoplatform.org/public) in offline mode and the artifact
org.exoplatform.jcr:jcr-parent:pom:1.15.4-GA has not been downloaded from it
before. @ org.exoplatform.social:social:4.0.x-SNAPSHOT,
/Users/arnaud/.m2/repository/org/exoplatform/social/social/4.0.x-SNAPSHOT/social-4.0.x-SNAPSHOT.pom,
line 345, column 19 - [Help 2]
[ERROR] Non-resolvable import POM: Cannot access exo-mirror
(https://repository.exoplatform.org/public) in offline mode and the artifact
org.exoplatform.ws:ws-parent:pom:2.3.4-GA has not been downloaded from it
before. @ org.exoplatform.social:social:4.0.x-SNAPSHOT,
/Users/arnaud/.m2/repository/org/exoplatform/social/social/4.0.x-SNAPSHOT/social-4.0.x-SNAPSHOT.pom,
line 353, column 19 - [Help 2]
[ERROR] Non-resolvable import POM: Cannot access exo-mirror
(https://repository.exoplatform.org/public) in offline mode and the artifact
org.exoplatform.core:core-parent:pom:2.5.4-GA has not been downloaded from it
before. @ org.exoplatform.social:social:4.0.x-SNAPSHOT,
/Users/arnaud/.m2/repository/org/exoplatform/social/social/4.0.x-SNAPSHOT/social-4.0.x-SNAPSHOT.pom,
line
[jira] (MNG-5478) Order of plugin execution does not match order of definition in profile
[
https://jira.codehaus.org/browse/MNG-5478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339906#comment-339906
]
Jason van Zyl commented on MNG-5478:
Please read
https://cwiki.apache.org/confluence/display/MAVEN/Submitting+Issue+for+Maven%27s+Core
Order of plugin execution does not match order of definition in profile
---
Key: MNG-5478
URL: https://jira.codehaus.org/browse/MNG-5478
Project: Maven 2 3
Issue Type: Bug
Components: Plugins and Lifecycle, Profiles
Affects Versions: 3.0.5
Environment: Apache Maven 3.0.5
(r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 08:51:28-0500)
Maven home: /usr/local/Cellar/maven/3.0.5/libexec
Java version: 1.7.0_21, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: mac os x, version: 10.7.5, arch: x86_64, family: mac
Reporter: Martin Burger
I would like to create an assembly that contains an obfuscated all-in-one
version of the main JAR artifacts of a multi-module project. For this
purpose, I created a profile that binds the following plugins and goals,
respectively, to phase {{package}}:
# {{maven-shade-plugin:shade}} - creates a single JAR file that contains all
classes of all modules (basically, an uberjar that, however, does not contain
3rd-party libraries)
# {{proguard-maven-plugin:proguard}} - creates an obfuscated version of the
above JAR file
# {{maven-assembly-plugin:single}} - creates a single distributable archive
that contains the above obfuscated JAR file alongside of 3rd-party JAR files
and some CLI scripts
Having the above configuration, it should be sufficient to call {{maven
package}} in order to create the desired assembly.
However, the plugins are not executed in the above order but the ProGuard
plugin gets executed first which consequently complains about the missing
input file (the latter should be created by the Shade plugin).
As a workaround, I created a profile that only binds the first two plugins to
phase {{package}}. Furthermore, I first call {{mvn package}} to create the
obfuscated uberjar; only then, I call {{mvn assembly:single}} to create the
desired assembly file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5472) M3 also-make-dependents completely broken
[
https://jira.codehaus.org/browse/MNG-5472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339907#comment-339907
]
Jason van Zyl commented on MNG-5472:
Please read
https://cwiki.apache.org/confluence/display/MAVEN/Submitting+Issue+for+Maven%27s+Core
M3 also-make-dependents completely broken
-
Key: MNG-5472
URL: https://jira.codehaus.org/browse/MNG-5472
Project: Maven 2 3
Issue Type: Bug
Components: Command Line, Reactor and workspace
Affects Versions: 3.0.5
Reporter: Jörg Schaible
Command-line option -amd (--also-make-dependents) is completely broken in M3.
Here a list of processed projects with M3:
{noformat}
$ mvn-3.0.5 -amd -pl internal/commons/ldap validate
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] Scalaris Commons LDAP Project
[INFO] eIP UsersMgmt Provider LDAP
[INFO]
[INFO]
snip
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Scalaris Commons LDAP Project . SUCCESS [0.152s]
[INFO] eIP UsersMgmt Provider LDAP ... SUCCESS [0.014s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 13.505s
[INFO] Finished at: Tue Apr 30 09:03:02 CEST 2013
[INFO] Final Memory: 223M/638M
[INFO]
{noformat}
The same with M221:
{noformat}
$ mvn-2.2.1 -amd -pl internal/commons/ldap validate
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Scalaris Commons LDAP Project
[INFO] eIP UsersMgmt Provider LDAP
[INFO] eIP SecService EJB
[INFO] eIP SecService Client Commons
[INFO] eIP Datastore Connector for Scalaris DMS
[INFO] eIP Datastore Connector integration tests
[INFO] eIP EventMonitor OraDMS Provider
[INFO] eIP OracleText PreIdx Commons
[INFO] eIP OracleText PreIdx EJB
[INFO] eIP OracleText PreIdx Client Commons
[INFO] eIP OracleText PreIdx WebClient
[INFO] eIP OracleText PreIdx EAR
[INFO] eIP SecService WebClient
[INFO] eIP SecService WebService
[INFO] eIP SecService WebServiceX
[INFO] eIP SecService EAR
[INFO] eIP SecService WebService Client
[INFO] eIP SecService WebServiceX Client
[INFO] eIP UsersMgmt EAR
[INFO] essencio Exporter Job Processor Service EJB
[INFO] essencio Exporter Client Commons
[INFO] essencio Exporter Server
[INFO] essencio Exporter OraDMS Provider
[INFO] essencio File Upload WebService
[INFO] essencio File Upload WebService Client Application
[INFO] inCursa WebWorkplace
[INFO] inCursa Base FileUpload Client Configuration
[INFO] inCursa Base FileUpload WebService
[INFO] inCursa Base eIP EventMonitor EAR
[INFO] inCursa Base eIP Server
[INFO] inCursa Base Workplace
[INFO] inCursa Base Application Server Configuration
[INFO] inCursa Solutions Base Distribution
[INFO] inCursa Base Project Definition
[INFO] inCursa Base Exporter Server Application Configuration
[INFO] inCursa Base Exporter EAR
[INFO] inCursa Base Project
[INFO] Document Future doculife inCursa Workplace Client
[INFO] Document Future doculife inCursa Workplace
[INFO] Document Future doculife Project Distribution
[INFO]
snip
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Scalaris Commons LDAP Project . SUCCESS
[0.048s]
[INFO] eIP UsersMgmt Provider LDAP ... SUCCESS
[0.000s]
[INFO] eIP SecService EJB SUCCESS
[0.001s]
[INFO] eIP SecService Client Commons . SUCCESS
[0.000s]
[INFO] eIP Datastore Connector for Scalaris DMS .. SUCCESS
[0.001s]
[INFO] eIP Datastore Connector integration tests . SUCCESS
[0.000s]
[INFO] eIP EventMonitor OraDMS Provider .. SUCCESS
[0.001s]
[INFO] eIP OracleText PreIdx Commons . SUCCESS
[0.000s]
[INFO] eIP OracleText PreIdx EJB . SUCCESS
[0.001s]
[INFO] eIP OracleText PreIdx Client Commons .. SUCCESS
[0.000s]
[INFO] eIP OracleText PreIdx WebClient
[jira] (MNG-5479) ExecutionEvent.Type.SessionEnded omited when runtime exception thrown
[
https://jira.codehaus.org/browse/MNG-5479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-5479:
---
Fix Version/s: 3.2
ExecutionEvent.Type.SessionEnded omited when runtime exception thrown
-
Key: MNG-5479
URL: https://jira.codehaus.org/browse/MNG-5479
Project: Maven 2 3
Issue Type: Bug
Components: Embedding, IDEs
Affects Versions: 3.0.4, 3.0.5
Reporter: Milos Kleint
Fix For: 3.2
Attachments: maven.patch
in LifecycleStarter.java the ExecutionEvent.Type.SessionStarted is always
fired, but ExecutionEvent.Type.SessionEnded appears only be fired when in
some cases, omitted in case of RuntimeException thrown. IMHO the event should
be fired in finally {} block. See attached patch.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5479) ExecutionEvent.Type.SessionEnded omited when runtime exception thrown
[
https://jira.codehaus.org/browse/MNG-5479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339905#comment-339905
]
Jason van Zyl commented on MNG-5479:
This is easy to fix, and can be added to the code for the
AbstractMavenLifecycleParticipant#afterSessionEnd
ExecutionEvent.Type.SessionEnded omited when runtime exception thrown
-
Key: MNG-5479
URL: https://jira.codehaus.org/browse/MNG-5479
Project: Maven 2 3
Issue Type: Bug
Components: Embedding, IDEs
Affects Versions: 3.0.4, 3.0.5
Reporter: Milos Kleint
Fix For: 3.2
Attachments: maven.patch
in LifecycleStarter.java the ExecutionEvent.Type.SessionStarted is always
fired, but ExecutionEvent.Type.SessionEnded appears only be fired when in
some cases, omitted in case of RuntimeException thrown. IMHO the event should
be fired in finally {} block. See attached patch.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5472) M3 also-make-dependents completely broken
[
https://jira.codehaus.org/browse/MNG-5472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339908#comment-339908
]
Jörg Schaible commented on MNG-5472:
MNG-5207 contains the project (since years) together with an IT.
M3 also-make-dependents completely broken
-
Key: MNG-5472
URL: https://jira.codehaus.org/browse/MNG-5472
Project: Maven 2 3
Issue Type: Bug
Components: Command Line, Reactor and workspace
Affects Versions: 3.0.5
Reporter: Jörg Schaible
Command-line option -amd (--also-make-dependents) is completely broken in M3.
Here a list of processed projects with M3:
{noformat}
$ mvn-3.0.5 -amd -pl internal/commons/ldap validate
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] Scalaris Commons LDAP Project
[INFO] eIP UsersMgmt Provider LDAP
[INFO]
[INFO]
snip
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Scalaris Commons LDAP Project . SUCCESS [0.152s]
[INFO] eIP UsersMgmt Provider LDAP ... SUCCESS [0.014s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 13.505s
[INFO] Finished at: Tue Apr 30 09:03:02 CEST 2013
[INFO] Final Memory: 223M/638M
[INFO]
{noformat}
The same with M221:
{noformat}
$ mvn-2.2.1 -amd -pl internal/commons/ldap validate
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Scalaris Commons LDAP Project
[INFO] eIP UsersMgmt Provider LDAP
[INFO] eIP SecService EJB
[INFO] eIP SecService Client Commons
[INFO] eIP Datastore Connector for Scalaris DMS
[INFO] eIP Datastore Connector integration tests
[INFO] eIP EventMonitor OraDMS Provider
[INFO] eIP OracleText PreIdx Commons
[INFO] eIP OracleText PreIdx EJB
[INFO] eIP OracleText PreIdx Client Commons
[INFO] eIP OracleText PreIdx WebClient
[INFO] eIP OracleText PreIdx EAR
[INFO] eIP SecService WebClient
[INFO] eIP SecService WebService
[INFO] eIP SecService WebServiceX
[INFO] eIP SecService EAR
[INFO] eIP SecService WebService Client
[INFO] eIP SecService WebServiceX Client
[INFO] eIP UsersMgmt EAR
[INFO] essencio Exporter Job Processor Service EJB
[INFO] essencio Exporter Client Commons
[INFO] essencio Exporter Server
[INFO] essencio Exporter OraDMS Provider
[INFO] essencio File Upload WebService
[INFO] essencio File Upload WebService Client Application
[INFO] inCursa WebWorkplace
[INFO] inCursa Base FileUpload Client Configuration
[INFO] inCursa Base FileUpload WebService
[INFO] inCursa Base eIP EventMonitor EAR
[INFO] inCursa Base eIP Server
[INFO] inCursa Base Workplace
[INFO] inCursa Base Application Server Configuration
[INFO] inCursa Solutions Base Distribution
[INFO] inCursa Base Project Definition
[INFO] inCursa Base Exporter Server Application Configuration
[INFO] inCursa Base Exporter EAR
[INFO] inCursa Base Project
[INFO] Document Future doculife inCursa Workplace Client
[INFO] Document Future doculife inCursa Workplace
[INFO] Document Future doculife Project Distribution
[INFO]
snip
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Scalaris Commons LDAP Project . SUCCESS
[0.048s]
[INFO] eIP UsersMgmt Provider LDAP ... SUCCESS
[0.000s]
[INFO] eIP SecService EJB SUCCESS
[0.001s]
[INFO] eIP SecService Client Commons . SUCCESS
[0.000s]
[INFO] eIP Datastore Connector for Scalaris DMS .. SUCCESS
[0.001s]
[INFO] eIP Datastore Connector integration tests . SUCCESS
[0.000s]
[INFO] eIP EventMonitor OraDMS Provider .. SUCCESS
[0.001s]
[INFO] eIP OracleText PreIdx Commons . SUCCESS
[0.000s]
[INFO] eIP OracleText PreIdx EJB . SUCCESS
[0.001s]
[INFO] eIP OracleText PreIdx Client Commons .. SUCCESS
[0.000s]
[INFO] eIP OracleText PreIdx WebClient ... SUCCESS
[0.039s]
[jira] (MNG-5466) Maven 3.0.5 doesn't send credentials for mirrorOf*/mirrorOf
[
https://jira.codehaus.org/browse/MNG-5466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339909#comment-339909
]
Jason van Zyl commented on MNG-5466:
These instructions are wrong, the mirror needs the id of the server you want to
authenticate against.
Maven 3.0.5 doesn't send credentials for mirrorOf*/mirrorOf
---
Key: MNG-5466
URL: https://jira.codehaus.org/browse/MNG-5466
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.0.5
Environment: Win Server 2012 x64, JDK7u17 x64, Maven 3.0.5
Reporter: Justin Garrick
Attachments: bad-settings.xml, workaround-settings.xml
When {code:xml}mirrorOf*mirrorOf{code} is used to create a mirror-any
setup as described
[here|http://wiki.jfrog.org/confluence/display/rtf/configuring+artifacts+resolution],
Maven 3.0.5 does not send credentials. * is documented as a valid option in
the [Maven
documentation|http://maven.apache.org/guides/mini/guide-mirror-settings.html].
This seems to be a regression as this functionality worked as expected in
Maven 3.0.4. Specifying a {code:xml}mirror{code} for each
{code:xml}server{code} seems to function as a temporary workaround.
See the {{bad-settings.xml}} attachment that demonstrates the problem and
{{workaround-settings.xml}} that demonstrates the workaround.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5466) Maven 3.0.5 doesn't send credentials for mirrorOf*/mirrorOf
[
https://jira.codehaus.org/browse/MNG-5466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-5466.
--
Resolution: Not A Bug
Maven 3.0.5 doesn't send credentials for mirrorOf*/mirrorOf
---
Key: MNG-5466
URL: https://jira.codehaus.org/browse/MNG-5466
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.0.5
Environment: Win Server 2012 x64, JDK7u17 x64, Maven 3.0.5
Reporter: Justin Garrick
Attachments: bad-settings.xml, workaround-settings.xml
When {code:xml}mirrorOf*mirrorOf{code} is used to create a mirror-any
setup as described
[here|http://wiki.jfrog.org/confluence/display/rtf/configuring+artifacts+resolution],
Maven 3.0.5 does not send credentials. * is documented as a valid option in
the [Maven
documentation|http://maven.apache.org/guides/mini/guide-mirror-settings.html].
This seems to be a regression as this functionality worked as expected in
Maven 3.0.4. Specifying a {code:xml}mirror{code} for each
{code:xml}server{code} seems to function as a temporary workaround.
See the {{bad-settings.xml}} attachment that demonstrates the problem and
{{workaround-settings.xml}} that demonstrates the workaround.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5463) warn if maven-site-plugin's reportPlugins is configured in POM
[ https://jira.codehaus.org/browse/MNG-5463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339910#comment-339910 ] Jason van Zyl commented on MNG-5463: Can we fully deprecate this and remove it in 4.0.0? warn if maven-site-plugin's reportPlugins is configured in POM -- Key: MNG-5463 URL: https://jira.codehaus.org/browse/MNG-5463 Project: Maven 2 3 Issue Type: Improvement Components: Sites Reporting Affects Versions: 3.0.5, 3.1.0-alpha-1 Reporter: Herve Boutemy Fix For: 3.x / Backlog reportPlugins is finally not ready for end-users: documented as don't use in MSITE-647 in MSITE-684, the plugin parameter even disappeared from generated goals documentation but because of MNG-5001, the parameter can still be used: nothing will help users discover that they should go back to classical configuration without waiting for the generic MNG-5001, adding a warning will help people discover and fix the issue -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5567) Zip files are not included in the test classpath
Pablo La Greca created MNG-5567: --- Summary: Zip files are not included in the test classpath Key: MNG-5567 URL: https://jira.codehaus.org/browse/MNG-5567 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Environment: windows xp Reporter: Pablo La Greca when i added a dependency that was zip file eg dependency groupIdhsqldb/groupId artifactIdhsqldb/artifactId version1.7.3.0/version scopeprovided/scope typezip/type /dependency this file was not included in the test classpath and so the test would not pass -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5462) Artifact resolution API doesn't take into account dependency management information from associated POM
[
https://jira.codehaus.org/browse/MNG-5462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339911#comment-339911
]
Jason van Zyl commented on MNG-5462:
This is all handled by Aether and I honestly don't see anyone rewriting these
APIs. Aether handles dependency management just fine.
Artifact resolution API doesn't take into account dependency management
information from associated POM
---
Key: MNG-5462
URL: https://jira.codehaus.org/browse/MNG-5462
Project: Maven 2 3
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.0.5
Reporter: Vincent Massol
Example:
{code}
ArtifactResolutionRequest request = new ArtifactResolutionRequest()
.setArtifact(this.project.getArtifact())
.setArtifactDependencies(artifacts)
.setCollectionFilter(filter)
.setRemoteRepositories(this.remoteRepositories)
.setLocalRepository(this.localRepository)
.setManagedVersionMap(this.project.getManagedVersionMap())
.setResolveRoot(false);
ArtifactResolutionResult resolutionResult =
this.repositorySystem.resolve(request);
{code}
In this case if some dependencies (found in artifacts variable) have
dependencyManagement information, they won't be taken into account since the
passed managed version map is the projet's one and thus won't contain this
information.
It seems really a burden on the API user to have to find the MavenProject for
each artifact, get the managed version map for that artifact's POM and
compute a global version map.
I was really expecting the Maven Artifact resolution API to do the heavy
lifting on that.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5462) Artifact resolution API doesn't take into account dependency management information from associated POM
[
https://jira.codehaus.org/browse/MNG-5462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-5462.
--
Resolution: Won't Fix
Artifact resolution API doesn't take into account dependency management
information from associated POM
---
Key: MNG-5462
URL: https://jira.codehaus.org/browse/MNG-5462
Project: Maven 2 3
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.0.5
Reporter: Vincent Massol
Example:
{code}
ArtifactResolutionRequest request = new ArtifactResolutionRequest()
.setArtifact(this.project.getArtifact())
.setArtifactDependencies(artifacts)
.setCollectionFilter(filter)
.setRemoteRepositories(this.remoteRepositories)
.setLocalRepository(this.localRepository)
.setManagedVersionMap(this.project.getManagedVersionMap())
.setResolveRoot(false);
ArtifactResolutionResult resolutionResult =
this.repositorySystem.resolve(request);
{code}
In this case if some dependencies (found in artifacts variable) have
dependencyManagement information, they won't be taken into account since the
passed managed version map is the projet's one and thus won't contain this
information.
It seems really a burden on the API user to have to find the MavenProject for
each artifact, get the managed version map for that artifact's POM and
compute a global version map.
I was really expecting the Maven Artifact resolution API to do the heavy
lifting on that.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5455) mvn -amd should honour dependencyManagement POM imports
[
https://jira.codehaus.org/browse/MNG-5455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-5455.
--
Resolution: Not A Bug
mvn -amd should honour dependencyManagement POM imports
---
Key: MNG-5455
URL: https://jira.codehaus.org/browse/MNG-5455
Project: Maven 2 3
Issue Type: Improvement
Components: Dependencies
Affects Versions: 3.0.4, 3.0.5
Environment: *JAVA*
java version 1.7.0_13
Java(TM) SE Runtime Environment (build 1.7.0_13-b20)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
*MAVEN*
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19
14:51:28+0100)
Maven home: /home/ansgar/opt/maven3
Java version: 1.7.0_13, vendor: Oracle Corporation
Java home: /opt/java/jdk1.7.0_13/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: linux, version: 3.7.9-104.fc17.x86_64, arch: amd64, family:
unix
Reporter: Ansgar Konermann
mvn -amd does not build submodules which depend on a POM via means of a POM
import in the dependencyManagement section, like so:
{code}
dependencyManagement
dependencies
dependency
groupIdamd-test/groupId
artifactIddependency-management/artifactId
version1.0/version
scopeimport/scope
typepom/type
/dependency
/dependencies
/dependencyManagement
{code}
I set up an example project here:
https://github.com/ansgarkonermann/maven-amd-experiment
The project has three submodules:
{code}
modules
moduledependency-management/module
modulejava-library/module
modulegui/module
/modules
{code}
Both 'java-library' and 'gui' import 'dependency-management'.
We'd expect Maven to build gui and java-library when issuing mvn -amd
-pl dependency-management, however only dependency-management gets build.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5567) Zip files are not included in the test classpath
[ https://jira.codehaus.org/browse/MNG-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339912#comment-339912 ] Pablo La Greca commented on MNG-5567: - As I couldn't reopen MNG-2500 I created this new issue. Why did you close it as won't fix?. It makes perfect sense to have a dependency as zip and not as jar. If you take a look at the classpath documentation here: http://docs.oracle.com/javase/7/docs/technotes/tools/windows/classpath.html you can see that .zip files are valid as part of the classpath and maven should support that. I understand that adding support for that may cause side effects with the current maven behavior but at least you should add a workaround to be able to add the .zip dependency to the classpath and test classpath Zip files are not included in the test classpath Key: MNG-5567 URL: https://jira.codehaus.org/browse/MNG-5567 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Environment: windows xp Reporter: Pablo La Greca when i added a dependency that was zip file egdependency groupIdhsqldb/groupId artifactIdhsqldb/artifactId version1.7.3.0/version scopeprovided/scope typezip/type /dependency this file was not included in the test classpath and so the test would not pass -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5567) Zip files are not included in the test classpath
[ https://jira.codehaus.org/browse/MNG-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pablo La Greca updated MNG-5567: Priority: Critical (was: Major) Environment: (was: windows xp) Zip files are not included in the test classpath Key: MNG-5567 URL: https://jira.codehaus.org/browse/MNG-5567 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Reporter: Pablo La Greca Priority: Critical when i added a dependency that was zip file egdependency groupIdhsqldb/groupId artifactIdhsqldb/artifactId version1.7.3.0/version scopeprovided/scope typezip/type /dependency this file was not included in the test classpath and so the test would not pass -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5455) mvn -amd should honour dependencyManagement POM imports
[
https://jira.codehaus.org/browse/MNG-5455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339913#comment-339913
]
Jason van Zyl commented on MNG-5455:
DependencyManagement has never affected build ordering because it's a
specification of a preference for a dependency version, not a dependency
itself. Therefore it is not used in the calculation for the graph of projects
to be build when using -am or -amd.
mvn -amd should honour dependencyManagement POM imports
---
Key: MNG-5455
URL: https://jira.codehaus.org/browse/MNG-5455
Project: Maven 2 3
Issue Type: Improvement
Components: Dependencies
Affects Versions: 3.0.4, 3.0.5
Environment: *JAVA*
java version 1.7.0_13
Java(TM) SE Runtime Environment (build 1.7.0_13-b20)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
*MAVEN*
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19
14:51:28+0100)
Maven home: /home/ansgar/opt/maven3
Java version: 1.7.0_13, vendor: Oracle Corporation
Java home: /opt/java/jdk1.7.0_13/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: linux, version: 3.7.9-104.fc17.x86_64, arch: amd64, family:
unix
Reporter: Ansgar Konermann
mvn -amd does not build submodules which depend on a POM via means of a POM
import in the dependencyManagement section, like so:
{code}
dependencyManagement
dependencies
dependency
groupIdamd-test/groupId
artifactIddependency-management/artifactId
version1.0/version
scopeimport/scope
typepom/type
/dependency
/dependencies
/dependencyManagement
{code}
I set up an example project here:
https://github.com/ansgarkonermann/maven-amd-experiment
The project has three submodules:
{code}
modules
moduledependency-management/module
modulejava-library/module
modulegui/module
/modules
{code}
Both 'java-library' and 'gui' import 'dependency-management'.
We'd expect Maven to build gui and java-library when issuing mvn -amd
-pl dependency-management, however only dependency-management gets build.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5449) Conflicting dependencies and NoClassDefFoundError
[
https://jira.codehaus.org/browse/MNG-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-5449.
--
Resolution: Won't Fix
Conflicting dependencies and NoClassDefFoundError
-
Key: MNG-5449
URL: https://jira.codehaus.org/browse/MNG-5449
Project: Maven 2 3
Issue Type: Bug
Components: Artifacts and Repositories, Dependencies
Affects Versions: 3.0.4
Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
Java version: 1.6.0_37, vendor: Apple Inc.
Default locale: en_US, platform encoding: MacRoman
OS name: mac os x, version: 10.6.8, arch: x86_64, family: mac
Reporter: Daniel Lipsitt
h3. Overview
I have conflicting transitive dependencies that lead to a runtime
{{NoClassDefFoundError}} without any warning.
h3. Details
I have a project whose transitive dependencies include two versions of
{{org.apache.maven/maven-artifact}}, 3.0.4 and 2.2.1.
{code:xml|title=pom.xml}
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
groupIddemo/groupId
artifactIddemo/artifactId
version0.0.1-SNAPSHOT/version
namedemo/name
dependencies
dependency
groupIdorg.antlr/groupId
artifactIdantlr4-maven-plugin/artifactId
version4.0/version
typemaven-plugin/type
/dependencydependency
groupIdorg.apache.maven.plugin-tools/groupId
artifactIdmaven-plugin-tools-generators/artifactId
version3.2/version
/dependency
/dependencies
/project
{code}
These artifacts have conflicting transitive dependencies:
{code}
$ mvn dependency:tree -Dverbose -Dincludes=org.apache.maven:maven-artifact
[INFO] demo:demo:jar:0.0.1-SNAPSHOT
[INFO] +- org.antlr:antlr4-maven-plugin:maven-plugin:4.0:compile
[INFO] | +- org.apache.maven:maven-plugin-api:jar:3.0.4:compile
[INFO] | | \- org.apache.maven:maven-artifact:jar:3.0.4:compile
[INFO] | \- org.apache.maven:maven-project:jar:2.2.1:compile
[INFO] | +- org.apache.maven:maven-artifact-manager:jar:2.2.1:compile
[INFO] | | \- (org.apache.maven:maven-artifact:jar:2.2.1:compile -
omitted for conflict with 3.0.4)
[INFO] | \- (org.apache.maven:maven-artifact:jar:2.2.1:compile - omitted
for conflict with 3.0.4)
[INFO] \-
org.apache.maven.plugin-tools:maven-plugin-tools-generators:jar:3.2:compile
[INFO]+-
org.apache.maven.plugin-tools:maven-plugin-tools-api:jar:3.2:compile
[INFO]| \- (org.apache.maven:maven-artifact:jar:2.2.1:compile - omitted
for conflict with 3.0.4)
[INFO]\- org.apache.maven:maven-plugin-descriptor:jar:2.2.1:compile
[INFO] \- (org.apache.maven:maven-artifact:jar:2.2.1:compile - omitted
for conflict with 3.0.4)
{code}
Here's some simple code importing a class from one of the direct dependencies:
{code:java|title=Main.java}
package demo;
import org.apache.maven.tools.plugin.generator.GeneratorUtils;
public class Main {
public static void main(String[] args) {
System.out.println(GeneratorUtils.toText({@code demo}));
}
}
{code}
When run, it gives the following traceback:
{code}
Exception in thread main java.lang.NoClassDefFoundError:
org/apache/maven/artifact/DependencyResolutionRequiredException
at demo.Main.main(Main.java:6)
Caused by: java.lang.ClassNotFoundException:
org.apache.maven.artifact.DependencyResolutionRequiredException
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
... 1 more
{code}
It turns out that {{DependencyResolutionRequiredException}} is present in
maven-artifact 2.x, but not in 3.x.
Given the above, I would have expected a warning of some kind about the
conflicting transitive dependencies if they can't be resolved automatically.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5449) Conflicting dependencies and NoClassDefFoundError
[
https://jira.codehaus.org/browse/MNG-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339914#comment-339914
]
Jason van Zyl commented on MNG-5449:
We're done trying to retain compatibility between 2.x and 3.x at this point.
Conflicting dependencies and NoClassDefFoundError
-
Key: MNG-5449
URL: https://jira.codehaus.org/browse/MNG-5449
Project: Maven 2 3
Issue Type: Bug
Components: Artifacts and Repositories, Dependencies
Affects Versions: 3.0.4
Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
Java version: 1.6.0_37, vendor: Apple Inc.
Default locale: en_US, platform encoding: MacRoman
OS name: mac os x, version: 10.6.8, arch: x86_64, family: mac
Reporter: Daniel Lipsitt
h3. Overview
I have conflicting transitive dependencies that lead to a runtime
{{NoClassDefFoundError}} without any warning.
h3. Details
I have a project whose transitive dependencies include two versions of
{{org.apache.maven/maven-artifact}}, 3.0.4 and 2.2.1.
{code:xml|title=pom.xml}
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
groupIddemo/groupId
artifactIddemo/artifactId
version0.0.1-SNAPSHOT/version
namedemo/name
dependencies
dependency
groupIdorg.antlr/groupId
artifactIdantlr4-maven-plugin/artifactId
version4.0/version
typemaven-plugin/type
/dependencydependency
groupIdorg.apache.maven.plugin-tools/groupId
artifactIdmaven-plugin-tools-generators/artifactId
version3.2/version
/dependency
/dependencies
/project
{code}
These artifacts have conflicting transitive dependencies:
{code}
$ mvn dependency:tree -Dverbose -Dincludes=org.apache.maven:maven-artifact
[INFO] demo:demo:jar:0.0.1-SNAPSHOT
[INFO] +- org.antlr:antlr4-maven-plugin:maven-plugin:4.0:compile
[INFO] | +- org.apache.maven:maven-plugin-api:jar:3.0.4:compile
[INFO] | | \- org.apache.maven:maven-artifact:jar:3.0.4:compile
[INFO] | \- org.apache.maven:maven-project:jar:2.2.1:compile
[INFO] | +- org.apache.maven:maven-artifact-manager:jar:2.2.1:compile
[INFO] | | \- (org.apache.maven:maven-artifact:jar:2.2.1:compile -
omitted for conflict with 3.0.4)
[INFO] | \- (org.apache.maven:maven-artifact:jar:2.2.1:compile - omitted
for conflict with 3.0.4)
[INFO] \-
org.apache.maven.plugin-tools:maven-plugin-tools-generators:jar:3.2:compile
[INFO]+-
org.apache.maven.plugin-tools:maven-plugin-tools-api:jar:3.2:compile
[INFO]| \- (org.apache.maven:maven-artifact:jar:2.2.1:compile - omitted
for conflict with 3.0.4)
[INFO]\- org.apache.maven:maven-plugin-descriptor:jar:2.2.1:compile
[INFO] \- (org.apache.maven:maven-artifact:jar:2.2.1:compile - omitted
for conflict with 3.0.4)
{code}
Here's some simple code importing a class from one of the direct dependencies:
{code:java|title=Main.java}
package demo;
import org.apache.maven.tools.plugin.generator.GeneratorUtils;
public class Main {
public static void main(String[] args) {
System.out.println(GeneratorUtils.toText({@code demo}));
}
}
{code}
When run, it gives the following traceback:
{code}
Exception in thread main java.lang.NoClassDefFoundError:
org/apache/maven/artifact/DependencyResolutionRequiredException
at demo.Main.main(Main.java:6)
Caused by: java.lang.ClassNotFoundException:
org.apache.maven.artifact.DependencyResolutionRequiredException
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
... 1 more
{code}
It turns out that {{DependencyResolutionRequiredException}} is present in
maven-artifact 2.x, but not in 3.x.
Given the above, I would have expected a warning of some kind about the
conflicting transitive dependencies if they can't be resolved automatically.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5440) default-value on mojo parameter of type collection or array effectively make parameter read-only
[
https://jira.codehaus.org/browse/MNG-5440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-5440:
---
Fix Version/s: Issues to be reviewed for 4.x
default-value on mojo parameter of type collection or array effectively make
parameter read-only
Key: MNG-5440
URL: https://jira.codehaus.org/browse/MNG-5440
Project: Maven 2 3
Issue Type: Bug
Reporter: Jan Sievers
Fix For: Issues to be reviewed for 4.x
Attachments: mojoParamsBug.zip
If you use default-value on collection or array mojo parameters like
{code}
/**
* @parameter default-value=foo,bar
*/
private ListString param1;
{code}
the default value will always win over pom.xml configuration.
See demo project attached.
Steps to reproduce:
1. {{mvn install}} on the demo project
2. {{mvn compile -f test-pom.xml -X -e}} on the demo project
you can see in the debug log that mojo configuration
[DEBUG] Configuration: ?xml version=1.0 encoding=UTF-8?
configuration
param1 default-value=foo,bar
param1non-default value1 param1/param1
param1non-default value2 param1/param1
/param1
param2 default-value=baz
param2non-default value1 param2/param2
param2non-default value2 param2/param2
/param2
/configuration
will not be aplied correctly:
[DEBUG] Configuring mojo 'mojoParamsBug:mojoParamsBug:0.0.1-SNAPSHOT:demo'
with basic configurator --
[DEBUG] (f) param1 = [foo, bar]
[DEBUG] (f) param2 = [baz]
[DEBUG] -- end configuration --
[INFO] param1: [foo, bar]
[INFO] param2: [baz]
If default values for srrays/collection are not supported, this should fail
the build in step 1. above.
If they are supported, the configurator should be fixed to actually allow
configuring non-default values.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5512) Deploy uses passwords that failed decryption; retries even if login fails
[ https://jira.codehaus.org/browse/MNG-5512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339915#comment-339915 ] SebbASF commented on MNG-5512: -- The issue here can be reproduced with any project that requires a login to deploy. However I have attached one that should be usable by any committer that can deploy org.apache.maven snapshots Deploy uses passwords that failed decryption; retries even if login fails - Key: MNG-5512 URL: https://jira.codehaus.org/browse/MNG-5512 Project: Maven 2 3 Issue Type: Bug Reporter: SebbASF Attachments: mng5512.zip [See MDEPLOY-130 which was closed as being an issue in Maven core] If passwords have been encrypted, deploy fails to notice if the password decryption failed. Furthermore, it carries on trying to login even after a login failure. This is true even if the decryption succeeded but the password was incorrect or no encryption was used and the password is incorrect. This is bad as it can result in lockout due to the multiple failed logins - deploy needs to login several times - and may cause unnecessary work for system admins. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5512) Deploy uses passwords that failed decryption; retries even if login fails
[ https://jira.codehaus.org/browse/MNG-5512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SebbASF updated MNG-5512: - Attachment: mng5512.zip Sample project Deploy uses passwords that failed decryption; retries even if login fails - Key: MNG-5512 URL: https://jira.codehaus.org/browse/MNG-5512 Project: Maven 2 3 Issue Type: Bug Reporter: SebbASF Attachments: mng5512.zip [See MDEPLOY-130 which was closed as being an issue in Maven core] If passwords have been encrypted, deploy fails to notice if the password decryption failed. Furthermore, it carries on trying to login even after a login failure. This is true even if the decryption succeeded but the password was incorrect or no encryption was used and the password is incorrect. This is bad as it can result in lockout due to the multiple failed logins - deploy needs to login several times - and may cause unnecessary work for system admins. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5436) Up to Maven 3.0.4, there can be only one ExecutionListener
[ https://jira.codehaus.org/browse/MNG-5436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5436: --- Fix Version/s: Issues to be reviewed for 4.x Up to Maven 3.0.4, there can be only one ExecutionListener -- Key: MNG-5436 URL: https://jira.codehaus.org/browse/MNG-5436 Project: Maven 2 3 Issue Type: Improvement Components: Logging Affects Versions: 3.0.4 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100) Maven home: C:\Program Files (x86)\Maven-3.0.4\bin\.. Java version: 1.6.0_30, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_30\jre Default locale: fr_FR, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Nicolas Delsaux Fix For: Issues to be reviewed for 4.x I'm working on a maven growl extension (https://github.com/Riduidel/maven-growl-plugin) that should send growl notification based upon project lifecycle. Typical use case is to receive a growl notification when build is over. According to discussion with olamy, there currently can be only one execution listener in maven. What's more, some code has to be added to execution listener class if one want these listeners calls to be chained. Like in Swing for all event listeners, it should be possible to have more than one listener, and those listeners management should be handled by maven itself, and not by the listener. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5435) Project which has shared dependency with a plugin fails to recognize artifact was downloaded and fails.
[
https://jira.codehaus.org/browse/MNG-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-5435:
---
Fix Version/s: Issues to be reviewed for 4.x
Project which has shared dependency with a plugin fails to recognize artifact
was downloaded and fails.
---
Key: MNG-5435
URL: https://jira.codehaus.org/browse/MNG-5435
Project: Maven 2 3
Issue Type: Bug
Components: Artifacts and Repositories, Dependencies
Affects Versions: 3.0.4
Reporter: Kirk Rasmussen
Priority: Blocker
Fix For: Issues to be reviewed for 4.x
Attachments: a.3, maven2.log, maven.log, pom.xml, settings.xml,
simple.zip
This is a twofer bug report :)
Issue #1:
I have included a stripped down version of an example using the maven antrun
plugin to spawn the Antlr tool. For technical reasons we cannot use the
native maven Antlr plugin.
If you look at the attached project you will see that Antlr is a dependency
of both the antrun plugin:
{code}
...
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
dependencies
dependency
groupIdorg.antlr/groupId
artifactIdantlr/artifactId
version${antlr.version}/version
/dependency
...
{code}
And the project itself:
{code}
...
dependencies
dependency
groupIdorg.antlr/groupId
artifactIdantlr/artifactId
/dependency
/dependencies
...
{code}
Starting with a blank M2 local repo, and then running
$ mvn -e -X -U clean install -s settings.xml /tmp/maven.log
Results in failure:
Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not
find artifact org.antlr:antlr:jar:3.4
However this artifact was indeed downloaded (first as a project dependency).
I stepped through some of the Maven code and it appears to fail during the
second run through
org.sonatype.aether.impl.internal.DefaultArtifactResolver#resolve as a plugin
dependency.
I strongly suspect it has to do with how
org.sonatype.aether.impl.internal.EnhancedLocalRepositoryManager#find is
implemented. It sees the file but it is not being tracked correctly I believe
so it ignores it.
If you run the build a second time it will then succeed because the Antlr
artifacts will be available as they are in the local repo from the previous
run.
$ mvn -e -X -U clean install -s settings.xml /tmp/maven2.log
I observed the exact same problem when using the Maven enforcer plugin along
with TestNG as they both depend on beanshell and with the Maven GWT plugin
and GWT project dependencies.
This was discovered as an issue once we started clearing out our local repo.
Once the artifacts are populated locally the issue goes away. It takes a
couple of runs to get past the bogus missing artifact errors but after that
it is ok. It's difficult to predict when it will fail w/o being intimately
familiar with all plugin/project dependencies per project.
I noticed that having Antlr 3.0.4 only as plugin dependency works fine. It
also works fine if it's only a project dependency. It's the combination of
having it both as a plugin AND a project dependency causes this problem.
#2
My first thought to get around issue #1 was to use dependency:resolve as a
pre-build step after cleaning the local repo but that doesn't full solve the
problem.
Using the Mavan dependency:resolve and dependency:resolve-plugins goals
partially sidesteps issue #1 but it still gets confused about inter-module
dependencies.
For example I have a simple multi-module project that includes: foo-module,
bar-module, and baz-module (see simple.zip).
Running:
$ mvn dependency:resolve dependency:resolve-plugins -s settings.xml
Results in a build failure on the baz-module:
[INFO] acme-pom .. SUCCESS [6.835s]
[INFO] foo-module SUCCESS [1.327s]
[INFO] bar-module SUCCESS [0.090s]
[INFO] baz-module FAILURE [0.012s]
This seems to avoid issue #1 as it doesn't complain about missing Antlr
artifacts anymore but it gets stuck on the baz-module with the error:
[ERROR] Failed to execute goal on project baz-module: Could not resolve
dependencies for project com.acme:baz-module:jar:4.0.0-SNAPSHOT: The
following artifacts could not be resolved:
com.acme:foo-module:jar:4.0.0-SNAPSHOT,
com.acme:bar-module:jar:4.0.0-SNAPSHOT: Could not find artifact
com.acme:foo-module:jar:4.0.0-SNAPSHOT - [Help 1]
In our real projects there are many
[jira] (MNG-5431) Support include scope
[ https://jira.codehaus.org/browse/MNG-5431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5431. -- Resolution: Duplicate Support include scope --- Key: MNG-5431 URL: https://jira.codehaus.org/browse/MNG-5431 Project: Maven 2 3 Issue Type: Improvement Components: Dependencies, Inheritance and Interpolation, POM Affects Versions: 3.0.4, 3.1.x Reporter: Matthew Adams Attachments: included-pom.xml, including-pom.xml I'd like to request an improvement over the current pom import support. The current import support only goes so far as adding dependencies to the dependencyManagement section of a pom. The importing pom still is left to add those dependencies to its own dependencies, which is inconvenient, especially for imported poms that define many dependencies. Instead, I propose the addition of a new scope called include that can be used to add the imported pom's dependencies section to the importing pom's dependencies section. A pom that wants to include another pom, then, would simply declare the dependency on the included pom's groupId:artifactId:version, but use a scope of include, which would imply type pom. The important thing to realize is that this could be done in the dependencies section of the including pom (not necessarily dependencyManagementdependencies). For example, in the including pom's dependencies (at XPath project/dependencies, not project/dependencyManagement/dependencies): dependency groupIdme.matthewadams/groupId artifactIddatanucleus-rdbms/artifactId scopeinclude/scope !-- NEW! different from import! -- version3.1.4/version /dependency The scope include implies typepom/type; declaring it explicitly would be ok, but declaring any other type would be an error. See the two poms attached to this request for a more thorough example. Also, see user list discussion at http://maven.40175.n5.nabble.com/New-Maven-idea-include-import-tp5745916.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5431) Support include scope
[ https://jira.codehaus.org/browse/MNG-5431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339918#comment-339918 ] Jason van Zyl commented on MNG-5431: Please follow this issue as I believe what you want would generally fall under mixins. Where you want to have a whole dependencyManagement and dependencies section. https://jira.codehaus.org/browse/MNG-5437 Support include scope --- Key: MNG-5431 URL: https://jira.codehaus.org/browse/MNG-5431 Project: Maven 2 3 Issue Type: Improvement Components: Dependencies, Inheritance and Interpolation, POM Affects Versions: 3.0.4, 3.1.x Reporter: Matthew Adams Attachments: included-pom.xml, including-pom.xml I'd like to request an improvement over the current pom import support. The current import support only goes so far as adding dependencies to the dependencyManagement section of a pom. The importing pom still is left to add those dependencies to its own dependencies, which is inconvenient, especially for imported poms that define many dependencies. Instead, I propose the addition of a new scope called include that can be used to add the imported pom's dependencies section to the importing pom's dependencies section. A pom that wants to include another pom, then, would simply declare the dependency on the included pom's groupId:artifactId:version, but use a scope of include, which would imply type pom. The important thing to realize is that this could be done in the dependencies section of the including pom (not necessarily dependencyManagementdependencies). For example, in the including pom's dependencies (at XPath project/dependencies, not project/dependencyManagement/dependencies): dependency groupIdme.matthewadams/groupId artifactIddatanucleus-rdbms/artifactId scopeinclude/scope !-- NEW! different from import! -- version3.1.4/version /dependency The scope include implies typepom/type; declaring it explicitly would be ok, but declaring any other type would be an error. See the two poms attached to this request for a more thorough example. Also, see user list discussion at http://maven.40175.n5.nabble.com/New-Maven-idea-include-import-tp5745916.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5423) mvn shell script doesn't always export JAVA_HOME
[ https://jira.codehaus.org/browse/MNG-5423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5423: --- Fix Version/s: Issues to be reviewed for 4.x mvn shell script doesn't always export JAVA_HOME Key: MNG-5423 URL: https://jira.codehaus.org/browse/MNG-5423 Project: Maven 2 3 Issue Type: Bug Components: Command Line Affects Versions: 3.0.4, 3.1.0-alpha-1 Reporter: Tom Mueller Fix For: Issues to be reviewed for 4.x There are code paths through the mvn shell script that do not result in JAVA_HOME being exported if it is not set when entering the script. I found this in 3.0.4 on MacOS X. JAVA_HOME gets set at line 117, but then is never exported, so the java process doesn't get the value. Based on reading the code, I see other paths through the script where JAVA_HOME is not exported even though it gets set by the script. On the head, there are statements like the following (line 65): export JAVA_HOME=/System/Library/Java/JavaVirtualMachines/CurrentJDK/Contents/Home This is not valid /bin/sh syntax. /bin/sh does not allow the export to be on the same line where the environment variable is set. There are also paths on the head where JAVA_HOME is not exported when it is set. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5408) Explicit profile activation in pom.xml
[
https://jira.codehaus.org/browse/MNG-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339919#comment-339919
]
Jason van Zyl commented on MNG-5408:
I think a better idea here would be mixins:
https://jira.codehaus.org/browse/MNG-5437
Explicit profile activation in pom.xml
--
Key: MNG-5408
URL: https://jira.codehaus.org/browse/MNG-5408
Project: Maven 2 3
Issue Type: Improvement
Components: Profiles
Affects Versions: 3.0.4
Reporter: Paul Lowry
+Background:+
Organisations should be able to define complex maven tasks, each involving
multiple plugin executions, in a way that is standardised for use in all
projects.
The obvious solution would seem to be profiles:
* They allow us to define maven project configuration and multiple plugin
executions
* They can be enabled/disabled, and they are not mutually exclusive, so we
can use them to run execution A or execution B of the same plugin, or A and
then B, or any other sequence (note: this sort of control is not available in
pluginManagement)
For example, consider an organisation where some project teams do integration
testing of war artifacts by running them in Jetty, whereas others use Tomcat.
Both scenarios require several plugins to run, and though the process is
similar it is not the same (for our example, let's assume that Jetty requires
a test context file, and Tomcat projects have a different naming scheme for
their test classes).
Using profiles in a root pom, which is the parent for all projects in the
organisation, we can make the process for running a war in Jetty/Tomcat quite
simple, and more importantly quite consistent:
{code:xml|title=root.pom.xml}
project
profiles
!--
profile for running integration tests using jetty
--
profile
idrunJetty/id
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-resources-plugin/artifactId
executions
execution
idrunJetty.prep/id
phasepre-integration-test/phase
goals
goalcopy-resources/goal
/goals
configuration
resources
resource
directory\${project.build.testOutputDirectory}/jetty/directory
filteringtrue/filtering
/resource
/resources
outputDirectory\${project.build.directory}/\${project.build.finalName}/outputDirectory
/configuration
/execution
/executions
/plugin
plugin
groupIdorg.mortbay.jetty/groupId
artifactIdjetty-maven-plugin/artifactId
executions
execution
idrunJetty.start/id
phasepre-integration-test/phase
!-- start server in jetty, using property
${runJetty.port} --
/execution
execution
idrunJetty.stop/id
phasepost-integration-test/phase
!-- stop jetty --
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-failsafe-plugin/artifactId
executions
execution
idrunJetty.test/id
phaseintegration-test/phase
goals
goalintegration-test/goal
goalverify/goal
/goals
/execution
/executions
/plugin
/plugins
/build
/profile
!--
profile for running integration tests using tomcat
--
profile
idrunTomcat/id
build
plugins
plugin
[jira] (MNG-5463) warn if maven-site-plugin's reportPlugins is configured in POM
[ https://jira.codehaus.org/browse/MNG-5463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339920#comment-339920 ] Herve Boutemy commented on MNG-5463: this is a configuration parameter, so nothing appears in pom schema: I don't see anything to deprecate and this warning would be useful warn if maven-site-plugin's reportPlugins is configured in POM -- Key: MNG-5463 URL: https://jira.codehaus.org/browse/MNG-5463 Project: Maven 2 3 Issue Type: Improvement Components: Sites Reporting Affects Versions: 3.0.5, 3.1.0-alpha-1 Reporter: Herve Boutemy Fix For: 3.x / Backlog reportPlugins is finally not ready for end-users: documented as don't use in MSITE-647 in MSITE-684, the plugin parameter even disappeared from generated goals documentation but because of MNG-5001, the parameter can still be used: nothing will help users discover that they should go back to classical configuration without waiting for the generic MNG-5001, adding a warning will help people discover and fix the issue -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5384) Declarative artifacts
[
https://jira.codehaus.org/browse/MNG-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-5384:
---
Fix Version/s: Issues to be reviewed for 4.x
Declarative artifacts
-
Key: MNG-5384
URL: https://jira.codehaus.org/browse/MNG-5384
Project: Maven 2 3
Issue Type: New Feature
Components: Artifacts and Repositories, POM, Reactor and workspace
Affects Versions: 3.0.4
Reporter: Tuomas Kiviaho
Fix For: Issues to be reviewed for 4.x
Currently there's no way to know what attachments a project is going to have
beforehand. Lack of this feature is currently patched inside Aether where
test-jar for instance has a special treatment prior packaging phase so that
we can get a file pointer to ${project.target.testOutputDirectory}.
Maven 2 had this hack embedded inside of it, but with Maven 3 the project
attachments list doesn't contain test-jar until it is actually added to the
project. I had to patch MBUILDHELPER-41 to be able attach this artifact prior
packaging phase and remove it at prepare-package so that the actual
attachment could be added to the project.
I propose that POM could have a section similar to {{build.finalName}} where
you'd list the attacments that the project is going to introduce. For
backwards compatibility this of course would not be required. Plugins such as
jar, sources and javadoc could kick in automatically when pom contains the
respective declarations (race conditions would arise between
maven-bundle-plugin and jar for instance).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5404) Wrong resolution of dependency scope by Maven 3
[
https://jira.codehaus.org/browse/MNG-5404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339921#comment-339921
]
Jason van Zyl commented on MNG-5404:
Please read
https://cwiki.apache.org/confluence/display/MAVEN/Submitting+Issue+for+Maven%27s+Core
Wrong resolution of dependency scope by Maven 3
---
Key: MNG-5404
URL: https://jira.codehaus.org/browse/MNG-5404
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.0.4
Reporter: Dmitry Batrak
Attachments: build.log
For the following POM:
{noformat}
project
modelVersion4.0.0/modelVersion
groupIdtest/groupId
artifactIdA/artifactId
version1.0/version
dependencies
dependency
groupIdorg.apache.axis2/groupId
artifactIdaxis2-xmlbeans/artifactId
version1.5/version
scopeprovided/scope
/dependency
dependency
groupIdorg.apache.axis2/groupId
artifactIdaxis2-codegen/artifactId
version1.5/version
exclusions
exclusion
groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-stax-api_1.0_spec/artifactId
/exclusion
/exclusions
/dependency
/dependencies
/project
{noformat}
running 'mvn dependency:resolve' using Maven 3.0.4 yields a wrong result.
Namely, geronimo-stax-api_1.0_spec dependency is reported as having the
resolved scope of 'compile'. With Maven 2.2.1 I get the 'provided' scope, as
expected.
Debug log is attached.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5347) Support expression language in ${...}
[
https://jira.codehaus.org/browse/MNG-5347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-5347.
--
Resolution: Won't Fix
Support expression language in ${...}
-
Key: MNG-5347
URL: https://jira.codehaus.org/browse/MNG-5347
Project: Maven 2 3
Issue Type: Wish
Components: General
Affects Versions: 3.0.4
Environment: mistria@mistria--rh:~$ mvn -version
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /home/mistria/apps/apache-maven-3.0.4
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux, version: 3.2.0-30-generic, arch: amd64, family: unix
Reporter: Mickael Istria
Use-case:
I want to give as input of my surefire-plugin
{code}
configuration
skip${skipTests} || ${skipDownloadRuntimes}/skip
configuration
{code}
This won't work because the expressions are not evaluated. Boolean arguments
in plugin are set to something like Boolean.parseBoolean, which is quite
limited.
Instead, we could think of introducing an expression language, such as
Groovy, that would allow expressions as parameters for plugins.
Then let's say skipTests=false and skipDownloadRuntimes=true, Maven would
first replace $#123;skipTests} || $#123;skipDownloadRuntimes} by false
|| true and then this evaluator would evaluate that to false, and skip
will receive the value false.
This would for sure make maven less verbose in some cases.
*EDIT* (thanks Ondrej for inspiring commnent)
Actually, this syntax would make more sense, and allow an expression language:
{code}
configuration
skip${skipTests|| skipDownloadRuntimes}/skip
configuration
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5347) Support expression language in ${...}
[
https://jira.codehaus.org/browse/MNG-5347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339923#comment-339923
]
Jason van Zyl commented on MNG-5347:
Never going to happen. We are not going back to Jelly and having any EL in the
POM.
Support expression language in ${...}
-
Key: MNG-5347
URL: https://jira.codehaus.org/browse/MNG-5347
Project: Maven 2 3
Issue Type: Wish
Components: General
Affects Versions: 3.0.4
Environment: mistria@mistria--rh:~$ mvn -version
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /home/mistria/apps/apache-maven-3.0.4
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux, version: 3.2.0-30-generic, arch: amd64, family: unix
Reporter: Mickael Istria
Use-case:
I want to give as input of my surefire-plugin
{code}
configuration
skip${skipTests} || ${skipDownloadRuntimes}/skip
configuration
{code}
This won't work because the expressions are not evaluated. Boolean arguments
in plugin are set to something like Boolean.parseBoolean, which is quite
limited.
Instead, we could think of introducing an expression language, such as
Groovy, that would allow expressions as parameters for plugins.
Then let's say skipTests=false and skipDownloadRuntimes=true, Maven would
first replace $#123;skipTests} || $#123;skipDownloadRuntimes} by false
|| true and then this evaluator would evaluate that to false, and skip
will receive the value false.
This would for sure make maven less verbose in some cases.
*EDIT* (thanks Ondrej for inspiring commnent)
Actually, this syntax would make more sense, and allow an expression language:
{code}
configuration
skip${skipTests|| skipDownloadRuntimes}/skip
configuration
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5512) Deploy uses passwords that failed decryption; retries even if login fails
[ https://jira.codehaus.org/browse/MNG-5512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339922#comment-339922 ] SebbASF commented on MNG-5512: -- Unpack the project zip in a suitable directory. Ensure that settings.xml has the following section completed correctly: !-- To publish a snapshot -- server idapache.snapshots.https/id usernamename/username passwordpassword/password /server Use mvn deploy to deploy the snapshot. It should deploy the snapshot OK to the org.apache.maven snapshot repo. Now change your login password (but without changing settings.xml) This is the normal use case - user updates login password, but forgets to update settings.xml. [If you don't wish to change the login password, change the saved password in settings.xml instead so it is no longer valid] Rerun mvn deploy. The deploy phase will try to login several times with the same password; these should all fail. BEWARE: this may well cause the user account to be locked. [ASF Maven committers should be able to reset their password using the self-service app. If not, they will have to contact the ASF Infra team] The attempt to deploy a snapshot should not repeatedly use the same bad password, but should cause the process to be abandoned as soon as the password is first rejected. Deploy uses passwords that failed decryption; retries even if login fails - Key: MNG-5512 URL: https://jira.codehaus.org/browse/MNG-5512 Project: Maven 2 3 Issue Type: Bug Reporter: SebbASF Attachments: mng5512.zip [See MDEPLOY-130 which was closed as being an issue in Maven core] If passwords have been encrypted, deploy fails to notice if the password decryption failed. Furthermore, it carries on trying to login even after a login failure. This is true even if the decryption succeeded but the password was incorrect or no encryption was used and the password is incorrect. This is bad as it can result in lockout due to the multiple failed logins - deploy needs to login several times - and may cause unnecessary work for system admins. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5331) JavaFX should be added to compilation classpath
[ https://jira.codehaus.org/browse/MNG-5331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339924#comment-339924 ] Jason van Zyl commented on MNG-5331: System dependencies are going away in general and I can't see us doing anything special for JavaFX. A special JavaFX plugin can likely do anything special that's required and build up a classloader and do whatever special things it requires. JavaFX should be added to compilation classpath --- Key: MNG-5331 URL: https://jira.codehaus.org/browse/MNG-5331 Project: Maven 2 3 Issue Type: Wish Reporter: Konstantin Solomatov Since JDK 1.7, JavaFX is part of JRE and JDK. However, Maven doesn't include them into classpath automatically. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5331) JavaFX should be added to compilation classpath
[ https://jira.codehaus.org/browse/MNG-5331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5331. -- Resolution: Won't Fix JavaFX should be added to compilation classpath --- Key: MNG-5331 URL: https://jira.codehaus.org/browse/MNG-5331 Project: Maven 2 3 Issue Type: Wish Reporter: Konstantin Solomatov Since JDK 1.7, JavaFX is part of JRE and JDK. However, Maven doesn't include them into classpath automatically. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5315) Artifact resolution sporadically fails in parallel builds
[
https://jira.codehaus.org/browse/MNG-5315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-5315:
---
Fix Version/s: Issues to be reviewed for 4.x
Artifact resolution sporadically fails in parallel builds
-
Key: MNG-5315
URL: https://jira.codehaus.org/browse/MNG-5315
Project: Maven 2 3
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.0.4
Reporter: Ivan S. Dubrov
Assignee: Jason van Zyl
Priority: Minor
Fix For: Issues to be reviewed for 4.x
Attachments: MNG-5315-3.0.x.patch, MNG-5315-3.1.2-SNAPSHOT.patch
Artifact resolution can fail during the parallel build if it was downloaded
during the same session.
Scenario:
1) Delete the whole Maven local repository.
2) Run build mvn compile -T1.5C
3) Build fails (see log extracts below)
4) If I run build again, it succeeds.
It seems like the problem is due to two thread trying to resolve same
artifact concurrently. This problem never happens once I have all
dependencies cached in the local repository.
Extracts from the log output:
{noformat}Downloading:
http://nexus/content/repositories/thirdparty/com/googlecode/guava-osgi/guava-osgi/11.0.0/guava-osgi-11.0.0.jar
12444/13937 KB ...
...
[DEBUG] Skipped remote update check for commons-cli:commons-cli:jar:1.2,
already updated during this session.
[DEBUG] Skipped remote update check for
com.googlecode.guava-osgi:guava-osgi:jar:11.0.0, already updated during this
session.
[DEBUG] Skipped remote update check for org.slf4j:slf4j-api:jar:1.6.4,
already updated during this session.
[DEBUG] Skipped remote update check for org.slf4j:slf4j-jdk14:jar:1.6.4,
already updated during this session.
...
[ERROR] Failed to execute goal on project util: Could not resolve
dependencies for project com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The
following artifacts could not be resolved: commons-cli:commons-cli:jar:1.2,
com.googlecode.guava-osgi:guava-osgi:jar:11.0.0,
org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to
find commons-cli:commons-cli:jar:1.2 in
http://nexus/content/repositories/thirdparty was cached in the local
repository, resolution will not be reattempted until the update interval of
gw.thirdparty has elapsed or updates are forced - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal on project util: Could not resolve dependencies for project
com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The following artifacts could not
be resolved: commons-cli:commons-cli:jar:1.2,
com.googlecode.guava-osgi:guava-osgi:jar:11.0.0,
org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to
find commons-cli:commons-cli:jar:1.2 in
http://nexus/content/repositories/thirdparty was cached in the local
repository, resolution will not be reattempted until the update interval of
gw.thirdparty has elapsed or updates are forced
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210)
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117)
at
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.apache.maven.project.DependencyResolutionException: Could not
resolve dependencies for project com.guidewire.pl:util:bundle:1.0-SNAPSHOT:
The
[jira] (MNG-5309) InputLocation missing for Xpp3Dom configuration elements
[ https://jira.codehaus.org/browse/MNG-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5309: --- Fix Version/s: Issues to be reviewed for 4.x InputLocation missing for Xpp3Dom configuration elements Key: MNG-5309 URL: https://jira.codehaus.org/browse/MNG-5309 Project: Maven 2 3 Issue Type: Bug Components: Embedding, IDEs, Inheritance and Interpolation, POM Affects Versions: 3.0.4 Reporter: Milos Kleint Assignee: Milos Kleint Fix For: Issues to be reviewed for 4.x Attachments: 2012-07-06_1548.png, mng_configuration.patch I'm trying to create a view over a pom.xml file that displays current effective pom, along with showing which line came from which pom. Works more or less ok, with the provided InputLocations with one significant exception. configuration element in plugin. See screenshot. The idea in the patch is to have the InputLocation tree mimic the tree of Xpp3Dom objects. All the merges of Xpp3Dom then manipulate the tree of InputLocations as well. The patch included is not complete, just proof of concept, needs to have proper InputLocation creating in Xpp3DomMavenReaderExt file (I've replaced that by some quick post processing, changing modello plugins to generate something else is error prone slow to to start with). Additionally the default Xpp3Dom merging from plexus-utils is replaced by maven's own version of merge code. Not sure there if it's possible/practical to move that code down to the dependency. also some additional tests are required to be written -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5273) Transitive dependencies with scope provided ending up in the final artifact
[
https://jira.codehaus.org/browse/MNG-5273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339927#comment-339927
]
Jason van Zyl commented on MNG-5273:
Please read
https://cwiki.apache.org/confluence/display/MAVEN/Submitting+Issue+for+Maven%27s+Core
Transitive dependencies with scope provided ending up in the final artifact
---
Key: MNG-5273
URL: https://jira.codehaus.org/browse/MNG-5273
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.0.3, 3.0.4
Environment: Windows 7, Sun OS 5.1
Reporter: Ian Phipps
Marking jaxws-rt as a provided dependency:
{noformat}dependency
groupIdcom.sun.xml.ws/groupId
artifactIdjaxws-rt/artifactId
version2.1.4/version
scopeprovided/scope
/dependency{noformat}
Correctly resolves jaxb-impl as a provided dependency (dependency:tree output
from 3.0.3 and 3.0.4):
{noformat}[INFO] +- com.sun.xml.ws:jaxws-rt:jar:2.1.4:provided
[INFO] | +- com.sun.xml.bind:jaxb-impl:jar:2.1.7:provided
[INFO] | +- com.sun.xml.stream.buffer:streambuffer:jar:0.7:provided
[INFO] | +- com.sun.xml.stream:sjsxp:jar:1.0.1:provided
[INFO] | +- org.jvnet.staxex:stax-ex:jar:1.2:provided
[INFO] | +- com.sun.org.apache.xml.internal:resolver:jar:20050927:provided
[INFO] | \- org.jvnet:mimepull:jar:1.2:provided {noformat}
But for some reason, in Maven 3 (tried 3.0.3 and 3.0.4), using a packaging
type of war, jaxb-impl-2.1.7 ends up in the final artifact.
It is correctly omitted from the final artifact in maven 2.x.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5265) enforce repository url verification for passing authz
[
https://jira.codehaus.org/browse/MNG-5265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339929#comment-339929
]
Jason van Zyl commented on MNG-5265:
Olivier, do you consider this to be closed now?
enforce repository url verification for passing authz
-
Key: MNG-5265
URL: https://jira.codehaus.org/browse/MNG-5265
Project: Maven 2 3
Issue Type: Improvement
Components: Settings
Affects Versions: 2.0.10, 2.2.1, 3.0.2, 3.0.3, 3.0.4
Reporter: Olivier Lamy
Fix For: 3.2
Related discussion: http://markmail.org/message/7pswshucxc7qwtef
in your settings you have:
{code}
server
usernameolamy/username
passwordreallycomplicatedpassword/password
idfoo.org/id
/server
{code}
During dependencies resolution, you get a pom with a repository.
{code}
repository
idfoo.org/id
urlhttp://yourpasswordwillbehacked.org//url
/repository
{code}
Idea id in settings must contains the target hostname.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5227) The 'optional' flag of a dependency should be manageable.
[
https://jira.codehaus.org/browse/MNG-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-5227.
--
Resolution: Incomplete
The 'optional' flag of a dependency should be manageable.
-
Key: MNG-5227
URL: https://jira.codehaus.org/browse/MNG-5227
Project: Maven 2 3
Issue Type: Wish
Components: Artifacts and Repositories
Affects Versions: 3.0.3
Reporter: Christian Schulte
Priority: Minor
{code}
dependencyManagement
dependencies
dependency
groupIdgroupId/groupId
artifactIdartifactId/artifactId
versionversion/version
optionalfalse/optional !-- Ignored by Maven 2 3 in dependency
management. --
/dependency
/dependencies
/dependencyManagement
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5199) Return back org.apache.maven.user-settings and org.apache.maven.global-settings properties
[
https://jira.codehaus.org/browse/MNG-5199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339932#comment-339932
]
Jason van Zyl commented on MNG-5199:
So this is primarily a deficiency in the way options are passed on spawned
execution environments. So if the -s parameter was passed on properly this
would not be an issue yes?
Return back org.apache.maven.user-settings and
org.apache.maven.global-settings properties
--
Key: MNG-5199
URL: https://jira.codehaus.org/browse/MNG-5199
Project: Maven 2 3
Issue Type: New Feature
Components: Settings
Affects Versions: 3.0.3
Reporter: Karel Piwko
According to discussion at
http://maven.40175.n5.nabble.com/Maven-3-support-for-org-apache-maven-user-settings-td3261146.html,
I'm sure there is a valid use case for the property:
Imagine following:
{code}
mvn -s setting.xml test
{code}
Surefire has no way how to pass the path of the settings.xml in the spawned
process. If the test in spawned process want to for example access remote
repository defined in settings.xml, user has to specify settings.xml path in
the test itself.
However, for the following:
{code}
mvn -Dorg.apache.maven.user-settings=settings.xml test
{code}
This system property can be passed to surefire configuration and propagated
to the Surefire spawned process later on.
Having a system property removes duplication of the environment settings.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5194) Profile activation: Allow expressions in activation
[ https://jira.codehaus.org/browse/MNG-5194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339933#comment-339933 ] Jason van Zyl commented on MNG-5194: There will never be expressions in the POM like we have in Maven 1.x. Profile activation: Allow expressions in activation - Key: MNG-5194 URL: https://jira.codehaus.org/browse/MNG-5194 Project: Maven 2 3 Issue Type: Improvement Components: Profiles Affects Versions: 3.0.3 Reporter: Ondrej Zizka Current profile activation capabilities are insufficient. Makes using large projects harder, especially with complex testsuites. Having a possibility to have profiles activated by an expression would help a lot. activation expressionproperty1 == true || (property2 property3)/expression /activation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5194) Profile activation: Allow expressions in activation
[ https://jira.codehaus.org/browse/MNG-5194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5194. -- Resolution: Won't Fix Profile activation: Allow expressions in activation - Key: MNG-5194 URL: https://jira.codehaus.org/browse/MNG-5194 Project: Maven 2 3 Issue Type: Improvement Components: Profiles Affects Versions: 3.0.3 Reporter: Ondrej Zizka Current profile activation capabilities are insufficient. Makes using large projects harder, especially with complex testsuites. Having a possibility to have profiles activated by an expression would help a lot. activation expressionproperty1 == true || (property2 property3)/expression /activation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5105) disable/enable repositories in settings.xml does not work
[ https://jira.codehaus.org/browse/MNG-5105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5105. -- Resolution: Cannot Reproduce disable/enable repositories in settings.xml does not work - Key: MNG-5105 URL: https://jira.codehaus.org/browse/MNG-5105 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.0.3 Reporter: Jeremy Nguyen Xuan Assignee: Jason van Zyl With the following configuration, Maven will resolve SNAPSHOT dependencies from the first repository: repositories repository idpublic/id urlhttp://artifacts/content/groups/public/url releases enabledtrue/enabled /releases snapshots enabledfalse/enabled /snapshots /repository repository idallowed-snapshots/id urlhttp://artifacts/content/groups/allowed-snapshots//url snapshots enabledtrue/enabled /snapshots /repository /repositories The expected behavior would be Maven to resolve only release versions from the first repository, and snapshots versions from the second one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5087) Maven 3 dependency resolution fails until maven-metadata-local.xml files (created by maven-invoker-plugin) are deleted
[
https://jira.codehaus.org/browse/MNG-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-5087.
--
Resolution: Fixed
Maven 3 dependency resolution fails until maven-metadata-local.xml files
(created by maven-invoker-plugin) are deleted
--
Key: MNG-5087
URL: https://jira.codehaus.org/browse/MNG-5087
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies, Integration Tests
Affects Versions: 3.0.2, 3.0.3
Environment: Mac OS X 10.6.x, Java 1.6.0_24
Reporter: Chas Emerick
Assignee: Jason van Zyl
In one of my Maven projects, dependency resolution will succeed once, then
fail for later build attempts:
{code}
[WARNING] The POM for commons-logging:commons-logging:jar:1.1.1 is missing,
no dependency information available
[WARNING] The POM for commons-httpclient:commons-httpclient:jar:3.1 is
missing, no dependency information available
[WARNING] The POM for javax.mail:mail:jar:1.4.4 is missing, no dependency
information available
{code}
...and so on, until I delete the {{maven-metadata-local.xml}} files
corresponding to the failing artifacts (e.g.
{{~/.m2/repository/commons-logging/commons-logging/maven-metadata-local.xml}}),
which appear to be created by maven-invoker-plugin:install. After those
files are deleted, the next {{mvn}} invocation proceeds properly; the
metadata files are restored by that invocation (presumably as part of the
process of checking my upstream repositories/mirrors for updated artifacts),
and I am again presented with the above errors until I again delete the
metadata files.
This is repeatable, even after starting with a completely fresh local
repository. Note that Maven 2.2.1 does *NOT* exhibit this problem.
FYI, I'm not using an integration-testing-only local repo
[http://maven.apache.org/plugins/maven-invoker-plugin/install-mojo.html#localRepositoryPath|as
described here], simply because doing so causes the re-downloading of all
transitive dependencies
([http://maven.apache.org/plugins/maven-invoker-plugin/examples/fast-use.html|unless
you want to maintain an integration-specific settings.xml file!!!]). I've
used the invoker plugin with a variety of other projects in this way with
good results ([http://github.com/clojure/tools.nrepl|example]) -- certainly
never encountering a borked local repository in the process like this.
Here's an affected project:
[https://github.com/cemerick/rummage/tree/1.3.0-compat|the 1.3.0-compat
branch of rummage]. To reproduce, just clone that repo, checkout
{{1.3.0-compat}}, and:
{code}
mvn clean test
# no error -- can run this and other builds that don't involve
maven-invoker-plugin all day w/o problems
mvn clean integration-test
# FAIL: Could not resolve dependencies, with warnings as noted above
mvn clean test
# FAIL: Could not resolve dependencies, with warnings as noted above
{code}
Once the local repository is broken (by the generation of the
{{maven-metadata-local.xml}} files, AFAICT), no builds will get past the
dependency resolution stage.
Running mvn -X reveals lines like this for each artifact that is later
apparently not found:
{code}
[DEBUG] Verifying availability of
/Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.jar from []
{code}
Of course,
{{/Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.jar}} et al.
does exist, as does
{{/Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.pom}}.
I'm assuming this is a bug in Maven 3's core dependency resolution mechanisms
(as opposed to maven-invoker-plugin) since Maven 2.2.1 doesn't exhibit the
behaviour.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5087) Maven 3 dependency resolution fails until maven-metadata-local.xml files (created by maven-invoker-plugin) are deleted
[
https://jira.codehaus.org/browse/MNG-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339934#comment-339934
]
Jason van Zyl commented on MNG-5087:
Fixed with new version of Aether.
Maven 3 dependency resolution fails until maven-metadata-local.xml files
(created by maven-invoker-plugin) are deleted
--
Key: MNG-5087
URL: https://jira.codehaus.org/browse/MNG-5087
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies, Integration Tests
Affects Versions: 3.0.2, 3.0.3
Environment: Mac OS X 10.6.x, Java 1.6.0_24
Reporter: Chas Emerick
Assignee: Jason van Zyl
In one of my Maven projects, dependency resolution will succeed once, then
fail for later build attempts:
{code}
[WARNING] The POM for commons-logging:commons-logging:jar:1.1.1 is missing,
no dependency information available
[WARNING] The POM for commons-httpclient:commons-httpclient:jar:3.1 is
missing, no dependency information available
[WARNING] The POM for javax.mail:mail:jar:1.4.4 is missing, no dependency
information available
{code}
...and so on, until I delete the {{maven-metadata-local.xml}} files
corresponding to the failing artifacts (e.g.
{{~/.m2/repository/commons-logging/commons-logging/maven-metadata-local.xml}}),
which appear to be created by maven-invoker-plugin:install. After those
files are deleted, the next {{mvn}} invocation proceeds properly; the
metadata files are restored by that invocation (presumably as part of the
process of checking my upstream repositories/mirrors for updated artifacts),
and I am again presented with the above errors until I again delete the
metadata files.
This is repeatable, even after starting with a completely fresh local
repository. Note that Maven 2.2.1 does *NOT* exhibit this problem.
FYI, I'm not using an integration-testing-only local repo
[http://maven.apache.org/plugins/maven-invoker-plugin/install-mojo.html#localRepositoryPath|as
described here], simply because doing so causes the re-downloading of all
transitive dependencies
([http://maven.apache.org/plugins/maven-invoker-plugin/examples/fast-use.html|unless
you want to maintain an integration-specific settings.xml file!!!]). I've
used the invoker plugin with a variety of other projects in this way with
good results ([http://github.com/clojure/tools.nrepl|example]) -- certainly
never encountering a borked local repository in the process like this.
Here's an affected project:
[https://github.com/cemerick/rummage/tree/1.3.0-compat|the 1.3.0-compat
branch of rummage]. To reproduce, just clone that repo, checkout
{{1.3.0-compat}}, and:
{code}
mvn clean test
# no error -- can run this and other builds that don't involve
maven-invoker-plugin all day w/o problems
mvn clean integration-test
# FAIL: Could not resolve dependencies, with warnings as noted above
mvn clean test
# FAIL: Could not resolve dependencies, with warnings as noted above
{code}
Once the local repository is broken (by the generation of the
{{maven-metadata-local.xml}} files, AFAICT), no builds will get past the
dependency resolution stage.
Running mvn -X reveals lines like this for each artifact that is later
apparently not found:
{code}
[DEBUG] Verifying availability of
/Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.jar from []
{code}
Of course,
{{/Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.jar}} et al.
does exist, as does
{{/Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.pom}}.
I'm assuming this is a bug in Maven 3's core dependency resolution mechanisms
(as opposed to maven-invoker-plugin) since Maven 2.2.1 doesn't exhibit the
behaviour.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5042) Regression: CloningClassLoader causes StackOverflowError in groovy
[
https://jira.codehaus.org/browse/MNG-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339935#comment-339935
]
Jason van Zyl commented on MNG-5042:
Fixed in 3.1.0.
Regression: CloningClassLoader causes StackOverflowError in groovy
--
Key: MNG-5042
URL: https://jira.codehaus.org/browse/MNG-5042
Project: Maven 2 3
Issue Type: Bug
Components: Class Loading
Affects Versions: 3.0, 3.0.1, 3.0.2, 3.0.3
Reporter: Patrick Staton
Attachments: test-plug.zip
I am unable to use a groovy class as a plexus component in maven 3 because
groovy's metaclass mechanism calls Introspector.getBeanInfo() in constructors
which in turn calls classloader.loadClass(beanClass.getName() +
BEANINFO_SUFFIX) (the class name is FooBar$__plexus2) which in turn causes
CloningClassLoader to create a new clone of the class named
FooBar$__plexus2BeanInfo. When FooBar$__plexusBeanInfo is instantiated
groovy's the meta class mechanism again calls
Introspector.getBeanInfo() on FooBar$__plexus2.
Example stack trace:
{code}at
sis.buildtools.SisMapVersionsPhase.$getStaticMetaClass(VersionsMojo.groovy)
at sis.buildtools.SisMapVersionsPhase.init(VersionsMojo.groovy:692)
at
sis.buildtools.SisMapVersionsPhase$__plexus2BeanInfo.init(Unknown Source)
at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown
Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at java.beans.Introspector.instantiate(Introspector.java:1449)
at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:431)
at java.beans.Introspector.init(Introspector.java:380)
at java.beans.Introspector.getBeanInfo(Introspector.java:167)
at groovy.lang.MetaClassImpl$15.run(MetaClassImpl.java:2940)
at java.security.AccessController.doPrivileged(Native Method)
at groovy.lang.MetaClassImpl.addProperties(MetaClassImpl.java:2938)
at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:2921)
at
org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:166)
at
org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:182)
at
sis.buildtools.SisMapVersionsPhase.$getStaticMetaClass(VersionsMojo.groovy)
at sis.buildtools.SisMapVersionsPhase.init(VersionsMojo.groovy:692)
at
sis.buildtools.SisMapVersionsPhase$__plexus2BeanInfo.init(Unknown Source)
at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown
Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at java.beans.Introspector.instantiate(Introspector.java:1449)
at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:431)
at java.beans.Introspector.init(Introspector.java:380)
at java.beans.Introspector.getBeanInfo(Introspector.java:167)
at groovy.lang.MetaClassImpl$15.run(MetaClassImpl.java:2940)
at java.security.AccessController.doPrivileged(Native Method)
at groovy.lang.MetaClassImpl.addProperties(MetaClassImpl.java:2938)
at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:2921)
at
org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:166)
at
org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:182)
at
sis.buildtools.SisMapVersionsPhase.$getStaticMetaClass(VersionsMojo.groovy)
at sis.buildtools.SisMapVersionsPhase.init(VersionsMojo.groovy:692)
at
sis.buildtools.SisMapVersionsPhase$__plexus2BeanInfo.init(Unknown Source)
at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown
Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at java.beans.Introspector.instantiate(Introspector.java:1449)
at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:431)
at java.beans.Introspector.init(Introspector.java:380)
at
[jira] (MNG-5042) Regression: CloningClassLoader causes StackOverflowError in groovy
[
https://jira.codehaus.org/browse/MNG-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-5042.
--
Resolution: Fixed
Regression: CloningClassLoader causes StackOverflowError in groovy
--
Key: MNG-5042
URL: https://jira.codehaus.org/browse/MNG-5042
Project: Maven 2 3
Issue Type: Bug
Components: Class Loading
Affects Versions: 3.0, 3.0.1, 3.0.2, 3.0.3
Reporter: Patrick Staton
Attachments: test-plug.zip
I am unable to use a groovy class as a plexus component in maven 3 because
groovy's metaclass mechanism calls Introspector.getBeanInfo() in constructors
which in turn calls classloader.loadClass(beanClass.getName() +
BEANINFO_SUFFIX) (the class name is FooBar$__plexus2) which in turn causes
CloningClassLoader to create a new clone of the class named
FooBar$__plexus2BeanInfo. When FooBar$__plexusBeanInfo is instantiated
groovy's the meta class mechanism again calls
Introspector.getBeanInfo() on FooBar$__plexus2.
Example stack trace:
{code}at
sis.buildtools.SisMapVersionsPhase.$getStaticMetaClass(VersionsMojo.groovy)
at sis.buildtools.SisMapVersionsPhase.init(VersionsMojo.groovy:692)
at
sis.buildtools.SisMapVersionsPhase$__plexus2BeanInfo.init(Unknown Source)
at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown
Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at java.beans.Introspector.instantiate(Introspector.java:1449)
at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:431)
at java.beans.Introspector.init(Introspector.java:380)
at java.beans.Introspector.getBeanInfo(Introspector.java:167)
at groovy.lang.MetaClassImpl$15.run(MetaClassImpl.java:2940)
at java.security.AccessController.doPrivileged(Native Method)
at groovy.lang.MetaClassImpl.addProperties(MetaClassImpl.java:2938)
at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:2921)
at
org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:166)
at
org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:182)
at
sis.buildtools.SisMapVersionsPhase.$getStaticMetaClass(VersionsMojo.groovy)
at sis.buildtools.SisMapVersionsPhase.init(VersionsMojo.groovy:692)
at
sis.buildtools.SisMapVersionsPhase$__plexus2BeanInfo.init(Unknown Source)
at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown
Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at java.beans.Introspector.instantiate(Introspector.java:1449)
at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:431)
at java.beans.Introspector.init(Introspector.java:380)
at java.beans.Introspector.getBeanInfo(Introspector.java:167)
at groovy.lang.MetaClassImpl$15.run(MetaClassImpl.java:2940)
at java.security.AccessController.doPrivileged(Native Method)
at groovy.lang.MetaClassImpl.addProperties(MetaClassImpl.java:2938)
at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:2921)
at
org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:166)
at
org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:182)
at
sis.buildtools.SisMapVersionsPhase.$getStaticMetaClass(VersionsMojo.groovy)
at sis.buildtools.SisMapVersionsPhase.init(VersionsMojo.groovy:692)
at
sis.buildtools.SisMapVersionsPhase$__plexus2BeanInfo.init(Unknown Source)
at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown
Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at java.beans.Introspector.instantiate(Introspector.java:1449)
at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:431)
at java.beans.Introspector.init(Introspector.java:380)
at java.beans.Introspector.getBeanInfo(Introspector.java:167)
at
[jira] (MNG-4999) Maven should fail the build or give a warning when there are cyclic dependencies
[ https://jira.codehaus.org/browse/MNG-4999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339936#comment-339936 ] Jason van Zyl commented on MNG-4999: And for weird situations you can use the enforcer plugin. Maven should fail the build or give a warning when there are cyclic dependencies Key: MNG-4999 URL: https://jira.codehaus.org/browse/MNG-4999 Project: Maven 2 3 Issue Type: Bug Components: POM Affects Versions: 2.2.1, 3.0.2 Environment: any Reporter: Phillip Hellewell Maven gives no warning or error when there are cyclic dependencies. It should give at least a warning, and have the ability to fail the build through an option. How to reproduce: 1. Make B that doesn't depend on anything. Deploy a snapshot of B. 2. Make A that depends on the snapshot of B . Deploy a snapshot of A. 3. Change B to depend on the snapshot of A. Now deploy a new snapshot of B (same version as in step 1). I would venture to say that the perc. of people who actually want to allow cycles is smaller than the percentage who want to catch it as an error. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4999) Maven should fail the build or give a warning when there are cyclic dependencies
[ https://jira.codehaus.org/browse/MNG-4999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-4999. -- Resolution: Cannot Reproduce Maven should fail the build or give a warning when there are cyclic dependencies Key: MNG-4999 URL: https://jira.codehaus.org/browse/MNG-4999 Project: Maven 2 3 Issue Type: Bug Components: POM Affects Versions: 2.2.1, 3.0.2 Environment: any Reporter: Phillip Hellewell Maven gives no warning or error when there are cyclic dependencies. It should give at least a warning, and have the ability to fail the build through an option. How to reproduce: 1. Make B that doesn't depend on anything. Deploy a snapshot of B. 2. Make A that depends on the snapshot of B . Deploy a snapshot of A. 3. Change B to depend on the snapshot of A. Now deploy a new snapshot of B (same version as in step 1). I would venture to say that the perc. of people who actually want to allow cycles is smaller than the percentage who want to catch it as an error. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5431) Support include scope
[ https://jira.codehaus.org/browse/MNG-5431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339937#comment-339937 ] Matthew Adams commented on MNG-5431: Ok, I'm now following https://jira.codehaus.org/browse/MNG-5437. Support include scope --- Key: MNG-5431 URL: https://jira.codehaus.org/browse/MNG-5431 Project: Maven 2 3 Issue Type: Improvement Components: Dependencies, Inheritance and Interpolation, POM Affects Versions: 3.0.4, 3.1.x Reporter: Matthew Adams Attachments: included-pom.xml, including-pom.xml I'd like to request an improvement over the current pom import support. The current import support only goes so far as adding dependencies to the dependencyManagement section of a pom. The importing pom still is left to add those dependencies to its own dependencies, which is inconvenient, especially for imported poms that define many dependencies. Instead, I propose the addition of a new scope called include that can be used to add the imported pom's dependencies section to the importing pom's dependencies section. A pom that wants to include another pom, then, would simply declare the dependency on the included pom's groupId:artifactId:version, but use a scope of include, which would imply type pom. The important thing to realize is that this could be done in the dependencies section of the including pom (not necessarily dependencyManagementdependencies). For example, in the including pom's dependencies (at XPath project/dependencies, not project/dependencyManagement/dependencies): dependency groupIdme.matthewadams/groupId artifactIddatanucleus-rdbms/artifactId scopeinclude/scope !-- NEW! different from import! -- version3.1.4/version /dependency The scope include implies typepom/type; declaring it explicitly would be ok, but declaring any other type would be an error. See the two poms attached to this request for a more thorough example. Also, see user list discussion at http://maven.40175.n5.nabble.com/New-Maven-idea-include-import-tp5745916.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4996) Maven3 parallel build fails occasionally for classpath problems.
[
https://jira.codehaus.org/browse/MNG-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-4996.
--
Resolution: Cannot Reproduce
Maven3 parallel build fails occasionally for classpath problems.
Key: MNG-4996
URL: https://jira.codehaus.org/browse/MNG-4996
Project: Maven 2 3
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 3.0.1
Environment: maven 3.0.1, maven 3.0
Reporter: Kari J. Niemi
Assignee: Kristian Rosenvold
In a multimodule (120 modules) maven build, the compiler plug-in would seem
to fail in creating a correct class-path every now and then.
Instead of this entry in maven -X logs for a single module build:
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
configurator --
..
[DEBUG] (f) classpathElements =
[/home/karniemi/mymodulepath/target/classes,
/home/karniemi/.m2/repository/org/apache/servicemix/servicemix-utils/1.2.0/servicemix-utils-1.2.0.jar,
/home/karniemi/.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,
/home/karniemi/.m2/repository/org/codehaus/woodstox/wstx-asl/3.2.6/wstx-asl-3.2.6.jar,
/home/karniemi/.m2/repository/org/apache/servicemix/specs/org.apache.servicemix.specs.jbi-api-1.0/1.4.0/org.apache.servicemix.specs.jbi-api-1.0-1.4.0.jar,
/home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-activation_1.1_spec/1.0.2/geronimo-activation_1.1_spec-1.0.2.jar,
/home/karniemi/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar]
every now and then I get this in the parallel build:
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
configurator --
...
[DEBUG] (f) classpathElements =
[/home/karniemi/mymodulepath/target/classes]
And of course the compilation fails because none of the dependencies are
added to the classpath. Sometimes it goes fine in the multi-module build, but
every now and then it fails for this.
In both maven runs I can see that the dependencies are resolved fine:
--
[DEBUG] mymodule:jar:DYNAMIC-SNAPSHOT
[DEBUG]junit:junit:jar:4.7:test
[DEBUG]org.apache.servicemix:servicemix-utils:jar:1.2.0:provided
[DEBUG]
org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:provided
[DEBUG] org.codehaus.woodstox:wstx-asl:jar:3.2.6:provided
[DEBUG]
org.apache.servicemix.specs:org.apache.servicemix.specs.jbi-api-1.0:jar:1.4.0:provided
(scope managed from compile) (version managed from 1.1.0)
[DEBUG]
org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:provided
[DEBUG]log4j:log4j:jar:1.2.14:provided
---
The pluginArtifactMap looks like this:
[DEBUG] (s) pluginArtifactMap =
{org.apache.maven.plugins:maven-surefire-plugin=org.apache.maven.plugins:maven-surefire-plugin:maven-plugin:2.6:,
org.apache.maven.surefire:surefire-booter=org.apache.maven.surefire:surefire-booter:jar:2.6:compile,
org.apache.maven.surefire:surefire-api=org.apache.maven.surefire:surefire-api:jar:2.6:compile,
org.apache.maven.surefire:maven-surefire-common=org.apache.maven.surefire:maven-surefire-common:jar:2.6:compile,
org.apache.maven.shared:maven-common-artifact-filters=org.apache.maven.shared:maven-common-artifact-filters:jar:1.2:compile,
org.codehaus.plexus:plexus-utils=org.codehaus.plexus:plexus-utils:jar:2.0.5:compile,
junit:junit=junit:junit:jar:3.8.1:compile,
org.apache.maven.reporting:maven-reporting-api=org.apache.maven.reporting:maven-reporting-api:jar:2.0.9:compile}
I'm really using jbi-maven-plugin for most of the modules, and that plugin
binds the other plugins -also the compiler-plugin -to maven life-cycle phases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4706) Multithreaded building can create bad files for downloaded artifacts in local repository
[ https://jira.codehaus.org/browse/MNG-4706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-4706: --- Fix Version/s: (was: Issues to be reviewed for 3.x) Issues to be reviewed for 4.x Multithreaded building can create bad files for downloaded artifacts in local repository Key: MNG-4706 URL: https://jira.codehaus.org/browse/MNG-4706 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.0-beta-1 Reporter: Kristian Rosenvold Assignee: Kristian Rosenvold Fix For: Issues to be reviewed for 4.x Within a parallel build, modules A and B can start at the same time and decide at the same time that they need to download artifact X. Since X is not available locally, both can start download of X. Both will download X and both will try to write the file for X to disk. On Windows platforms, one of them can fail with file locking problems. On Unixes the contents of the written file can be non-deterministic. This issue is related to MNG-2802 in the sense that it can create a corrupted artifact file in the local repository, and it can happen to ANY file written. But as opposed to MNG-2802 the synhronization needed to fix this issue is basically only within a single running maven process, so regular java mechanisms can apply, whereas MNG-2802 probably needs to use a totally different solution space. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4633) Make weave mode work reliably
[ https://jira.codehaus.org/browse/MNG-4633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339939#comment-339939 ] Jason van Zyl commented on MNG-4633: Kristian, feel free to reopen if you're going to work on it. But after looking at these modes as well I only think this mode would reward poorly modularized builds. The only time this might help is if you have a critical path where you just can't go any further, but you really can't do a whole lot in the next builds until the critical path finishes. This code is also super complicated. Make weave mode work reliably - Key: MNG-4633 URL: https://jira.codehaus.org/browse/MNG-4633 Project: Maven 2 3 Issue Type: Improvement Affects Versions: 3.0-beta-1 Reporter: Kristian Rosenvold Assignee: Kristian Rosenvold Fix For: 3.x / Backlog m3 trunk currently contains two different concurrent-build implementations; parallel and weave. The main target for m3 is for production quality parallel to be ready; there are numerous plugins that will need to adjust to this functionality. Alongside this activity weave mode will also be fine-tuned and evaluated; due to the generally tighter concurrency in this model, weave mode is more likely to reveal concurrency related issues in both maven, plugins, libraries and the jdk. This task is used to collect all commits related to making weave mode work reliably. The final evaluation of weave mode will be taken at a later stage. In the event that Weave mode is to be abandoned, the class LifecycleWeaveBuilder contains instructions on how/what can be removed from m3 core. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4631) Add integration tests of parallel build features
[ https://jira.codehaus.org/browse/MNG-4631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-4631: --- Fix Version/s: (was: Issues to be reviewed for 3.x) Issues to be reviewed for 4.x Add integration tests of parallel build features Key: MNG-4631 URL: https://jira.codehaus.org/browse/MNG-4631 Project: Maven 2 3 Issue Type: Test Affects Versions: 3.0-beta-2 Reporter: Kristian Rosenvold Assignee: Kristian Rosenvold Fix For: Issues to be reviewed for 4.x While some of the features are unit tested and there are some IT's on mng-3004, there needs to be integration test to cover: A) Concurrent mojo instantiations with model expression resolutions, including most parameter type from PluginParameterExpressionEvaluator. This test is important to assert/preserve future thread safety of this process, since most of this assertion has been done manually to this point. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4631) Add integration tests of parallel build features
[ https://jira.codehaus.org/browse/MNG-4631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339940#comment-339940 ] Jason van Zyl commented on MNG-4631: This is definitely critical for the addition of the aggressive parallel mode. Add integration tests of parallel build features Key: MNG-4631 URL: https://jira.codehaus.org/browse/MNG-4631 Project: Maven 2 3 Issue Type: Test Affects Versions: 3.0-beta-2 Reporter: Kristian Rosenvold Assignee: Kristian Rosenvold Fix For: Issues to be reviewed for 4.x While some of the features are unit tested and there are some IT's on mng-3004, there needs to be integration test to cover: A) Concurrent mojo instantiations with model expression resolutions, including most parameter type from PluginParameterExpressionEvaluator. This test is important to assert/preserve future thread safety of this process, since most of this assertion has been done manually to this point. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4633) Make weave mode work reliably
[ https://jira.codehaus.org/browse/MNG-4633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-4633. -- Resolution: Won't Fix Make weave mode work reliably - Key: MNG-4633 URL: https://jira.codehaus.org/browse/MNG-4633 Project: Maven 2 3 Issue Type: Improvement Affects Versions: 3.0-beta-1 Reporter: Kristian Rosenvold Assignee: Kristian Rosenvold Fix For: 3.x / Backlog m3 trunk currently contains two different concurrent-build implementations; parallel and weave. The main target for m3 is for production quality parallel to be ready; there are numerous plugins that will need to adjust to this functionality. Alongside this activity weave mode will also be fine-tuned and evaluated; due to the generally tighter concurrency in this model, weave mode is more likely to reveal concurrency related issues in both maven, plugins, libraries and the jdk. This task is used to collect all commits related to making weave mode work reliably. The final evaluation of weave mode will be taken at a later stage. In the event that Weave mode is to be abandoned, the class LifecycleWeaveBuilder contains instructions on how/what can be removed from m3 core. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4622) Throw Validation Error if pom contains a dependency with two different versions.
[ https://jira.codehaus.org/browse/MNG-4622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339941#comment-339941 ] Jason van Zyl commented on MNG-4622: This is not necessarily and error and this behaviour has existed for so long I would be loathe to turn it on. Throw Validation Error if pom contains a dependency with two different versions. Key: MNG-4622 URL: https://jira.codehaus.org/browse/MNG-4622 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Shane Isbell Fix For: Issues to be reviewed for 4.x Throw a validation error if a pom contains the same dependency with two different versions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4622) Throw Validation Error if pom contains a dependency with two different versions.
[ https://jira.codehaus.org/browse/MNG-4622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-4622. -- Resolution: Won't Fix Throw Validation Error if pom contains a dependency with two different versions. Key: MNG-4622 URL: https://jira.codehaus.org/browse/MNG-4622 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Shane Isbell Fix For: Issues to be reviewed for 4.x Throw a validation error if a pom contains the same dependency with two different versions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4188) Add a 'finally' phase.
[
https://jira.codehaus.org/browse/MNG-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339942#comment-339942
]
Jason van Zyl commented on MNG-4188:
We effectively have this now with
AbstractMavenLifecycleParticipant#afterSessionEnd but I think we need to clean
this up as part of 4.0.0
Add a 'finally' phase.
--
Key: MNG-4188
URL: https://jira.codehaus.org/browse/MNG-4188
Project: Maven 2 3
Issue Type: Wish
Components: Plugins and Lifecycle
Affects Versions: Issues to be reviewed for 3.x
Reporter: Christian Schulte
Priority: Minor
Fix For: Issues to be reviewed for 3.x
When Maven executes a lifecycle, it does not execute any phases succeeding a
failing phase. It would be great if Maven supports a 'finally' phase, which
is guaranteed to run regardless of the state of the lifecycle just like a
Java 'finally' block. The use case I would need such a phase for is the
following:
{code}
profile
idsourceforge-shell/id
activation
activeByDefaultfalse/activeByDefault
/activation
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
dependencies
dependency
groupIdorg.apache.ant/groupId
artifactIdant-jsch/artifactId
version1.7.1/version
/dependency
/dependencies
executions
execution
idcreate-sourceforge-shell/id
phasevalidate/phase
goals
goalrun/goal
/goals
configuration
tasks
sshexec host=shell.sourceforge.net
username=${sf.username},${sf.project} password=${sf.password}
command=create timeout=30 /
/tasks
/configuration
/execution
execution
idcreate-sourceforge-shell-site/id
phasepre-site/phase
goals
goalrun/goal
/goals
configuration
tasks
sshexec host=shell.sourceforge.net
username=${sf.username},${sf.project} password=${sf.password}
command=create timeout=30 /
/tasks
/configuration
/execution
execution
idshutdown-sourceforge-shell/id
phasedeploy/phase
goals
goalrun/goal
/goals
configuration
tasks
sshexec host=shell.sourceforge.net
username=${sf.username},${sf.project} password=${sf.password}
command=shutdown timeout=30 /
echo message=Sleeping for 1 minute waiting for shutdown
of shell. /
sleep minutes=1 /
/tasks
/configuration
/execution
execution
idshutdown-sourceforge-shell-site/id
phasesite-deploy/phase
goals
goalrun/goal
/goals
configuration
tasks
sshexec host=shell.sourceforge.net
username=${sf.username},${sf.project} password=${sf.password}
command=shutdown timeout=30 /
echo message=Sleeping for 1 minute waiting for shutdown
of shell. /
sleep minutes=1 /
/tasks
/configuration
/execution
/executions
/plugin
/plugins
/build
/profile
{code}
I am currently using this profile when deploying to sourceforge. The problem
is, that the shell won't get shutdown, whenever a build fails. It needs to
get shutdown, so that a build for another SF project can succeed. In the
example above, the two executions 'shutdown-sourceforge-shell' and
'shutdown-sourceforge-shell-site' could be bound to a 'finally' phase and
could shutdown the shell regardless of the outcome of the build.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3959) Per-execution inherited flag ignored
[
https://jira.codehaus.org/browse/MNG-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-3959.
--
Resolution: Not A Bug
Per-execution inherited flag ignored
Key: MNG-3959
URL: https://jira.codehaus.org/browse/MNG-3959
Project: Maven 2 3
Issue Type: Bug
Components: Inheritance and Interpolation
Reporter: Dave Syer
Fix For: Issues to be reviewed for 3.x
Per-execution inherited flag ignored. E.g.
{code}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
idtest/id
phaseinitialize/phase
inheritedfalse/inherited
...
{code}
If you move the inherited element up to the plugin level it works, but then
that applies to all executions, which isn't what is needed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
