[jira] Updated: (MNG-2580) UNC in MAVEN_HOME not working
[ http://jira.codehaus.org/browse/MNG-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenney Westerhof updated MNG-2580: -- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.x UNC in MAVEN_HOME not working - Key: MNG-2580 URL: http://jira.codehaus.org/browse/MNG-2580 Project: Maven 2 Issue Type: Bug Components: Command Line Affects Versions: 2.0.4 Environment: Windows XP Reporter: Remy COQUEUGNIOT Priority: Blocker Fix For: 2.0.x Maven2 is installed in a corporate server : SERVER From my computer, this installation is accesible on a network share : \\SERVER\MAVEN2 From a command line I setup MAVEN_HOME with this UNC: set MAVEN_HOME=\\SERVER\MAVEN2 And put it in the PATH set PATH=%MAVEN_HOME%\bin;%PATH% When I try to build any projects, maven is unable to acces my global settings which is stored in %MAVEN_HOME%\conf\settings.xml But when I mount a network share to this UNC: net use Z: \\SERVER\MAVEN2 ...Setup MAVEN_HOME ... set MAVEN_HOME=Z:\ ...And put it in the PATH ... set PATH=%MAVEN_HOME%\bin;%PATH% The global settings.xml is read. This useCase seems OK with Maven 1. mvn -X doesn't give too any informations about the final %MAVEN_HOME%\conf which is used. But it prints the plugin-registry.xml locations which are based on the %MAVEN_HOME% In this case \\SERVER\MAVEN2 is badly transformed in C:\SERVER\MAVEN2 : set MAVEN_HOME=\\frmlefsi20\inet_dev\DEVPLATFORM\maven-2.0.4 mvn clean -X (...) [DEBUG] Building Maven global-level plugin registry from: 'C:\frmlefsi20\inet_dev\DEVPLATFORM\maven-2.0.4\bin\..\conf\plugin-registry.xml' (...) Thanks for your support and this great tool ! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3001) Maven2 does not resolve version ranges correctly [PATCH INCLUDED]
[ http://jira.codehaus.org/browse/MNG-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99664 ] Kenney Westerhof commented on MNG-3001: --- I think the specificiation is wrong. [1.0,) should resolve to 1.0, 1.0.1-SNAPSHOT, 1.1-SNAPSHOT, 1.1 and higher (but not 1.0-SNAPSHOT). Wheter snapshots are included in resolution shouldn't be specified in the version range, but wheter a snapshot repository is declared or not. [1.0,) is a minimum version requirement, so this states that any version higher than or equal to 1.0 should work. [1.0,) cannot resolve to 1.0-SNAPSHOT. I added 2 tests in trunk to verify that. Maven2 does not resolve version ranges correctly [PATCH INCLUDED] - Key: MNG-3001 URL: http://jira.codehaus.org/browse/MNG-3001 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.4, 2.0.6 Environment: Windows. Affects versions 2.04 2.06 minimum. Reporter: David Hoffer Assignee: Jason van Zyl Priority: Blocker Fix For: Reviewed Pending Version Assignment Attachments: VersionRangeSnapshotFix.patch Maven does not properly handle version ranges when the high end is unbounded. The spec clearly states that it should not resolve to a SNAPSHOT unless included as an explicit boundary. Currently maven2 does resolve to a SNAPSHOT which makes usage of version ranges to control versions of dependencies unworkable. (We currently use a local build of maven with this fix else we could not use version ranges. This is a major issue can you please include in the next release?) Code fix and unit tests are included. Example: dependency groupIdmyGroup/groupId artifactIdmyArtifact/artifactId version[1.0,)/version /dependency This version range can resolve to the latest development 1.0-SNAPSHOT. All artifact dependencies should ignore SNAPSHOTS as that is not intended by the unbounded high end of the version range. This should resolve to any released version of 1.1 or higher. This document: http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges addressed the requirements for version ranges and stated that Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary. I think this requirement was forgotten when version ranges were implemented. I have included a patch for this bug. The fix is in the containsVersion method of VersionRange. I have added tests in VersionRangeTest and DefaultArtifactCollectorTest. All tests in maven pass with this fix. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-78) Dependencies listed as version ${project.version} in maven-archetype prevent the use of archetypes
[
http://jira.codehaus.org/browse/ARCHETYPE-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99666
]
Kenney Westerhof commented on ARCHETYPE-78:
---
This is caused by the fact that -Dversion=0.1 is provided on the commandline.
The archetype poms specify ${project.version}.
RegexBasedModelInterpolator strips off the leading project. (or pom. or env.)
and checks the context object for 'version', which it contains since -Dversion
was specified.
So in this case 0.1 is used for dependencies.
this will break with ALL maven builds that have a ${project.version} somewhere
and -Dversion is specified.
Dependencies listed as version ${project.version} in maven-archetype prevent
the use of archetypes
--
Key: ARCHETYPE-78
URL: http://jira.codehaus.org/browse/ARCHETYPE-78
Project: Maven Archetype
Issue Type: Bug
Affects Versions: 1.0-alpha-4
Reporter: Wayne Fay
Priority: Critical
Dependencies are listed as ${project.version} in deployed POM.
dependencyManagement
dependencies
dependency
groupIdorg.apache.maven.archetype/groupId
artifactIdmaven-archetype-model/artifactId
version${project.version}/version
/dependency
dependency
groupIdorg.apache.maven.archetype/groupId
artifactIdmaven-archetype-core/artifactId
version${project.version}/version
/dependency
dependency
groupIdorg.apache.maven.archetype/groupId
artifactIdmaven-archetype-creator/artifactId
version${project.version}/version
/dependency
/dependencies
/dependencyManagement
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2653) using ${version} for subproject dependencies doesn't work (maven uses 2.4.1 version instead)
[
http://jira.codehaus.org/browse/MNG-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99667
]
Kenney Westerhof commented on MNG-2653:
---
I'm tempted to 'close - won't fix'.
${version} is evaluated to either a system prop or a -Dversion=..., so this is
expected.
However, ${pom.version} _should_ be evaluated to the pom's version tag. But
that's a different issue alltogether.
using ${version} for subproject dependencies doesn't work (maven uses 2.4.1
version instead)
Key: MNG-2653
URL: http://jira.codehaus.org/browse/MNG-2653
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Environment: win xp, maven 2.0.1, eclipse plugin 0.0.3, eclipse 3.1
Reporter: Michal Stochmialek
Assignee: Jason van Zyl
Fix For: Reviewed Pending Version Assignment
Attachments: mngeclipse20-trigger.jpg, mvn-multiproject.zip,
org.maven.ide.eclipse-MNGECLIPSE-20-patch.txt
My project is a ear multiproject. It has 5 modules, that have internal
dependencies. For example web module needs app and type modules.
I usually use following declaration for this kind of dependencies. Note that
I'm using ${version} in dependency. In result I'm requesting foo-type jar of
the same version as current project.
project
modelVersion4.0.0/modelVersion
parent
groupIdfoo/groupId
artifactIdfoo/artifactId
version0.0.1-SNAPSHOT/version
/parent
artifactIdfoo-app/artifactId
dependencies
dependency
groupIdfoo/groupId
artifactIdfoo-type/artifactId
version${version}/version
/dependency
/dependencies
/project
This works from commandline, but doesn't work in eclipse plugin. I get
following message:
Unable to download the artifact from any repository foo:foo-type-2.4.1.jar
Maven (or maven plugin) tries to download foo-type module in very strange
version (instead 0.0.1-SNAPSHOT)!
I've attached simple multimodule project.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-2339) ${project.*} are interpreted in the wrong place
[
http://jira.codehaus.org/browse/MNG-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof reopened MNG-2339:
---
this is not fixed.
${project.*} are interpreted in the wrong place
---
Key: MNG-2339
URL: http://jira.codehaus.org/browse/MNG-2339
Project: Maven 2
Issue Type: Bug
Components: General
Affects Versions: 2.0.4
Reporter: Emmanuel Venisse
Assignee: Kenney Westerhof
Priority: Critical
Fix For: 2.0.6
If a plugin use ${project.version}, this parameter is interpreted with the
version of the current project and not the plugin version. I think we have
the same pb with dependencies and other ${project.*}
For a plugin in version 2.0 used in a project in version 1.0-SNAPSHOT,
${project.version} used in the plugin will be interpreted as 1.0-SNAPSHOT
instead of 2.0
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2339) ${project.*} are interpreted in the wrong place
[
http://jira.codehaus.org/browse/MNG-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof updated MNG-2339:
--
Fix Version/s: (was: 2.0.6)
2.0.8
${project.*} are interpreted in the wrong place
---
Key: MNG-2339
URL: http://jira.codehaus.org/browse/MNG-2339
Project: Maven 2
Issue Type: Bug
Components: General
Affects Versions: 2.0.4
Reporter: Emmanuel Venisse
Assignee: Kenney Westerhof
Priority: Critical
Fix For: 2.0.8
If a plugin use ${project.version}, this parameter is interpreted with the
version of the current project and not the plugin version. I think we have
the same pb with dependencies and other ${project.*}
For a plugin in version 2.0 used in a project in version 1.0-SNAPSHOT,
${project.version} used in the plugin will be interpreted as 1.0-SNAPSHOT
instead of 2.0
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (ARCHETYPE-78) Dependencies listed as version ${project.version} in maven-archetype prevent the use of archetypes
[
http://jira.codehaus.org/browse/ARCHETYPE-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof closed ARCHETYPE-78.
-
Resolution: Fixed
Fix Version/s: 1.0
Dupe of MNG-2339.
Fixed by removing ${project.version} in the poms and replacing it by the real
version string.
Dependencies listed as version ${project.version} in maven-archetype prevent
the use of archetypes
--
Key: ARCHETYPE-78
URL: http://jira.codehaus.org/browse/ARCHETYPE-78
Project: Maven Archetype
Issue Type: Bug
Affects Versions: 1.0-alpha-4
Reporter: Wayne Fay
Assignee: Kenney Westerhof
Priority: Critical
Fix For: 1.0
Dependencies are listed as ${project.version} in deployed POM.
dependencyManagement
dependencies
dependency
groupIdorg.apache.maven.archetype/groupId
artifactIdmaven-archetype-model/artifactId
version${project.version}/version
/dependency
dependency
groupIdorg.apache.maven.archetype/groupId
artifactIdmaven-archetype-core/artifactId
version${project.version}/version
/dependency
dependency
groupIdorg.apache.maven.archetype/groupId
artifactIdmaven-archetype-creator/artifactId
version${project.version}/version
/dependency
/dependencies
/dependencyManagement
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2651) POM interpolator treats ${pom.something} like ${something} and prefers system properties
[
http://jira.codehaus.org/browse/MNG-2651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof closed MNG-2651.
-
Resolution: Duplicate
POM interpolator treats ${pom.something} like ${something} and prefers system
properties
Key: MNG-2651
URL: http://jira.codehaus.org/browse/MNG-2651
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 2.0.4
Reporter: Daniel Schulz
Assignee: Kenney Westerhof
Fix For: Reviewed Pending Version Assignment
The POM interpolator (RegexBasedModelInterpolator) removes all leading
pom., project. and env. portions of an expression before evaluating it.
then searching for values happens in the following order: system properties,
project properties, pom bean properties.
An example: Although ${pom.version} is more specific than ${version}, version
wins. That's the problem in MNGECLIPSE-20.
IMHO the interpolation strategy should be changed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2653) using ${version} for subproject dependencies doesn't work (maven uses 2.4.1 version instead)
[
http://jira.codehaus.org/browse/MNG-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof closed MNG-2653.
-
Assignee: Kenney Westerhof (was: Jason van Zyl)
Resolution: Duplicate
using ${version} for subproject dependencies doesn't work (maven uses 2.4.1
version instead)
Key: MNG-2653
URL: http://jira.codehaus.org/browse/MNG-2653
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Environment: win xp, maven 2.0.1, eclipse plugin 0.0.3, eclipse 3.1
Reporter: Michal Stochmialek
Assignee: Kenney Westerhof
Fix For: Reviewed Pending Version Assignment
Attachments: mngeclipse20-trigger.jpg, mvn-multiproject.zip,
org.maven.ide.eclipse-MNGECLIPSE-20-patch.txt
My project is a ear multiproject. It has 5 modules, that have internal
dependencies. For example web module needs app and type modules.
I usually use following declaration for this kind of dependencies. Note that
I'm using ${version} in dependency. In result I'm requesting foo-type jar of
the same version as current project.
project
modelVersion4.0.0/modelVersion
parent
groupIdfoo/groupId
artifactIdfoo/artifactId
version0.0.1-SNAPSHOT/version
/parent
artifactIdfoo-app/artifactId
dependencies
dependency
groupIdfoo/groupId
artifactIdfoo-type/artifactId
version${version}/version
/dependency
/dependencies
/project
This works from commandline, but doesn't work in eclipse plugin. I get
following message:
Unable to download the artifact from any repository foo:foo-type-2.4.1.jar
Maven (or maven plugin) tries to download foo-type module in very strange
version (instead 0.0.1-SNAPSHOT)!
I've attached simple multimodule project.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2782) Version property in dependencies is not expanded correctly
[
http://jira.codehaus.org/browse/MNG-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof closed MNG-2782.
-
Resolution: Duplicate
Version property in dependencies is not expanded correctly
--
Key: MNG-2782
URL: http://jira.codehaus.org/browse/MNG-2782
Project: Maven 2
Issue Type: Bug
Components: Dependencies
Reporter: Carsten Ziegeler
Fix For: Reviewed Pending Version Assignment
The Spring poms, for example spring-beans, version 2.0.2 use the following
dependencies:
dependency
groupId${project.groupId}/groupId
artifactIdspring-core/artifactId
version${project.version}/version
/dependency
Which means, they are using variables in the poms. In some cases, these
variables are resolved correctly, but in some cases however they are not,
causing problems.
Imho, it would be better to resolve variables for released poms to avoid any
problems (or if variables are allowed, this is a maven bug then)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2796) Yet another snapshot/timestamp version resolution problem
[
http://jira.codehaus.org/browse/MNG-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof closed MNG-2796.
-
Resolution: Duplicate
Yet another snapshot/timestamp version resolution problem
-
Key: MNG-2796
URL: http://jira.codehaus.org/browse/MNG-2796
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories, Inheritance and Interpolation
Affects Versions: 2.0.4
Reporter: David Jencks
Fix For: Reviewed Pending Version Assignment
In the geronimo openejb3 integration we've encountered yet another problem
with broken version resolution. It would be great if the maven team could
fix these problems soon: I think that the geronimo and openejb developers
have now spent several weeks trying to understand bizarre version resolution
errors and trying to find workarounds for them.
Here's what we think the relevant project details are. Reproducing this
problem requires deploying snapshots at different revision numbers so I don't
really see how to provide a test project.
openejb project structure:
base openejb pom
openejb container pom, parent is openejb pom. Snapshot deployed with a
timestamped version 3.0-incubating-20070126.103431-21
openejb server pom, parent is openejb pom. Snapshot deployed with a
timestamped version 3.0-incubating-20070126.103431-20
server pom has a dependency on container pom, using this:
dependencies
dependency
groupIdorg.apache.openejb/groupId
artifactIdcontainer/artifactId
version${pom.version}/version
typepom/type
scopecompile/scope
/dependency
/dependencies
Subproject server/openejb-ejbd, parent pom is server.pom. Snapshot deployed
at 3.0-incubating-20070126.103431-20
Both container and server are pom-packaged projects, i.e. they have no code
of their own.
Openejb builds and deploys fine by itself, and the timestamped versions are
as indicated above.
geronimo-openejb module has a dependency
dependency
groupIdorg.apache.openejb/groupId
artifactIdopenejb-ejbd/artifactId
/dependency
whose version is supplied in an ancestor dependencyManagement section:
dependency
groupIdorg.apache.openejb/groupId
artifactIdopenejb-ejbd/artifactId
version${openejbVersion}/version
/dependency
where
openejbVersion3.0-incubating-SNAPSHOT/openejbVersion
When we build the geronimo-openejb module in geronimo the build breaks
because the incorrect version of openejb container is resolved:
This appears to be the relevant section of the -X trace, note that after the
incorrect non-resolution at -20 container is correctly resolved at -21 a few
lines later:
[DEBUG] openejb-client: resolved to version 3.0-incubating-20070126.103431-20
from repository apache.snapshots
[DEBUG] Retrieving parent-POM:
org.apache.openejb:server::3.0-incubating-SNAPSHOT for project:
null:openejb-client:jar:3.0-incubating-20070126.103431-20 from the repository.
[DEBUG] server: resolved to version 3.0-incubating-20070126.103431-20 from
repository apache.snapshots
[DEBUG] Retrieving parent-POM:
org.apache.openejb:openejb::3.0-incubating-SNAPSHOT for project:
null:server:pom:null from the repository.
[DEBUG] openejb: resolved to version 3.0-incubating-20070126.103431-22 from
repository apache.snapshots
[DEBUG] Retrieving parent-POM: org.apache:apache::3 for project:
org.apache.openejb:openejb:pom:3.0-incubating-SNAPSHOT from the repository.
[DEBUG]
org.apache.openejb:openejb-client:jar:3.0-incubating-SNAPSHOT:compile
(selected for compile)
[DEBUG] Retrieving parent-POM: org.apache.geronimo.specs:specs::1.2 for
project: null:geronimo-ejb_3.0_spec:jar:1.0-M1 from the repository.
[DEBUG] Retrieving parent-POM:
org.apache.geronimo.genesis.config:project-config::1.1 for project:
org.apache.geronimo.specs:specs:pom:1.2 from the repository.
[DEBUG] Retrieving parent-POM: org.apache.geronimo.genesis.config:config::1.1
for project: null:project-config:pom:null from the repository.
[DEBUG] Retrieving parent-POM: org.apache.geronimo.genesis:genesis::1.1 for
project: org.apache.geronimo.genesis.config:config:pom:null from the
repository.
[DEBUG] Retrieving parent-POM: org.apache:apache::3 for project:
org.apache.geronimo.genesis:genesis:pom:1.1 from the repository.
[DEBUG]
org.apache.geronimo.specs:geronimo-ejb_3.0_spec:jar:1.0-M1:compile (removed -
nearer found: 1.0)
[DEBUG] Artifact not found - using stub model: System is offline.
org.apache.openejb:container:pom:3.0-incubating-20070126.103431-20
[DEBUG] Using defaults for missing POM
org.apache.openejb:container:pom:3.0-incubating-SNAPSHOT:compile
[DEBUG]
[jira] Closed: (MNG-2647) Version not inherited for SNAPSHOT version
[
http://jira.codehaus.org/browse/MNG-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof closed MNG-2647.
-
Resolution: Duplicate
Version not inherited for SNAPSHOT version
--
Key: MNG-2647
URL: http://jira.codehaus.org/browse/MNG-2647
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation, POM
Affects Versions: 2.0.4
Environment: Windows 2000
Reporter: Stéphane Veyret
Fix For: Reviewed Pending Version Assignment
Attachments: module1.pom, parent.pom
I have the parent module which defines 2 modules. In the modules, the version
is inherited from the parent. If I am working on a SNAPSHOT version, the
child modules get the timestamp version instead of what was given to parent.
If you have a look at the attachements, the problem is that module1 version
in deployed pom will be something like 1234567.123456-7 and when searching
for dependent module2 version, will fail because it will try to download a
released version 1234567.123456-7 of module 2.
Only this seem to be a bug to me, but this is even stranger considering the
version of module2 is defined in dependecyManagement of parent pom with
${project.version}. This project.version is correct (3.4.0_SNAPSHOT) in
parent pom !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2339) ${project.*} are interpreted in the wrong place
[
http://jira.codehaus.org/browse/MNG-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99673
]
Kenney Westerhof commented on MNG-2339:
---
This issue deals with ${project.version}, or ${version}, or ${xxx.version} for
that matter, all being treated like ${version}.
commandline arguments like -Dversion=foo will have effect on the dependencies
or wherever one of the expressions above is used.
${project.version} and ${pom.version} should ALWAYS resolve to a version tag
in the pom.
RegexBasedModelInterpolator strips off the first part (project.) and then
checks the context for the value. This is wrong.
Issue MNG-2486 is different - that one deals with the fact that SNAPSHOT
version expressions, which are correctly interpolated from the pom and not from
external properties,
are evaluated to the timestamped version instead of the string present in the
model.
${project.*} are interpreted in the wrong place
---
Key: MNG-2339
URL: http://jira.codehaus.org/browse/MNG-2339
Project: Maven 2
Issue Type: Bug
Components: General
Affects Versions: 2.0.4
Reporter: Emmanuel Venisse
Assignee: Kenney Westerhof
Priority: Critical
Fix For: 2.0.8
If a plugin use ${project.version}, this parameter is interpreted with the
version of the current project and not the plugin version. I think we have
the same pb with dependencies and other ${project.*}
For a plugin in version 2.0 used in a project in version 1.0-SNAPSHOT,
${project.version} used in the plugin will be interpreted as 1.0-SNAPSHOT
instead of 2.0
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2486) ${project.version} evaluated to timestamped version if referring to SNAPSHOT
[
http://jira.codehaus.org/browse/MNG-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof updated MNG-2486:
--
Assignee: (was: Kenney Westerhof)
Affects Version/s: 2.1-alpha-1
2.0.7
2.0.5
2.0.6
Fix Version/s: (was: Reviewed Pending Version Assignment)
2.1-alpha-1
2.0.8
Issue Type: Bug (was: Improvement)
Summary: ${project.version} evaluated to timestamped version if
referring to SNAPSHOT (was: disallow use of ${project.version} in dependency
versions)
${project.version} evaluated to timestamped version if referring to SNAPSHOT
Key: MNG-2486
URL: http://jira.codehaus.org/browse/MNG-2486
Project: Maven 2
Issue Type: Bug
Components: Dependencies, Inheritance and Interpolation, POM
Affects Versions: 2.0.4, 2.0.5, 2.0.6, 2.0.7, 2.1-alpha-1
Reporter: John Casey
Priority: Critical
Fix For: 2.0.8, 2.1-alpha-1
when projects specify dependencyManagement sections with a shorthand version
notation using the current project version (using ${project.version}) the
version resolved will be that of the POM in which the dependencyManagement
section is specified. If this POM is a snapshot, these dependency
specifications will get the timestamp/buildnumber of that POM, instead of the
actual one used when the dependency it references gets deployed.
We should look at strategies for limiting or eliminating this practice, or
else (somehow) pulling the real timestamp/buildnumber for that artifact from
the reactor...in order to make these deps transitively resolvable for users.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2486) ${project.version} evaluated to timestamped version if referring to SNAPSHOT
[
http://jira.codehaus.org/browse/MNG-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99676
]
Kenney Westerhof commented on MNG-2486:
---
This issue deals with the fact that whenever ${project.version} or
${pom.version} is evaluated to a POM version tag (be it parent,
or project, present in a dependency or dependencyManagement or anywhere else in
the POM),
and that version is a SNAPSHOT version, then the timestamped version is used,
instead of the literal string.
This causes problems with multimodule builds that share versions but aren't
always deployed as a whole.
Even if they are deployed as a whole, this could cause problems since the
timestamps might not be the same for all artifacts.
${project.version} evaluated to timestamped version if referring to SNAPSHOT
Key: MNG-2486
URL: http://jira.codehaus.org/browse/MNG-2486
Project: Maven 2
Issue Type: Bug
Components: Dependencies, Inheritance and Interpolation, POM
Affects Versions: 2.0.4, 2.0.5, 2.0.6, 2.0.7, 2.1-alpha-1
Reporter: John Casey
Priority: Critical
Fix For: 2.0.8, 2.1-alpha-1
when projects specify dependencyManagement sections with a shorthand version
notation using the current project version (using ${project.version}) the
version resolved will be that of the POM in which the dependencyManagement
section is specified. If this POM is a snapshot, these dependency
specifications will get the timestamp/buildnumber of that POM, instead of the
actual one used when the dependency it references gets deployed.
We should look at strategies for limiting or eliminating this practice, or
else (somehow) pulling the real timestamp/buildnumber for that artifact from
the reactor...in order to make these deps transitively resolvable for users.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2569) Expressions not evaluated inside parent
[ http://jira.codehaus.org/browse/MNG-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenney Westerhof updated MNG-2569: -- Summary: Expressions not evaluated inside parent (was: The version tag within the parrent block does not evaluate properties.) Expressions not evaluated inside parent - Key: MNG-2569 URL: http://jira.codehaus.org/browse/MNG-2569 Project: Maven 2 Issue Type: Bug Components: Inheritance and Interpolation, POM, Reactor and workspace Affects Versions: 2.0.4 Environment: WinXP Java 1.5_08 Maven 2.04 Reporter: Thomas Minor Priority: Minor Fix For: Reviewed Pending Version Assignment The version tag within the parrent block does not evaluate properties. If I put a Version String directly in there, it works. A correctly defined property doesn't. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3009) Maven 2.0.5+ fails to resolve ${project.version} on deployment
[
http://jira.codehaus.org/browse/MNG-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof closed MNG-3009.
-
Resolution: Duplicate
Maven 2.0.5+ fails to resolve ${project.version} on deployment
--
Key: MNG-3009
URL: http://jira.codehaus.org/browse/MNG-3009
Project: Maven 2
Issue Type: Bug
Components: Deployment
Affects Versions: 2.0.5, 2.0.6
Reporter: Stefan Behnel
Priority: Blocker
Fix For: Reviewed Pending Version Assignment
Starting with version 2.0.5, Maven fails to resolve the ${project.version}
variable in poms on (SNAPSHOT?) deployment. This results in corrupted
repositories, as Maven will (sporadically) fail to resolve transitive
dependencies that involve these references.
The symptom is that Maven will start searching for a magical version 2.4.1
of an artifact, although such a version never existed and was never written
in any POM. Dependent builds therefor fail as this version cannot be resolved.
The deploy plugin should *always* resolve all involved versions when it
uploads POMs.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2745) Do not allow System properties to be interpolated in the POM
[
http://jira.codehaus.org/browse/MNG-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof closed MNG-2745.
-
Resolution: Duplicate
Do not allow System properties to be interpolated in the POM
Key: MNG-2745
URL: http://jira.codehaus.org/browse/MNG-2745
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 2.0.4
Environment: Windows using JDK 1.4.2
Reporter: Jason van Zyl
Assignee: Jason van Zyl
Fix For: 2.1.x
There is an XML library which is inserting a property version=2.4.1 and it is
completely screwing up the interpolation of ${version} in any POM.
1) We should force fully qualified references anyway so ${pom.version} and
not allow ${version}
2) Totally shut out System properties from all internal operations. We can
still take -D from the command line and turn them into execution properties
but we should just ignore all Sytem properties in the core.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2199) Version ranges not supported for parent artifacts
[
http://jira.codehaus.org/browse/MNG-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99678
]
Kenney Westerhof commented on MNG-2199:
---
tempting to 'close - won't fix'.
Whatever parent pom is present in the local repo will be used, resulting in a
different effective pom on different systems.
This'll be the cause of all sorts of problems.
Version ranges not supported for parent artifacts
-
Key: MNG-2199
URL: http://jira.codehaus.org/browse/MNG-2199
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation, POM, Reactor and workspace
Affects Versions: 2.0.3
Reporter: Christian Schulte
Fix For: 2.1.x
It would be great if Maven supports version ranges when specifying parent
artifacts in a multi-module build. Currently this does not work.
parent
artifactIdartifactId/artifactId
groupIdgroupId/groupId
version[2.0, 2.0.1]/version
/parent
[INFO] Scanning for projects...
Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0,
2.0.1]/artifactId-[2.0, 2.0.1].pom
Additionally it would be great if this
parent
artifactIdartifactId/artifactId
groupIdgroupId/groupId
version[2.0, ${pom.version}]/version
/parent
[INFO] Scanning for projects...
Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0,
${pom.version}]/artifactId-[2.0, ${pom.version}].pom
would also work, if the version is specified in the same pom.xml which
defines this parent definition.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2915) No way to avoid adding artifactId to site urls
[
http://jira.codehaus.org/browse/MNG-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99680
]
Kenney Westerhof commented on MNG-2915:
---
Place to fix:
maven-project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java
perhaps check wheter the parentpath already contains an expression for
artifactId, or maybe add a decision
whether to append based on the path ending in a slash or not.
No way to avoid adding artifactId to site urls
--
Key: MNG-2915
URL: http://jira.codehaus.org/browse/MNG-2915
Project: Maven 2
Issue Type: Improvement
Components: Sites Reporting
Affects Versions: 2.0.5
Reporter: Richard van der Hoff
Priority: Minor
Fix For: Reviewed Pending Version Assignment
Currently, whenever a child pom inherits from a parent (and doesn't override
the relevant settings), both project.url and
project.distributionManagement.site.url have the name of the child artifact
appended.
It would be nice to be able to have something like
:code:
urlscpexe://host/blah/${project.artifactId}/${project.version}/url
:code:
and have this inherited to all child poms in the obvious way.
My usecase for this is that we have a single parent pom for all our projects,
with useful settings such as distributionManagement, and I'd like to be able
to deploy their sites to a single directory and have Apache generate me a
directory listing for all the child projects. However, I curently have no way
of releasing the parent project without obliterating the list of child
projects.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2915) No way to avoid adding artifactId to site urls
[
http://jira.codehaus.org/browse/MNG-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof updated MNG-2915:
--
Fix Version/s: (was: Reviewed Pending Version Assignment)
2.1-alpha-1
No way to avoid adding artifactId to site urls
--
Key: MNG-2915
URL: http://jira.codehaus.org/browse/MNG-2915
Project: Maven 2
Issue Type: Improvement
Components: Sites Reporting
Affects Versions: 2.0.5
Reporter: Richard van der Hoff
Priority: Minor
Fix For: 2.1-alpha-1
Currently, whenever a child pom inherits from a parent (and doesn't override
the relevant settings), both project.url and
project.distributionManagement.site.url have the name of the child artifact
appended.
It would be nice to be able to have something like
:code:
urlscpexe://host/blah/${project.artifactId}/${project.version}/url
:code:
and have this inherited to all child poms in the obvious way.
My usecase for this is that we have a single parent pom for all our projects,
with useful settings such as distributionManagement, and I'd like to be able
to deploy their sites to a single directory and have Apache generate me a
directory listing for all the child projects. However, I curently have no way
of releasing the parent project without obliterating the list of child
projects.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2241) Versions are required when it shouldn't with multi-modules projects and war dependencies
[
http://jira.codehaus.org/browse/MNG-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99681
]
Kenney Westerhof commented on MNG-2241:
---
Specifying type in the dependencies in depMgt for deps that aren't
packagingjar should solve this.
However this needs to be fixed. A more strict separation between packaging,
types, and classifiers should be enforced.
The default of typejar/type in a dependency is bogus - it needs to be the
same as the packaging from the pom for that artifact/dependency.
Specifing, for instance, a test-jar dependency, you can say
typetest-jar/type. Since this is not a derived artifact, classifiers don't
apply here.
It's an alternative packaging, so typetest-jar/type is correct. Classifiers
shouldn't apply here.
The same goes for attached assemblies.
Are Javadoc and source jars considered derived or alternative? Since the source
_could_ theoretically be derived from the main artifact, it could be a
classifier,
though you'd miss the javadoc, so I think these are alternatives, and a type
is wise here.
For war and ear artifacts, the packaging _is_ the main type; it's not an
attachment, either derived or alternative, so type shouldn't be needed
in dependencies or dependencyManagement.
Also, i've never seen multiple classifiers for one type, where the type is not
the main type.
Anyway, since this (typejar/type being the default for dependencies) is
documented, this should be a closed-won't fix, though since I disagree with
the spec/documentation I'll leave this open.
Versions are required when it shouldn't with multi-modules projects and war
dependencies
Key: MNG-2241
URL: http://jira.codehaus.org/browse/MNG-2241
Project: Maven 2
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.0.4
Environment: Maven 2.0.4, Java 5, Windows XP
Reporter: Celso Gomes Barreto Junior
Fix For: 2.1.x
In a multi-project with a parent pom which should enforces modules's versions
in dependencyManagement element, when I use a war dependnecy it starts to
require the version declaration in child pom's dependencies. When I use jar
dependencies, it works fine.
Project structure:
parent project
|_ web (war)
|_ commons (jar)
|_ webcommons (war)
--
parent project pom:
?xml version=1.0 encoding=UTF-8?
project
modelVersion4.0.0/modelVersion
nameProcdev - Referência/name
groupIdglobo/groupId
artifactIdprocdevref/artifactId
packagingpom/packaging
version0.0.1/version
descriptionno/description
modules
moduleweb/module
modulecommons/module
modulewebcommons/module
/modules
dependencyManagement
dependencies
dependency
groupIdglobo/groupId
artifactIdprocdevref-web/artifactId
version${project.version}/version
/dependency
dependency
groupIdglobo/groupId
artifactIdprocdevref-commons/artifactId
version${project.version}/version
/dependency
dependency
groupIdglobo/groupId
artifactIdprocdevref-webcommons/artifactId
version${project.version}/version
/dependency
/dependencies
/dependencyManagement
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version3.8.1/version
scopetest/scope
/dependency
/dependencies
/project
--
web project pom:
?xml version=1.0 encoding=UTF-8?
project
modelVersion4.0.0/modelVersion
parent
groupIdglobo/groupId
artifactIdprocdevref/artifactId
version0.0.1/version
/parent
nameProcdev Web/name
artifactIdprocdevref-web/artifactId
packagingwar/packaging
version0.0.1/version
descriptionno/description
dependencies
dependency
groupIdglobo/groupId
artifactIdprocdevref-webcommons/artifactId
typewar/type
/dependency
dependency
groupIdglobo/groupId
artifactIdprocdevref-commons/artifactId
/dependency
dependency
groupIdjstl/groupId
artifactIdjstl/artifactId
version[1.1.2,]/version
/dependency
dependency
groupIdtaglibs/groupId
artifactIdstandard/artifactId
version[1.1.2,]/version
/dependency
/dependencies
/project
--
webcommons project pom:
?xml version=1.0 encoding=UTF-8?
project
modelVersion4.0.0/modelVersion
parent
groupIdglobo/groupId
artifactIdprocdevref/artifactId
version0.0.1/version
/parent
nameProcdev Web Commons/name
artifactIdprocdevref-webcommons/artifactId
packagingwar/packaging
[jira] Commented: (MNG-2340) Incorrect dependency version downloaded
[
http://jira.codehaus.org/browse/MNG-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99682
]
Kenney Westerhof commented on MNG-2340:
---
Maven 2.0.6 and 2.0.7 do it like this:
- depMgt provides defaults; so if a child pom declares a dependency present in
depMgt, with a different version, the version from the child pom is used.
Maven 2.0.4 and 2.0.5 do it like this:
- depMgt provides OVERRIDES, so if a child pom declares a dependency present in
depMgt, with a different version, the version from depMgt is used.
The difference probably is that you use the commandline version of maven, 2.0.4
or 2.0.5, and in eclipse you use the embedder which is based
on 2.1, and uses the same approach as 2.0.6 and 2.0.7.
I think that when you use the commandline version 2.0.6 or newer, you'll see
that m2eclipse and maven commandline both use the same approach.
Incorrect dependency version downloaded
---
Key: MNG-2340
URL: http://jira.codehaus.org/browse/MNG-2340
Project: Maven 2
Issue Type: Bug
Components: Embedding
Affects Versions: 2.0.4
Reporter: Adrian
Priority: Critical
Fix For: 2.1.x
Attachments: MNGECLIPSE-131.zip
I have a parent pom with a dependency management section specifying the
version of an artifact to use. In the child project, I override this version.
The maven plugin ignores the overriding version and downloads the version
specified by the parent pom.
For example, in the parent pom
{code}
dependency
groupIdlucene/groupId
artifactIdlucene/artifactId
version1.4.3/version
/dependency
{code}
in the project pom, inheriting the parent pom
{code}
dependency
groupIdlucene/groupId
artifactIdlucene/artifactId
version2.0/version
/dependency
{code}
The maven eclipse plugin downloads version 1.4.3 for my project
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2826) Integration-test target runs integration tests twice
[
http://jira.codehaus.org/browse/MNG-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenney Westerhof closed MNG-2826.
-
Resolution: Won't Fix
This is not a bug nor an issue; this should've been asked on the users list.
what you're doing is declaring the surefire plugin's test goal again, when it
is already defined
implicitly in the test phase.
If you have tests you do not want to execute during the normal test phase, you
should exclude them
from the execution;
Define an execution, phase test, goal test, outside of the profile.
Add excludes to **/*ITest.java (inside a configuration tag in the execution
tag) or whatever your integration test classes are.
Then update the execution for the integration test profile and add an includes
there for **/*ITest.
Surefire will run twice, once in the test phase, once in the integration-test
phase, but executing different
tests.
Integration-test target runs integration tests twice
Key: MNG-2826
URL: http://jira.codehaus.org/browse/MNG-2826
Project: Maven 2
Issue Type: Bug
Components: Bootstrap Build
Affects Versions: 2.0.4
Environment: Win XP
Reporter: EJ Ciramella
Fix For: Reviewed Pending Version Assignment
So we have two types of tests, unit and integration.
What we've attempted to do is bind the integration-test lifecycle to the
test phase but ONLY run the *Utest.java tests when integration-test
was specified.
What happens is, by default, the test goal works fine, but when you
specify integration-test it runs the *Utest.java tests twice.
I'll attach the logs shortly...
Here's the important part from the log:
[INFO]
[INFO] Building Reward Engine
[INFO]task-segment: [integration-test]
[INFO]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test]
[INFO] Surefire report directory:
E:\work\LTY-P39\rewardEngine\..\reportsdirectory
---
T E S T S
---
There are no tests to run.
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar]
[INFO] Building jar:
E:\work\LTY-P39\rewardEngine\target\rewardEngine-1.0-SNAPSHOT.jar
[INFO] Preparing javadoc:javadoc
[WARNING] Removing: javadoc from forked lifecycle, to prevent recursive
invocation.
[INFO] No goals needed for project - skipping
[INFO] [javadoc:javadoc {execution: default}]
39 warnings
[INFO] [surefire:test {execution: surefire-iTest}]
[INFO] Surefire report directory:
E:\work\LTY-P39\rewardEngine\..\reportsdirectory
---
T E S T S
---
Running com.upromise.common.reward.RewardEngineITest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 24.123
sec
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO] [surefire:test {execution: surefire-iTest}]
[INFO] Surefire report directory:
E:\work\LTY-P39\rewardEngine\..\reportsdirectory
---
T E S T S
---
Running com.upromise.common.reward.RewardEngineITest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 25.23
sec
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
Here are the details of my pom:
I'm having a problem binding our integration tests to the
integration-test lifecycle goal.
Can anyone explain why this would happen twice?
Here's my pom:
?xml version=1.0 encoding=ISO-8859-1?
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
parent
groupIdlty/groupId
artifactIdapp/artifactId
version1.0-SNAPSHOT/version
/parent
artifactIdrewardEngine/artifactId
packagingjar/packaging
version1.0-SNAPSHOT/version
descriptionModule to calculate rewards/description
nameReward Engine/name
urlhttp://www.upromise.com/url
build
resources
resource
directorysrc/main/resources/directory
filteringtrue/filtering
/resource
/resources
plugins
plugin
[jira] Closed: (MNG-2448) Can not exclude a dependency from a plugin
[ http://jira.codehaus.org/browse/MNG-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenney Westerhof closed MNG-2448. - Resolution: Won't Fix Just redeclare the dependency as you normally do inside plugindependencies. Since maven 2.0.5, (or possibly 2.0.6) that declaration will override the one from the plugin itself. Can not exclude a dependency from a plugin -- Key: MNG-2448 URL: http://jira.codehaus.org/browse/MNG-2448 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.4 Reporter: Dain Sundstrom Fix For: Reviewed Pending Version Assignment I need to be able to exclude a dependency that a plugin included so I can replace it with a different dependency. In this exact case I'm attempting to use the com.sun.tools.xjc.maven2:maven-jaxb-plugin:1.0 plugin and it depends on the non-public jsr173 jar. I would like to exclude that jar so I can include public stax one. I know this will be fixed by implementing the spec resolution feature, but excluding bad dependencies from a plugin is a general problem. The following snippit will demonstrate the download problem assuming you don't have the jsr173 jar available: plugin groupIdcom.sun.tools.xjc.maven2/groupId artifactIdmaven-jaxb-plugin/artifactId version1.0/version executions execution goals goalgenerate/goal /goals /execution /executions configuration generatePackageorg.apache.xbean.jaxb.schema/generatePackage /configuration /configuration /plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2434) Local snapshots should be preferred over remote ones
[ http://jira.codehaus.org/browse/MNG-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99688 ] Kenney Westerhof commented on MNG-2434: --- Could this be tested again with 2.0.6? I think there's a fix for another issue that may solve this one as a side-effect. Local snapshots should be preferred over remote ones Key: MNG-2434 URL: http://jira.codehaus.org/browse/MNG-2434 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Reporter: Carsten Ziegeler Fix For: Reviewed Pending Version Assignment If you're build a project with snapshots, m2 tries to download the newest versions of the snapshots even if the local ones are newer. Interestingly later on, the local versions are used. So the download is useless. A complex test case for this is the Cocoon project where nearly all modules are snapshot and locally build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1603) Upload JIDE Common Layer to maven repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99693 ] Wim Deblauwe commented on MAVENUPLOAD-1603: --- I see that the bundle does not include the sources. This is very handy for the IntelliJ and Eclipse plugins. Can you create a bundle with a source jar in there? Upload JIDE Common Layer to maven repository Key: MAVENUPLOAD-1603 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1603 Project: maven-upload-requests Issue Type: Task Reporter: David Qiao JIDE Common Layer is Swing component library built on top of Java/Swing. It is also the foundation of other component products from JIDE. This project has over 30 Swing components and over 100k lines of code. It greatly enhanced the default component set provided by Swing and allow developers to focus on business logic layer instead of making components. JIDE Common Layer was originally developed by JIDE Software developers as a foundation in order to build other more advanced components. In April of 2007, JIDE Software decided to open source this common layer so that more and more developers can leverage them instead of wasting time building them again. For more information, please visit project home page on JIDE Software website at http://www.jidesoft.com/products/oss.htm or on java.net at https://jide-oss.dev.java.net. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1603) Upload JIDE Common Layer to maven repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99694 ] David Qiao commented on MAVENUPLOAD-1603: - I just double checked. The bundle jar contains jide-oss-2.0.4-sources.jar which is the source jar. Is it what you are looking for? Upload JIDE Common Layer to maven repository Key: MAVENUPLOAD-1603 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1603 Project: maven-upload-requests Issue Type: Task Reporter: David Qiao JIDE Common Layer is Swing component library built on top of Java/Swing. It is also the foundation of other component products from JIDE. This project has over 30 Swing components and over 100k lines of code. It greatly enhanced the default component set provided by Swing and allow developers to focus on business logic layer instead of making components. JIDE Common Layer was originally developed by JIDE Software developers as a foundation in order to build other more advanced components. In April of 2007, JIDE Software decided to open source this common layer so that more and more developers can leverage them instead of wasting time building them again. For more information, please visit project home page on JIDE Software website at http://www.jidesoft.com/products/oss.htm or on java.net at https://jide-oss.dev.java.net. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1604) release ognl 2.7
release ognl 2.7 Key: MAVENUPLOAD-1604 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1604 Project: maven-upload-requests Issue Type: Task Reporter: Jesse Kuhnert The 2.7 release has been made to a remote repository which can be found here: http://opencomponentry.com/repository/m2-ibiblio-sync-repo/ognl/ognl/2.7/ . The main project web site is http://www.ognl.org, but also http://opensymphony.com/ognl/ since the project was taken over by opensymphony. I haven't yet made any new changes to the actual web site (still syncing with Patrick) so I'm not listed officially on a team list but am visible as the project lead here: http://jira.opensymphony.com/browse/OGNL. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2434) Local snapshots should be preferred over remote ones
[ http://jira.codehaus.org/browse/MNG-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99697 ] Carsten Ziegeler commented on MNG-2434: --- Yes, this does not happen with maven 2.0.6 any more, so it seems that this is fixed now. Local snapshots should be preferred over remote ones Key: MNG-2434 URL: http://jira.codehaus.org/browse/MNG-2434 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Reporter: Carsten Ziegeler Fix For: Reviewed Pending Version Assignment If you're build a project with snapshots, m2 tries to download the newest versions of the snapshots even if the local ones are newer. Interestingly later on, the local versions are used. So the download is useless. A complex test case for this is the Cocoon project where nearly all modules are snapshot and locally build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2434) Local snapshots should be preferred over remote ones
[ http://jira.codehaus.org/browse/MNG-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99698 ] Kenney Westerhof commented on MNG-2434: --- Thanks for testing! Marking this closed and fixed in 2.0.6. Local snapshots should be preferred over remote ones Key: MNG-2434 URL: http://jira.codehaus.org/browse/MNG-2434 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Reporter: Carsten Ziegeler Fix For: 2.0.6 If you're build a project with snapshots, m2 tries to download the newest versions of the snapshots even if the local ones are newer. Interestingly later on, the local versions are used. So the download is useless. A complex test case for this is the Cocoon project where nearly all modules are snapshot and locally build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2434) Local snapshots should be preferred over remote ones
[ http://jira.codehaus.org/browse/MNG-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenney Westerhof closed MNG-2434. - Resolution: Fixed Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.6 Local snapshots should be preferred over remote ones Key: MNG-2434 URL: http://jira.codehaus.org/browse/MNG-2434 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Reporter: Carsten Ziegeler Fix For: 2.0.6 If you're build a project with snapshots, m2 tries to download the newest versions of the snapshots even if the local ones are newer. Interestingly later on, the local versions are used. So the download is useless. A complex test case for this is the Cocoon project where nearly all modules are snapshot and locally build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-106) Dependencies with scope runtime or provided are not used in the javadoc classpath
[ http://jira.codehaus.org/browse/MJAVADOC-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99699 ] Adam Hardy commented on MJAVADOC-106: - I am trying to run javadoc on the tests in my src/test/java directory, and I find that maven-javadoc-plugin is excluding the dependencies with scope 'test'. This unleashes a whole stream of nasty exceptions such as: java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl These nasty exceptions seem to stem from a bug in javadoc itself: [http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6442982] so the exceptions will not appear for everyone. Javadoc may complete, but I suspect it will leave unsatisfied links to 'test' dependencies. I then changed the scope on the required dependencies to 'provided' and maven-javadoc-plugin now does include the dependency in the classpath passed to javadoc - contrary to what Christophe is experiencing. I am using JDK 1.5.0_12, mvn 2.0.6, maven-javadoc-plugin 2.3-20070314.204553-2 It seems that maven-javadoc-plugin is currently suitable only for running javadoc on the main code, rather than any other source folders such as test. I can of course include the src/test/java directory in the config with sourcepath tags, but the javadoc will not be correct, if it completes at all. As a work-around I can specify scope 'provided'. I am currently looking into another issue I have with the plugin, so when I am convinced that it too is a bug, I would be happy to put together a quick test project. Best regards Dependencies with scope runtime or provided are not used in the javadoc classpath - Key: MJAVADOC-106 URL: http://jira.codehaus.org/browse/MJAVADOC-106 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Christophe DENEUX Hi, I have a class inherited from an hibernate class. So my project contains a dependency onto Hibernate with the default scope, and an other dependencies needed by Hibernate with scope=runtime and/or provided. My javadoc plugin is configured to use the doclet Umlgraph. At the report generation I have an error telling that classes are not found. These classes are contained in dependencies with scope=runtime/provided. If I change the scope to compile, that works fine. After investigation in the source code, it seems to me that only dependencies with scope=compile are used. Can you take into account dependencies with scope=runtime/provided, or propose configuration parameters to set these artifacts. Christophe DENEUX Capgemini Sud - France - Nice -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2466) resursive build - modules using always using pom.xml
[ http://jira.codehaus.org/browse/MNG-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2466. -- Resolution: Fixed Won't fix. You should use profiles to use different sets of dependencies and behavior. Encouraging multipe hierarchies of POMs is a bad practice. resursive build - modules using always using pom.xml Key: MNG-2466 URL: http://jira.codehaus.org/browse/MNG-2466 Project: Maven 2 Issue Type: Bug Components: POM Environment: software Reporter: Jagan Priority: Blocker Fix For: Reviewed Pending Version Assignment When we run a multi project build with an alternative pom file, the modules its still using pom.xml. Shouldn't the modules use the same alternative pom file which we passed. Could someone fix at the earliest as its a showstopper for our development. Thanks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2972) Ignores version of plugin dependency specified in my pom
[ http://jira.codehaus.org/browse/MNG-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2972. -- Resolution: Won't Fix This is not how plugin dependencies work. You actually specify the dependencies inside the plugin element. Try this and if that doesn't work then it's a bug and open a new issue. Ignores version of plugin dependency specified in my pom Key: MNG-2972 URL: http://jira.codehaus.org/browse/MNG-2972 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.6 Environment: maven 2.0.6, java version 1.5.0_07 Reporter: Derek Alexander Priority: Critical Fix For: Reviewed Pending Version Assignment xmlbeans-maven-plugin declares a dependency on xmlbeans-2.0.0 I want to use xmlbeans-2.2.0 So in my pom I put: plugin groupIdorg.codehaus.mojo/groupId artifactIdxmlbeans-maven-plugin/artifactId executions execution goals goalxmlbeans/goal /goals /execution /executions configuration ... /configuration dependencies dependency groupIdxmlbeans/groupId artifactIdxbean/artifactId version2.2.0/version /dependency /dependencies /plugin But it still downloads 2.0.0. (as well as 2.2.0). Haven't got a clue which it is using as it doesn't seem to output stuff like that. Couldn't see a verbose or debug switch mentioned in the docs. Anyway I think it is still using 2.0.0. Seems like I'm not the first to experience this: http://www.nabble.com/Override-plugin-dependency-version-tf2357806s177.html#a6568092 Apparently this should be possible: http://maven.apache.org/pom.html#plugins dependencies: Dependencies are seen a lot within the POM, and are an element under all plugins element blocks. The dependencies have the same structure and function as under that base build. The major difference in this case is that instead of applying as dependencies of the project, they now apply as dependencies of the plugin that they are under. The power of this is to alter the dependency list of a plugin, perhaps by removing an unused runtime dependency via exclusions, or by altering the version of a required dpendency. See above under Dependencies for more information. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1436) Unable to load maven-model-2.0-all from a plugin
[ http://jira.codehaus.org/browse/MNG-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99705 ] Jason van Zyl commented on MNG-1436: Brett, so can this be closed? Unable to load maven-model-2.0-all from a plugin Key: MNG-1436 URL: http://jira.codehaus.org/browse/MNG-1436 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Reporter: fabrizio giustina Priority: Critical Fix For: Reviewed Pending Version Assignment The org.apache.maven:maven-model artifact is available with the all classifier in the maven repo. The all version also contains project v3 classes and reader/writer. Adding a dependency with: dependency groupIdorg.apache.maven/groupId artifactIdmaven-model/artifactId version2.0/version typejar/type classifierall/classifier /dependency let you use project 3 classes in a plugin and install successfully. However, when running the plugin, the maven-model-2.0-all artifact seems to be ignored and replaced by the version in m2/lib _also if the classifier is different_. This is the debug log from an execution of a plugin that uses this dependency: [INFO] Searching repository for plugin with prefix: 'maven1'. [DEBUG] maven-maven1-plugin: using locally installed snapshot [DEBUG] maven-maven1-plugin: using locally installed snapshot [DEBUG] org.apache.maven.plugins:maven-maven1-plugin:maven-plugin:2.0-SNAPSHOT (selected for runtime) [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for runtime) [DEBUG] Retrieving parent-POM from the repository for project: org.apache.maven:maven-model:jar:2.0 [DEBUG] org.apache.maven:maven-model:jar:all:2.0 (selected for runtime) [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for runtime) [DEBUG] dom4j:dom4j:jar:1.4 (selected for runtime) [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-maven1-plugin:2.0-SNAPSHOT:convert' -- [DEBUG] (f) basedir = \testconvert [DEBUG] -- end configuration -- [INFO] [1:convert] [WARNING] pom.xml in \testconvert already exists, overwriting [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org/apache/maven/model/v3_0_0/io/xpp3/MavenXpp3Reader [INFO] [DEBUG] Trace java.lang.NoClassDefFoundError: org/apache/maven/model/v3_0_0/io/xpp3/MavenXpp3Reader At the moment this makes impossible to use pom v.3 in mvn. Apart from the classifier issue that could be solved in a future m2 release, I would like to find out a workaroud in order to use v3 poms for a mvn plugin that could automatically convert maven 1 project.xml to mvn pom.xml for making migration from maven 1 easier. The current options I can think at are: - embedding the org.apache.maven.model.v3_0_0.* classes in the plugin - releasing maven-model-2.0-all with a different artifactId (maven-model-all-2.0 or maven-model-v3-2.0) thoughts? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2602) maven-csharp-source-plugin:process-classes messes up outputDirectory and thereby indirectly messes up release plugin
[ http://jira.codehaus.org/browse/MNG-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2602. -- Resolution: Won't Fix This is not one of our plugins. Request to move it, as it looks more like an NMaven issue to me. maven-csharp-source-plugin:process-classes messes up outputDirectory and thereby indirectly messes up release plugin Key: MNG-2602 URL: http://jira.codehaus.org/browse/MNG-2602 Project: Maven 2 Issue Type: Bug Components: Sandbox Environment: Windows XP Reporter: James Carpenter Priority: Critical Fix For: Reviewed Pending Version Assignment Within the csharp plugins org.apache.maven.plugins:maven-csharp-source-plugin:process-classes is registered at the process-classes phase. Within this plugin the execute method resets the output directory to be that of the actual artifact (target/dotnet-assembly/somelib.dll) rather than the directory which it was set to (target/dotnet-assembly). The short javadoc within org.apache.maven.plugin.csharp.source.ProcessClassesMojo says: --- This Mojo adds the result of the compile to the classpath elements This is required by the NUnitMojo. As it turns out this has very negative side affects. If one tries to run multiple goals at once (mvn deploy site-deploy), the first goal is very likely to mess up the effective pom for the following goal. This is what happens to the release plugin. During release:perform the release plugin uses the plexus command line tools to run mvn --no-plugin-updates --variousOtherFlags deploy site-deploy within target/checkout. As you might imagine this really messes things up, such that the site-deploy fails as it tries to find target/checkout/target/dotnet-assembly/somelib.dll/somelib.dll. In summary a better way to keep the NUnit plugin happy must be found, as the current solution is very problematic. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2559) Module Selection From Command Line Argument Broken
[ http://jira.codehaus.org/browse/MNG-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2559: --- Use profiles to define different modules and then invoke the profile with -P. Module Selection From Command Line Argument Broken -- Key: MNG-2559 URL: http://jira.codehaus.org/browse/MNG-2559 Project: Maven 2 Issue Type: Bug Components: Command Line Affects Versions: 2.0.4 Environment: Linux 2.6.16-gentoo-r7 #3 SMP PREEMPT i686 Intel(R) Xeon(TM) CPU 3.40GHz GNU/Linux Java HotSpot(TM) Server VM (build 1.5.0_07-b03, mixed mode) Maven 2.0.4 Reporter: Gus Power Fix For: Reviewed Pending Version Assignment Hi, I am unable to specify which modules to include in the reactor build from the command line when invoking maven on the parent POM. Having searched around on Google I have seen references to invoking maven using the following syntax: 'mvn -Dmodule=moduleName goal' but it does not appear to have any effect. My solution is to define different module combinations in different parent POM profiles but this is clunky and inflexible. This has been a key annoyance in setting up different cruisecontrol configurations for our continuous build. Regards, Gus. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2559) Module Selection From Command Line Argument Broken
[ http://jira.codehaus.org/browse/MNG-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2559. -- Resolution: Won't Fix Module Selection From Command Line Argument Broken -- Key: MNG-2559 URL: http://jira.codehaus.org/browse/MNG-2559 Project: Maven 2 Issue Type: Bug Components: Command Line Affects Versions: 2.0.4 Environment: Linux 2.6.16-gentoo-r7 #3 SMP PREEMPT i686 Intel(R) Xeon(TM) CPU 3.40GHz GNU/Linux Java HotSpot(TM) Server VM (build 1.5.0_07-b03, mixed mode) Maven 2.0.4 Reporter: Gus Power Fix For: Reviewed Pending Version Assignment Hi, I am unable to specify which modules to include in the reactor build from the command line when invoking maven on the parent POM. Having searched around on Google I have seen references to invoking maven using the following syntax: 'mvn -Dmodule=moduleName goal' but it does not appear to have any effect. My solution is to define different module combinations in different parent POM profiles but this is clunky and inflexible. This has been a key annoyance in setting up different cruisecontrol configurations for our continuous build. Regards, Gus. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2565) plugin version aren't taken from pluginManagement in a sub-sub-modules
[ http://jira.codehaus.org/browse/MNG-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99708 ] Jason van Zyl commented on MNG-2565: Is this an issue? Or can this be closed? plugin version aren't taken from pluginManagement in a sub-sub-modules -- Key: MNG-2565 URL: http://jira.codehaus.org/browse/MNG-2565 Project: Maven 2 Issue Type: Bug Components: Inheritance and Interpolation Affects Versions: 2.0.5 Reporter: Emmanuel Venisse Priority: Critical Fix For: Reviewed Pending Version Assignment It works only for the first inheritence level -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2588) Rewrite of the maven-jdeveloper-plugin to use classes for IDE like in the Eclipse plugins
[ http://jira.codehaus.org/browse/MNG-2588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99709 ] Jason van Zyl commented on MNG-2588: This is a not a core maven issue. Where do we want to put this stuff? Rewrite of the maven-jdeveloper-plugin to use classes for IDE like in the Eclipse plugins - Key: MNG-2588 URL: http://jira.codehaus.org/browse/MNG-2588 Project: Maven 2 Issue Type: Improvement Components: IDEs Reporter: Sylvain Deschênes Fix For: Reviewed Pending Version Assignment Attachments: patch.txt Following a discussion on the Maven developer List started by Brett Porter, I have rewrited the JDeveloper plugin in order to make it use the utility classes wich are found in the maven eclipse plugin. I have kept the same idea wich was used by John Fallows. The plugin updates a blank jdeveloper project with informations coming from the pom and some additional configuration options. It still needs some work - some of the original features are still not implemented. For instance, it doesn't generate a test project, and it only work with version 10.1.3. I am planning to continue workint on it but I would like the original author's feedback first. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2889) Generic readModel method missing in embedder
[ http://jira.codehaus.org/browse/MNG-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2889: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.1.x Generic readModel method missing in embedder Key: MNG-2889 URL: http://jira.codehaus.org/browse/MNG-2889 Project: Maven 2 Issue Type: Improvement Components: Embedding Affects Versions: 2.0.4 Reporter: Piotr Smolinski Assignee: Jason van Zyl Fix For: 2.1.x Currently there is only one method to read model in MavenEmbedder. It supports only reading from file. There is need to provide readModel method using Reader as data source. I can find related methods for writing. Please consider opening pom.xml from archive in eclipse. There is only input stream to use. Thanks a lot, Piotr Smolinski -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2511) Need ability to redefine distribution management url
[ http://jira.codehaus.org/browse/MNG-2511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2511. -- Resolution: Fixed For deployment you can now specify and alternative distribution repository. The release plugin uses this to stage releases. Need ability to redefine distribution management url Key: MNG-2511 URL: http://jira.codehaus.org/browse/MNG-2511 Project: Maven 2 Issue Type: Improvement Components: Settings Affects Versions: 2.0.4 Reporter: Brian Fox Fix For: Reviewed Pending Version Assignment Currently the only way to specify a url for distributionManagement is in the pom. We need to be able to override that so that if needed a developer can set a server id in their settings and define a new url. For example, some developers are outside the company's infrastructure and they deploy differently than developers internally. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2526) Getting started sample fails several times, then it works suddenly
[ http://jira.codehaus.org/browse/MNG-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2526. -- Resolution: Cannot Reproduce Generally due to load on ibiblio but should not be the case anymore with the new server. Getting started sample fails several times, then it works suddenly -- Key: MNG-2526 URL: http://jira.codehaus.org/browse/MNG-2526 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Environment: Windows XP SP2, local firewall enabled (Windows defaults) Maven 2.0.4 ANT 1.6.5 Sun JDK 1.5.0_08 Company Firewall, opened for HTTP and FTP and some more ports Reporter: Markus KARG Fix For: Reviewed Pending Version Assignment When I am trying to follow the samples in the getting started guide, the mvn command will fail two times, but succeed on the third time. Certainly there is no bug in the mvn software, but the problem is the overloaded main repository servers I think. But nevertheless, beginners will have problems with that, also automated processes will crash. So this should be fixed ASAP. Here is the log: Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\Dokumente und Einstellungen\Kargmvn -version Maven version: 2.0.4 C:\Dokumente und Einstellungen\Kargmvn archetype:create -DgroupId=de.quipsy.fool -DartifactId=TheFoolApp [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'archetype'. [INFO] org.apache.maven.plugins: checking for updates from central [INFO] org.codehaus.mojo: checking for updates from central [INFO] artifact org.apache.maven.plugins:maven-archetype-plugin: checking for updates from central Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-archetype-plugin/1.0-alpha-4/maven-archetype-plugin-1.0-alpha-4.pom 1K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/archetype/maven-archetype/1.0-alpha-4/maven-archetype-1.0-alpha-4.pom 2K downloaded [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 'eb9e286b16844e1c5f8f38a9ddd7ee266985c8f6'; remote = '2f4311799239ce76c6c1386bee04988f579d2 6b7' - RETRYING Downloading: http://repo1.maven.org/maven2/org/apache/maven/archetype/maven-archetype/1.0-alpha-4/maven-archetype-1.0-alpha-4.pom 2K downloaded [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 'eb9e286b16844e1c5f8f38a9ddd7ee266985c8f6'; remote = '2f4311799239ce76c6c1386bee04988f579d2 6b7' - IGNORING Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-parent/1/maven-parent-1.pom 6K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/apache/1/apache-1.pom 3K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-archetype-plugin/1.0-alpha-4/maven-archetype-plugin-1.0-alpha-4.jar 9K downloaded [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [archetype:create] (aggregator-style) [INFO] Downloading: http://repo1.maven.org/maven2/org/apache/maven/archetype/maven-archetype-core/1.0-alpha-4/maven-archetype-core-1.0-alpha-4.pom 1K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-model/2.0/maven-model-2.0.pom 2K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven/2.0/maven-2.0.pom 8K downloaded Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.0.4/plexus-utils-1.0.4.pom 6K downloaded Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.pom 1K downloaded Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-containers/1.0.3/plexus-containers-1.0.3.pom 492b downloaded [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: null:plexus-container-default:jar:1.0-alpha-9 Reason: Cannot find parent: org.codehaus.plexus:plexus-containers for project: null:plexus-container-default:jar:1.0-alpha-9 [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 8 seconds [INFO] Finished at: Wed Aug 23 08:01:14 CEST 2006 [INFO] Final Memory: 1M/3M [INFO]
[jira] Updated: (MNG-2966) Use optional transitive dependencies versions as dependencyManagement does
[
http://jira.codehaus.org/browse/MNG-2966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-2966:
---
Fix Version/s: (was: Reviewed Pending Version Assignment)
2.1.x
Use optional transitive dependencies versions as dependencyManagement does
--
Key: MNG-2966
URL: http://jira.codehaus.org/browse/MNG-2966
Project: Maven 2
Issue Type: Improvement
Components: Dependencies
Affects Versions: 2.0.6
Reporter: Daniel Beland
Fix For: 2.1.x
I would like to be able to add an includes statement on a dependency to get
its optional dependency(ies).
ie:
dependency
groupIdhibernate/groupId
artifactIdhibernate/artifactId
version3.2.1.ga/version
inclusions
inclusion
groupIdjgroups/groupId
artifactIdjgroups-all/artifactId
scoperuntime/scope
optionalfalse/optional
/inclusion
/inclusions
/dependency
For example, I use hibernate 3.2.1.ga, it has an optional dependency on
jgroups-all-2.2.8.
I would like to be able to add an inclusion statement on the hibernate lib to
tell that I want to include jgroups as well.
The main reason for this is that I want the same version as specified in the
hibernate pom.
This way, upgrading hibernate would also upgrade my version of jgroups at the
same time.
Obviously, we need to be able to define a scope and optional attribute as
well (not inherited)
Or maybe we could set the dependency explicitly in the pom without specifying
the version and have maven resolve the version from the nearest source (as it
does normally) automatically or we specify where to resolve it.
ie something like:
dependency
groupIdjgroups/groupId
artifactIdjgroups-all/artifactId
! -- either maven resolves the version from the nearest source
automatically or we need to tell maven where to find it --
versionLookup
groupIdhibernate/groupId
artifactIdhibernate/artifactId
!-- maven will resolve the version from the hibernate pom as long as
hibernate is already a dependency of my project (no version needed)
or we specify which version from a property (to have it
defined only once in the pom) --
version${hibernate.version}/version
/versionLookup
scoperuntime/scope
optionalfalse/optional
/dependency
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2856) Maven Archetype Plugin Changes PNG images
[ http://jira.codehaus.org/browse/MNG-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2856. -- Resolution: Duplicate General binary resource filtering has already been raised in ARCHETYPE. Maven Archetype Plugin Changes PNG images - Key: MNG-2856 URL: http://jira.codehaus.org/browse/MNG-2856 Project: Maven 2 Issue Type: Bug Components: Plugin Creation Tools Affects Versions: 2.0.4 Environment: Fedora Core 6 Reporter: Ole Ersoy Priority: Minor Fix For: Reviewed Pending Version Assignment When the maven archetype serializes 123.png, it changes the file, making it unreadable. Here's the log info: [WARNING] org.apache.velocity.runtime.exception.ReferenceException: reference : template = archetype-resources/src/main/resources/images/123.png [line 9,column 50] : $I is not a valid reference. [WARNING] org.apache.velocity.runtime.exception.ReferenceException: reference : template = archetype-resources/src/main/resources/images/123.png [line 11,column 115] : $I is not a valid reference. Maybe there needs to be a binary resources tag in the archetype descriptor, so that the maven archetype simply copies binary resources, without attempting to evaluate template parameters. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2791) Error parsing Maven 1 POM file with an extend tag
[ http://jira.codehaus.org/browse/MNG-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2791. -- Resolution: Fixed We don't parse m1 POMs. Error parsing Maven 1 POM file with an extend tag - Key: MNG-2791 URL: http://jira.codehaus.org/browse/MNG-2791 Project: Maven 2 Issue Type: Bug Components: Embedding Affects Versions: 2.1.x Environment: Maven 2 Eclipse plugin 0.0.10 (latest from SVN) using the following jars: lucene-core-2.0.0.jar maven-embedder-2.1.0.v20070110-2115-dep.jar Eclipse 3.2 Session Data: eclipse.buildId=M20060921-0945 java.version=1.6.0 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=es_ES Command-line arguments: -os win32 -ws win32 -arch x86 -data c:\workspace -clean Reporter: Rodrigo Ruiz Fix For: Reviewed Pending Version Assignment Trying to rebuild a project that depends on an artifact obtained from a Maven1 repository, I get the following stacktrace: org.eclipse.core.runtime.CoreException: Parsing error [whatever].pom; org.codehaus.plexus.util.xml.pull.XmlPullParserException: Unrecognised tag: 'extend' (position: START_TAG seen .../modelVersion\n extend... @4:11) at org.maven.ide.eclipse.embedder.MavenModelManager.readMavenModel(MavenModelManager.java:137) at org.maven.ide.eclipse.embedder.ClassPathResolver.getJavaDocUrl(ClassPathResolver.java:241) at org.maven.ide.eclipse.embedder.ClassPathResolver.resolveClasspathEntries(ClassPathResolver.java:154) at org.maven.ide.eclipse.builder.Maven2Builder.updateClasspath(Maven2Builder.java:95) at org.maven.ide.eclipse.builder.Maven2Builder.build(Maven2Builder.java:86) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:603) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:167) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:230) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:233) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:252) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:285) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:145) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:208) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) org.eclipse.core.runtime.CoreException[4]: org.codehaus.plexus.util.xml.pull.XmlPullParserException: Unrecognised tag: 'extend' (position: START_TAG seen .../modelVersion\n extend... @4:11) at org.apache.maven.model.io.xpp3.MavenXpp3Reader.parseModel(MavenXpp3Reader.java:2405) at org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(MavenXpp3Reader.java:4438) at org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(MavenXpp3Reader.java:4449) at org.apache.maven.embedder.MavenEmbedder.readModel(MavenEmbedder.java:208) at org.maven.ide.eclipse.embedder.MavenModelManager.readMavenModel(MavenModelManager.java:133) at org.maven.ide.eclipse.embedder.ClassPathResolver.getJavaDocUrl(ClassPathResolver.java:241) at org.maven.ide.eclipse.embedder.ClassPathResolver.resolveClasspathEntries(ClassPathResolver.java:154) at org.maven.ide.eclipse.builder.Maven2Builder.updateClasspath(Maven2Builder.java:95) at org.maven.ide.eclipse.builder.Maven2Builder.build(Maven2Builder.java:86) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:603) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:167) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:230) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:233) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:252) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:285) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:145) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:208) at
[jira] Closed: (MNG-2810) Create a Windows Installer and update instructions on download site
[ http://jira.codehaus.org/browse/MNG-2810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2810. -- Resolution: Won't Fix Third parties can make installers, for example you can get one from Mergere. We're not putting the creation of installers in the standard release process. Others can do that. Create a Windows Installer and update instructions on download site --- Key: MNG-2810 URL: http://jira.codehaus.org/browse/MNG-2810 Project: Maven 2 Issue Type: Improvement Components: General Affects Versions: 2.0.4 Environment: http://maven.apache.org/download.html Reporter: Archimedes Trajano Fix For: Reviewed Pending Version Assignment Please add a Windows installer (similar to the one that was done in Maven 1.x) and update the instructions on http://maven.apache.org/download.html since it still refers to 2.0.3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2779) Inconsistent dependency scope resolution
[ http://jira.codehaus.org/browse/MNG-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2779. -- Resolution: Incomplete Provide a sample project that demonstrates the problem. Inconsistent dependency scope resolution Key: MNG-2779 URL: http://jira.codehaus.org/browse/MNG-2779 Project: Maven 2 Issue Type: Bug Components: Dependencies, Reactor and workspace Affects Versions: 2.0.4 Reporter: Chris Eldredge Priority: Minor Fix For: Reviewed Pending Version Assignment Suppose a multi-module project with modules a, b and c: module a depends on commons-lang (scope compile) module b depends on commons-lang (scope provided) module c depends on module a (scope test) module c depends on module b (scope provided) If I run mvn on the top level pom (with a moduleSet containing a, b and c) the compile of module c fails because commons-lang is included transitively with test scope (meaning that source code in src/main/java does not have commons-lang in the classpath). If I run mvn on module c only, commons-lang is included transitively with provided scope, and everything works fine. Changing module a's dependency on commons-lang to provided scope resolved this issue, but the inconsistency is there nonetheless. The inconsistency seems to be that in a reactor build, module dependencies are provided by MavenProject instances, whereas when the individual module is built, the module dependency is processed like any other from the pom in the repository. So I think the bug is in how module dependencies are processed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2875) Maven does not honour Plexus component lifecycles in embedded environment for singleton-keep-alive components
[ http://jira.codehaus.org/browse/MNG-2875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2875: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.1.x Component/s: (was: Plugins and Lifecycle) Embedding Maven does not honour Plexus component lifecycles in embedded environment for singleton-keep-alive components - Key: MNG-2875 URL: http://jira.codehaus.org/browse/MNG-2875 Project: Maven 2 Issue Type: Bug Components: Embedding Affects Versions: 2.0.5 Reporter: Ross Lamont Fix For: 2.1.x I have a plugin which is injected with a Plexus Component. This plexus component implements the plexus Startable interface, and therefore expects stop() to be called upon completion in order to perform cleanup. In addition, the component is a singleton-keep-alive component so it sticks around for a while and is available to other plugins. Now this plugin spawns and monitors a thread (it actually kicks off a copy of Jetty 5 so I can do integration tests). Naturally, I want to shut down Jetty 5 after my tests have run. To do this I have another plugin which is run after my integration tests which gets the component and tells it to shutdown the threads. All works well so far, provided that the tests don't fail. If the tests do fail, the stop plugin is never reached. In standalone maven this all works fine, because the process ends, killing the threads. In embedded maven however, the stop method of the component is never called, so that my copy of Jetty keeps on running and I have to shutdown my entire embedded environment (in this case Netbeans with Mevenide, but I believe the same problem occurs in Eclipse). Running through the code, it appears that Maven never shuts down the top level component, thus components never have the opportunity to cleanup. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2886) Dynamically includes module dependencies if subfolder is available
[
http://jira.codehaus.org/browse/MNG-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-2886.
--
Resolution: Fixed
You must be explicit and that's the way it will stay. Adding a directory should
not change maven's behavior, everything is controled from the POM. This is not
Ant.
Dynamically includes module dependencies if subfolder is available
-
Key: MNG-2886
URL: http://jira.codehaus.org/browse/MNG-2886
Project: Maven 2
Issue Type: Improvement
Components: Reactor and workspace
Affects Versions: 2.0.5
Reporter: Dominick More
Fix For: Reviewed Pending Version Assignment
We would like to use Maven to build our multi-project using the modules/
construct in a top level pom file. The project contains common libraries and
war files. Since the war files are not dependent on each other, developers
are used to exclude all other war project directories out of their SCM load
configurations to reduce update time. Currently we have implemented ANT in
such a way that if a project directory is not available at build time it will
excluded from the build configuration. Since the sub-module pom contains the
dependency/ reference to a sibling build configuration anyway the build
will fail if the dependency cannot be found.
Currently if a module is defined for which no project exists you get the
following error:
E:\Temp\Maven\AXNmvn install
[INFO] Scanning for projects...
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Error building POM (may not be this project's POM).
Project ID: unknown
Reason: Could not find the model file 'E:\Temp\Maven\AXN\xyz\pom.xml'.
...
On further investigation I located the source of the exception is being
thrown in the method org.apache.maven.DefaultMaven::collectProjects where the
modules list added at line 496:
modulesFiles.add( moduleFile );
The following change would do the trick...
if( moduleFile.isFile()) {
modulesFiles.add( moduleFile );
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2935) settings.xml errors are ignored
[ http://jira.codehaus.org/browse/MNG-2935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2935: --- Assignee: Jason van Zyl Affects Version/s: (was: 2.1-alpha-1) 2.1.x Fix Version/s: (was: Reviewed Pending Version Assignment) 2.1-alpha-1 settings.xml errors are ignored --- Key: MNG-2935 URL: http://jira.codehaus.org/browse/MNG-2935 Project: Maven 2 Issue Type: Bug Components: Settings Affects Versions: 2.1.x Reporter: Carlos Sanchez Assignee: Jason van Zyl Priority: Minor Fix For: 2.1-alpha-1 when there's a parsing error on settings.xml the build continues ignoring it $ mvn clean -X + Error stacktraces are turned on. Maven version: 2.1-SNAPSHOT [ERROR] Failed to read settings from: xxx\.m2\settings.xml. Throwing XmlPullParserException... [DEBUG] Registering at plexus.core: org.apache.maven.wagon.providers.ssh.jsch.interactive.PrompterUIKeyboardInteractive (object realm: [EMAIL PROTECTED]), lookuprealm=plexus.core [INFO] Scanning for projects... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2943) Same package name is used in different modules
[ http://jira.codehaus.org/browse/MNG-2943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2943. -- Resolution: Fixed One bundle will be used, and no one wants to change all the packages around to satisfy OSGi bundling requirements. Same package name is used in different modules -- Key: MNG-2943 URL: http://jira.codehaus.org/browse/MNG-2943 Project: Maven 2 Issue Type: Bug Components: General Affects Versions: 2.1-alpha-1 Reporter: Carlos Sanchez Assignee: Carlos Sanchez Fix For: Reviewed Pending Version Assignment As best practice and to play well with OSGi the same package shouldn't be in two modules We should copy classes to a new package, make old ones extend them and deprecate -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2940) Add a method to the embedder to list available versions of an artifact
[ http://jira.codehaus.org/browse/MNG-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99719 ] Jason van Zyl commented on MNG-2940: I reviewed this and 1) Why multiple remote repositories? An artifact should only be available from one repository 2) Why do you have the local repository? You want to full set of versions available in the wild yes? Or do you want to distinguish between local and remote? Add a method to the embedder to list available versions of an artifact -- Key: MNG-2940 URL: http://jira.codehaus.org/browse/MNG-2940 Project: Maven 2 Issue Type: New Feature Components: Embedding Affects Versions: 2.1.x Reporter: Carlos Sanchez Assignee: Jason van Zyl Fix For: Reviewed Pending Version Assignment Attachments: patch.txt, patch.txt I've added a method following the style of the resolve method already present public void resolve( Artifact artifact, List remoteRepositories, ArtifactRepository localRepository ) throws ArtifactResolutionException, ArtifactNotFoundException -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2940) Add a method to the embedder to list available versions of an artifact
[ http://jira.codehaus.org/browse/MNG-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2940: --- Affects Version/s: (was: 2.1-alpha-1) 2.1.x Add a method to the embedder to list available versions of an artifact -- Key: MNG-2940 URL: http://jira.codehaus.org/browse/MNG-2940 Project: Maven 2 Issue Type: New Feature Components: Embedding Affects Versions: 2.1.x Reporter: Carlos Sanchez Assignee: Jason van Zyl Fix For: Reviewed Pending Version Assignment Attachments: patch.txt, patch.txt I've added a method following the style of the resolve method already present public void resolve( Artifact artifact, List remoteRepositories, ArtifactRepository localRepository ) throws ArtifactResolutionException, ArtifactNotFoundException -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2956) The documentation refers to system property user.dir when it should refer to user.home
[
http://jira.codehaus.org/browse/MNG-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-2956.
--
Resolution: Incomplete
Tell us where, or the report of pretty much useless.
The documentation refers to system property user.dir when it should refer
to user.home
--
Key: MNG-2956
URL: http://jira.codehaus.org/browse/MNG-2956
Project: Maven 2
Issue Type: Bug
Components: Settings
Affects Versions: 2.0.5
Environment: Windows XP Professional
Reporter: Donley R. P'Simer
Fix For: Reviewed Pending Version Assignment
In several places the documentation for maven2 refers to the local repository
and user settings.xml file being relative to the ${user.dir} system
property. Behavior suggests that it is actually the ${user.home} system
property that is being used. From the javadoc for System.getProperties() in
jdk1.5:
user.home User's home directory
user.dir User's current working directory
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/System.html#getProperties()
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (DOXIA-119) How to deal with encoding and documentation
[ http://jira.codehaus.org/browse/DOXIA-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl moved MNG-1371 to DOXIA-119: -- Fix Version/s: (was: Documentation) Component/s: (was: Documentation: Guides) Complexity: (was: Intermediate) Key: DOXIA-119 (was: MNG-1371) Project: doxia (was: Maven 2) How to deal with encoding and documentation --- Key: DOXIA-119 URL: http://jira.codehaus.org/browse/DOXIA-119 Project: doxia Issue Type: Task Reporter: Jason van Zyl Show how people can use different encodings with APT. This can probably be added to the guide-site.apt. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-1259) clean up/fix the plugin registry
[ http://jira.codehaus.org/browse/MNG-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1259. -- Resolution: Fixed It's gone from 2.1.x. clean up/fix the plugin registry Key: MNG-1259 URL: http://jira.codehaus.org/browse/MNG-1259 Project: Maven 2 Issue Type: Task Components: Plugins and Lifecycle, Settings Affects Versions: 2.0-alpha-1 Reporter: Brett Porter Fix For: 2.1.x there are some command line options left over that are ineffective since the plugin registry isn't really used. We need to ensure this whole thing is fixed up, reenabled and cleaned up -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2938) Build error is ignored at the end of the build
[ http://jira.codehaus.org/browse/MNG-2938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2938: --- Affects Version/s: (was: 2.1-alpha-1) 2.1.x Fix Version/s: (was: Reviewed Pending Version Assignment) 2.1-alpha-1 Build error is ignored at the end of the build -- Key: MNG-2938 URL: http://jira.codehaus.org/browse/MNG-2938 Project: Maven 2 Issue Type: Bug Components: Command Line Affects Versions: 2.1.x Reporter: Carlos Sanchez Fix For: 2.1-alpha-1 On a build error you get BUILD ERROR and then BUILD SUCCESSFUL [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to construct build plan for: org.apache.maven.its.it0020:maven-it-it0020:maven-plugin:1.0-SNAPSHOT ( task-segment: [clean:clean, install, ... [INFO] [INFO] Total time: 1 second [INFO] Finished at: Thu Apr 05 16:27:47 PDT 2007 [INFO] Final Memory: 6M/11M [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 second [INFO] Finished at: Thu Apr 05 16:27:47 PDT 2007 [INFO] Final Memory: 6M/11M [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-574) Add version info to plugins.xml and cache that in plugin-registry.xml
[ http://jira.codehaus.org/browse/MNG-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-574. - Resolution: Fixed registry is not used anymore Add version info to plugins.xml and cache that in plugin-registry.xml - Key: MNG-574 URL: http://jira.codehaus.org/browse/MNG-574 Project: Maven 2 Issue Type: Improvement Components: Plugins and Lifecycle Reporter: Kenney Westerhof Priority: Minor Fix For: 2.1.x By caching that information locally, maven only has to check one url to see if a plugin is up-to-date, rather than open a connection for each plugin encountered. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-763) consider include source root
[ http://jira.codehaus.org/browse/MNG-763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99732 ] Jason van Zyl commented on MNG-763: --- What does this mean exactly? consider include source root Key: MNG-763 URL: http://jira.codehaus.org/browse/MNG-763 Project: Maven 2 Issue Type: New Feature Components: POM Reporter: Brett Porter Priority: Minor Fix For: 2.1.x this is something used by the native plugin but could be used by several plugins that deal with C/C++ and maybe other languages. We should consider adding it to the build section and the MavenProject object. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2940) Add a method to the embedder to list available versions of an artifact
[ http://jira.codehaus.org/browse/MNG-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99738 ] Carlos Sanchez commented on MNG-2940: - It encapsulates ArtifactMetadataSource.retrieveAvailableVersions and uses the same signature Add a method to the embedder to list available versions of an artifact -- Key: MNG-2940 URL: http://jira.codehaus.org/browse/MNG-2940 Project: Maven 2 Issue Type: New Feature Components: Embedding Affects Versions: 2.1.x Reporter: Carlos Sanchez Assignee: Jason van Zyl Fix For: Reviewed Pending Version Assignment Attachments: patch.txt, patch.txt I've added a method following the style of the resolve method already present public void resolve( Artifact artifact, List remoteRepositories, ArtifactRepository localRepository ) throws ArtifactResolutionException, ArtifactNotFoundException -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2940) Add a method to the embedder to list available versions of an artifact
[ http://jira.codehaus.org/browse/MNG-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99740 ] Jason van Zyl commented on MNG-2940: So what? It's wrong. Who cares what the existing signature is? The question is whether it makes any sense is what I'm asking you. In that it makes no sense to have multiple repositories, or specify the local repository when all the user wants is the set of versions. Add a method to the embedder to list available versions of an artifact -- Key: MNG-2940 URL: http://jira.codehaus.org/browse/MNG-2940 Project: Maven 2 Issue Type: New Feature Components: Embedding Affects Versions: 2.1.x Reporter: Carlos Sanchez Assignee: Jason van Zyl Fix For: Reviewed Pending Version Assignment Attachments: patch.txt, patch.txt I've added a method following the style of the resolve method already present public void resolve( Artifact artifact, List remoteRepositories, ArtifactRepository localRepository ) throws ArtifactResolutionException, ArtifactNotFoundException -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
