[jira] Closed: (MDEP-238) Wrong links on the web site
[ http://jira.codehaus.org/browse/MDEP-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran closed MDEP-238. - Resolution: Fixed Fix Version/s: 2.2 Assignee: Dan Tran (was: Brian Fox) fixed at Revision: 894564 Author: dantran Date: 12:06:02 AM, Wednesday, December 30, 2009 Message: MDEP-238: fixed bad links at examples/preparing-dependencies.html Modified : /maven/plugins/trunk/maven-dependency-plugin/src/site/apt/examples/preparing-dependencies.apt > Wrong links on the web site > --- > > Key: MDEP-238 > URL: http://jira.codehaus.org/browse/MDEP-238 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: All >Reporter: Karl Heinz Marbaise >Assignee: Dan Tran >Priority: Minor > Fix For: 2.2 > > > The web sites of the plugin do have some wrong links. > On the following page: > http://maven.apache.org/plugins/maven-dependency-plugin/examples/preparing-dependencies.html > the links (Analyze Mojo, Analyze-dep-mgt Mojo, Usage)on the bottom of the > page produce "Page Not Found" messages. -- 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: (MDEP-127) Take advantage of PLXCOMP-76
[ http://jira.codehaus.org/browse/MDEP-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran closed MDEP-127. - Resolution: Fixed Fix Version/s: 2.2 tested with internal build and committed at Revision: 894571 Author: dantran Date: 12:59:30 AM, Wednesday, December 30, 2009 Message: MDEP-127:upgrade to plexus-archiver-1.0-alpha-12, plexus-io-1.0-alpha-5, maven-plugin-16. Plus added missing dependencies reported by dependency:analyze Modified : /maven/plugins/trunk/maven-dependency-plugin/pom.xml > Take advantage of PLXCOMP-76 > > > Key: MDEP-127 > URL: http://jira.codehaus.org/browse/MDEP-127 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: unpack, unpack-dependencies >Affects Versions: 2.0-alpha-4 > Environment: xp,linux,solaris >Reporter: Dan Tran >Assignee: Dan Tran > Fix For: 2.2 > > Attachments: MDEP-127.diff > > > need to release plexus-archiver 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] Commented: (MDEP-142) Path with space makes the dependency:unpack goal fail
[
http://jira.codehaus.org/browse/MDEP-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204536#action_204536
]
Benjamin Bentmann commented on MDEP-142:
The new IT works, it fails on the grid's Ubuntu box.
> Path with space makes the dependency:unpack goal fail
> -
>
> Key: MDEP-142
> URL: http://jira.codehaus.org/browse/MDEP-142
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: unpack
>Affects Versions: 2.0-alpha-4, 2.0
> Environment: Mac OS X 10.5.1
> Java 1.5.0_13-b05-237
> Maven 2.0.8
>Reporter: Pierre-Arnaud Marcelot
>Assignee: Brian Fox
>Priority: Blocker
> Fix For: 2.2
>
> Attachments: AbstractDependencyPluginITCase.java,
> DuplicateFilesTest.java, pom.xml, pom.xml, pom.xml, pom.xml
>
>
> Configuration in pom.xml file:
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> launcher-macosx (unpack)
>
> generate-resources
>
> unpack
>
>
> true
>
> ${project.build.directory}/dependency-maven-plugin-markers/macosx
>
>
> org.apache.directory.studio
> launcher-macosx
> tar.gz
> ${studio-dir}-macosx
>
>
> org.eclipse.equinox.launcher.carbon
> macosx
> tar.gz
> ${studio-dir}-macosx/Apache Directory
> Studio.app/Contents/Resources/Java/plugins
>
>
>
>
>
>
>
>
> Maven output:
> [INFO]
>
> [INFO] Building Apache Directory Studio Build
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory
> /Users/pajbam/Development/Apache/studio-maven/studio/target
> [INFO] Deleting directory
> /Users/pajbam/Development/Apache/studio-maven/studio/target/classes
> [INFO] Deleting directory
> /Users/pajbam/Development/Apache/studio-maven/studio/target/test-classes
> [INFO] Deleting directory
> /Users/pajbam/Development/Apache/studio-maven/studio/target/site
> [INFO] [remote-resources:process {execution: default}]
> [INFO] [dependency:unpack {execution: launcher-macosx (unpack)}]
> [INFO] Configured Artifact:
> org.apache.directory.studio:launcher-macosx:?:tar.gz
> [INFO] Configured Artifact:
> org.eclipse.equinox.launcher.carbon:macosx:?:tar.gz
> [INFO] Unpacking
> /Users/pajbam/.m2/repository/org/apache/directory/studio/launcher-macosx/1.1.0/launcher-macosx-1.1.0.tar.gzto
>
> /Users/pajbam/Development/Apache/studio-maven/studio/target/ApacheDirectoryStudio-macosx
> with Includes null and excludes:null
> [INFO] Expanding
> /Users/pajbam/.m2/repository/org/apache/directory/studio/launcher-macosx/1.1.0/launcher-macosx-1.1.0.tar.gz
> to /tmp/tmp6522.tar
> [INFO] Expanding: /tmp/tmp6522.tar into
> /Users/pajbam/Development/Apache/studio-maven/studio/target/ApacheDirectoryStudio-macosx
> [WARNING] ---
> [WARNING] Standard error:
> [WARNING] ---
> [WARNING]
> [WARNING] ---
> [WARNING] Standard output:
> [WARNING] ---
> [WARNING] /bin/sh: line 0: cd:
> /Users/pajbam/Development/Apache/studio-maven/studio/target/ApacheDirectoryStudio-macosx/Apache:
> No such file or directory
> [WARNING] ---
> org.codehaus.plexus.archiver.ArchiverException: chmod exit code was: 1
> at
> org.codehaus.plexus.archiver.util.ArchiveEntryUtils.chmod(ArchiveEntryUtils.java:59)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipUnArchiver.extractFile(AbstractZipUnArchiver.java:236)
> at
> org.codehaus.plexus.archiver.tar.TarUnArchiver.execute(TarUnArchiver.java:92)
> at
> org.codehaus.plexus.archiver.tar.TarGZipUnArchiver.execute(TarGZipUnArchiver.java:76)
> at
> org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:108)
> at
> org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:266)
> at
> org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.unpackArtifact(UnpackMojo.java:122)
> at
> org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.execute(UnpackMojo.java:95)
> at
> o
[jira] Commented: (MDEP-142) Path with space makes the dependency:unpack goal fail
[
http://jira.codehaus.org/browse/MDEP-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204540#action_204540
]
Dan Tran commented on MDEP-142:
---
- able to get the test fails on my redhat 5 box.
- went a head to upgrade plexus-utils-1.5.1 per MDEP-138 and its associated
plexus fix.
unpack IT test are now passed on both windows and linux
Revision: 894584
Author: dantran
Date: 2:48:22 AM, Wednesday, December 30, 2009
Message:
MDEP-138:update plexus-utils-1.5.1 to fix space in path issue which only found
on linux. This will fix MDEP-142 as well
Modified : /maven/plugins/trunk/maven-dependency-plugin/pom.xml
> Path with space makes the dependency:unpack goal fail
> -
>
> Key: MDEP-142
> URL: http://jira.codehaus.org/browse/MDEP-142
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: unpack
>Affects Versions: 2.0-alpha-4, 2.0
> Environment: Mac OS X 10.5.1
> Java 1.5.0_13-b05-237
> Maven 2.0.8
>Reporter: Pierre-Arnaud Marcelot
>Assignee: Brian Fox
>Priority: Blocker
> Fix For: 2.2
>
> Attachments: AbstractDependencyPluginITCase.java,
> DuplicateFilesTest.java, pom.xml, pom.xml, pom.xml, pom.xml
>
>
> Configuration in pom.xml file:
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> launcher-macosx (unpack)
>
> generate-resources
>
> unpack
>
>
> true
>
> ${project.build.directory}/dependency-maven-plugin-markers/macosx
>
>
> org.apache.directory.studio
> launcher-macosx
> tar.gz
> ${studio-dir}-macosx
>
>
> org.eclipse.equinox.launcher.carbon
> macosx
> tar.gz
> ${studio-dir}-macosx/Apache Directory
> Studio.app/Contents/Resources/Java/plugins
>
>
>
>
>
>
>
>
> Maven output:
> [INFO]
>
> [INFO] Building Apache Directory Studio Build
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory
> /Users/pajbam/Development/Apache/studio-maven/studio/target
> [INFO] Deleting directory
> /Users/pajbam/Development/Apache/studio-maven/studio/target/classes
> [INFO] Deleting directory
> /Users/pajbam/Development/Apache/studio-maven/studio/target/test-classes
> [INFO] Deleting directory
> /Users/pajbam/Development/Apache/studio-maven/studio/target/site
> [INFO] [remote-resources:process {execution: default}]
> [INFO] [dependency:unpack {execution: launcher-macosx (unpack)}]
> [INFO] Configured Artifact:
> org.apache.directory.studio:launcher-macosx:?:tar.gz
> [INFO] Configured Artifact:
> org.eclipse.equinox.launcher.carbon:macosx:?:tar.gz
> [INFO] Unpacking
> /Users/pajbam/.m2/repository/org/apache/directory/studio/launcher-macosx/1.1.0/launcher-macosx-1.1.0.tar.gzto
>
> /Users/pajbam/Development/Apache/studio-maven/studio/target/ApacheDirectoryStudio-macosx
> with Includes null and excludes:null
> [INFO] Expanding
> /Users/pajbam/.m2/repository/org/apache/directory/studio/launcher-macosx/1.1.0/launcher-macosx-1.1.0.tar.gz
> to /tmp/tmp6522.tar
> [INFO] Expanding: /tmp/tmp6522.tar into
> /Users/pajbam/Development/Apache/studio-maven/studio/target/ApacheDirectoryStudio-macosx
> [WARNING] ---
> [WARNING] Standard error:
> [WARNING] ---
> [WARNING]
> [WARNING] ---
> [WARNING] Standard output:
> [WARNING] ---
> [WARNING] /bin/sh: line 0: cd:
> /Users/pajbam/Development/Apache/studio-maven/studio/target/ApacheDirectoryStudio-macosx/Apache:
> No such file or directory
> [WARNING] ---
> org.codehaus.plexus.archiver.ArchiverException: chmod exit code was: 1
> at
> org.codehaus.plexus.archiver.util.ArchiveEntryUtils.chmod(ArchiveEntryUtils.java:59)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipUnArchiver.extractFile(AbstractZipUnArchiver.java:236)
> at
> org.codehaus.plexus.archiver.tar.TarUnArchiver.execute(TarUnArchiver.java:92)
> at
> org.codehaus.plexus.archiver.tar.TarGZipUnArchiver.execute(TarGZipUnArchiver.java:76)
> at
> org.codehaus.plexus.arch
[jira] Closed: (MDEP-138) unpack of tar files fail with ArchiverException: chmod exit code was: 1
[ http://jira.codehaus.org/browse/MDEP-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran closed MDEP-138. - Resolution: Fixed Fix Version/s: 2.2 Assignee: Dan Tran (was: Brian Fox) unpack IT added see MDEP-142 fixed at Revision: 894584 Author: dantran Date: 2:48:22 AM, Wednesday, December 30, 2009 Message: MDEP-138:update plexus-utils-1.5.1 to fix space in path issue which only found on linux. This will fix MDEP-142 as well Modified : /maven/plugins/trunk/maven-dependency-plugin/pom.xml > unpack of tar files fail with ArchiverException: chmod exit code was: 1 > --- > > Key: MDEP-138 > URL: http://jira.codehaus.org/browse/MDEP-138 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: unpack >Affects Versions: 2.0 >Reporter: Brian Fox >Assignee: Dan Tran > Fix For: 2.2 > > > Upgrade to new plexus-archiver when the tar issue is fixed. see PLXCOMP-93 -- 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: (MDEP-142) Path with space makes the dependency:unpack goal fail
[
http://jira.codehaus.org/browse/MDEP-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Tran closed MDEP-142.
-
Resolution: Duplicate
Assignee: Dan Tran (was: Brian Fox)
> Path with space makes the dependency:unpack goal fail
> -
>
> Key: MDEP-142
> URL: http://jira.codehaus.org/browse/MDEP-142
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: unpack
>Affects Versions: 2.0-alpha-4, 2.0
> Environment: Mac OS X 10.5.1
> Java 1.5.0_13-b05-237
> Maven 2.0.8
>Reporter: Pierre-Arnaud Marcelot
>Assignee: Dan Tran
>Priority: Blocker
> Fix For: 2.2
>
> Attachments: AbstractDependencyPluginITCase.java,
> DuplicateFilesTest.java, pom.xml, pom.xml, pom.xml, pom.xml
>
>
> Configuration in pom.xml file:
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> launcher-macosx (unpack)
>
> generate-resources
>
> unpack
>
>
> true
>
> ${project.build.directory}/dependency-maven-plugin-markers/macosx
>
>
> org.apache.directory.studio
> launcher-macosx
> tar.gz
> ${studio-dir}-macosx
>
>
> org.eclipse.equinox.launcher.carbon
> macosx
> tar.gz
> ${studio-dir}-macosx/Apache Directory
> Studio.app/Contents/Resources/Java/plugins
>
>
>
>
>
>
>
>
> Maven output:
> [INFO]
>
> [INFO] Building Apache Directory Studio Build
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory
> /Users/pajbam/Development/Apache/studio-maven/studio/target
> [INFO] Deleting directory
> /Users/pajbam/Development/Apache/studio-maven/studio/target/classes
> [INFO] Deleting directory
> /Users/pajbam/Development/Apache/studio-maven/studio/target/test-classes
> [INFO] Deleting directory
> /Users/pajbam/Development/Apache/studio-maven/studio/target/site
> [INFO] [remote-resources:process {execution: default}]
> [INFO] [dependency:unpack {execution: launcher-macosx (unpack)}]
> [INFO] Configured Artifact:
> org.apache.directory.studio:launcher-macosx:?:tar.gz
> [INFO] Configured Artifact:
> org.eclipse.equinox.launcher.carbon:macosx:?:tar.gz
> [INFO] Unpacking
> /Users/pajbam/.m2/repository/org/apache/directory/studio/launcher-macosx/1.1.0/launcher-macosx-1.1.0.tar.gzto
>
> /Users/pajbam/Development/Apache/studio-maven/studio/target/ApacheDirectoryStudio-macosx
> with Includes null and excludes:null
> [INFO] Expanding
> /Users/pajbam/.m2/repository/org/apache/directory/studio/launcher-macosx/1.1.0/launcher-macosx-1.1.0.tar.gz
> to /tmp/tmp6522.tar
> [INFO] Expanding: /tmp/tmp6522.tar into
> /Users/pajbam/Development/Apache/studio-maven/studio/target/ApacheDirectoryStudio-macosx
> [WARNING] ---
> [WARNING] Standard error:
> [WARNING] ---
> [WARNING]
> [WARNING] ---
> [WARNING] Standard output:
> [WARNING] ---
> [WARNING] /bin/sh: line 0: cd:
> /Users/pajbam/Development/Apache/studio-maven/studio/target/ApacheDirectoryStudio-macosx/Apache:
> No such file or directory
> [WARNING] ---
> org.codehaus.plexus.archiver.ArchiverException: chmod exit code was: 1
> at
> org.codehaus.plexus.archiver.util.ArchiveEntryUtils.chmod(ArchiveEntryUtils.java:59)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipUnArchiver.extractFile(AbstractZipUnArchiver.java:236)
> at
> org.codehaus.plexus.archiver.tar.TarUnArchiver.execute(TarUnArchiver.java:92)
> at
> org.codehaus.plexus.archiver.tar.TarGZipUnArchiver.execute(TarGZipUnArchiver.java:76)
> at
> org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:108)
> at
> org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:266)
> at
> org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.unpackArtifact(UnpackMojo.java:122)
> at
> org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.execute(UnpackMojo.java:95)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(D
[jira] Created: (MSHADE-70) Artifact filter does not recognize pattern ending with slash
Artifact filter does not recognize pattern ending with slash
Key: MSHADE-70
URL: http://jira.codehaus.org/browse/MSHADE-70
Project: Maven 2.x Shade Plugin
Issue Type: Bug
Affects Versions: 1.2.2
Reporter: Benjamin Bentmann
Priority: Minor
A configuration like
{code:xml}
foo:bar
org/apache/
{code}
fails to exclude paths starting with "org/apache/". In other words, the pattern
"org/apache/" is not understood as a shorthand for "org/apache/\*\*" (cf.
[Patterns|http://ant.apache.org/manual/dirtasks.html#patterns]).
--
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: (MSHADE-70) Artifact filter does not recognize pattern ending with slash
[
http://jira.codehaus.org/browse/MSHADE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MSHADE-70.
---
Resolution: Fixed
Fix Version/s: 1.3
Assignee: Benjamin Bentmann
Fixed in [r894596|http://svn.apache.org/viewvc?view=revision&revision=894596].
> Artifact filter does not recognize pattern ending with slash
>
>
> Key: MSHADE-70
> URL: http://jira.codehaus.org/browse/MSHADE-70
> Project: Maven 2.x Shade Plugin
> Issue Type: Bug
>Affects Versions: 1.2.2
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
>Priority: Minor
> Fix For: 1.3
>
>
> A configuration like
> {code:xml}
>
>
>
> foo:bar
>
> org/apache/
>
>
>
>
> {code}
> fails to exclude paths starting with "org/apache/". In other words, the
> pattern "org/apache/" is not understood as a shorthand for "org/apache/\*\*"
> (cf. [Patterns|http://ant.apache.org/manual/dirtasks.html#patterns]).
--
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: (MDEP-171) link to "Unpacking the Project Dependencies" is broken - website
[ http://jira.codehaus.org/browse/MDEP-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Sellers reopened MDEP-171: -- Still looks broken to me. It's in the "example" section as follows: Examples The following examples show how to use the dependency plugin in more advanced use-cases: * Instructions on how to prepare your dependencies for upgrade to Maven 2.0.6 / 2.1. * Copying Specific Artifacts * Copying Project Dependencies * Unpacking Specific Artifacts * Unpacking the Project Dependencies > link to "Unpacking the Project Dependencies" is broken - website > > > Key: MDEP-171 > URL: http://jira.codehaus.org/browse/MDEP-171 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Jim Sellers >Assignee: Brian Fox >Priority: Trivial > Fix For: 2.1 > > > On the website [1] the link for "Unpacking the Project Dependencies" goes to > the "Copying Project Dependencies" page. It should go to the correct page > [2]. > [1] http://maven.apache.org/plugins/maven-dependency-plugin/ > [2] > http://maven.apache.org/plugins/maven-dependency-plugin/examples/unpacking-project-dependencies.html -- 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: (MEAR-119) Maven-ear-plugin seems not to expand/filter properties in classifiers
[
http://jira.codehaus.org/browse/MEAR-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204555#action_204555
]
Stephane Nicoll commented on MEAR-119:
--
this has nothing to do with the maven ear plugin I would say. Please provide a
simple project that reproduces the problem
> Maven-ear-plugin seems not to expand/filter properties in classifiers
> -
>
> Key: MEAR-119
> URL: http://jira.codehaus.org/browse/MEAR-119
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Mikhail Olifirenko
>
> The probable issue deals with using of classified transitive dependencies,
> where classifiers are specified by profiles.
> There are 3 modules: ear-application, ejb1 and ejb2 is used by ejb1 module.
> Ear application ear-application includes EJB modules ejb1 and ejb2. ejb1
> depends on ejb2.
> Let's ear-application pom.xml contains:
> ...
>
> org.apache.maven.plugins
> maven-ear-plugin
> 2.4
>
>${var}
>5
>
>
> com.softcomputer
> ejb1
> ${var}
>
>
> com.softcomputer
> ejb2
> ${var}
>
> ...
> Pom.xml of ejb1 contains:
> ...
>ejb1
>com.softcomputer
>First EJB module
>ejb
>
>
> com.softcomputer
> ejb2
> ejb
> ${var}
>
> ...
> Attempt to build specified enterprise application leads to:
> ...
> INFO] Failed to resolve artifact.
> Missing:
> --
> 1) com.softcomputer:ejb2:ejb:${var}:1.0.0-05-01
> ...
> Path to dependency:
>1) com.softcomputer:ear-application:ear:1.0.0-07-05
>2) com.softcomputer:ejb1:ejb:expandedVar:1.0.0-05-01
>3) com.softcomputer:ejb2:ejb:${var}:1.0.0-05-01
> ...
> Where ${var} should be expanded with expandedVar value.
--
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: (MASSEMBLY-460) default file mode of 7777 leads to trouble
default file mode of leads to trouble --- Key: MASSEMBLY-460 URL: http://jira.codehaus.org/browse/MASSEMBLY-460 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-4 Reporter: Benson Margulies We are getting build failures as follows. 1: why and not 0777? Why a WARNING if the build is going to quit? Why quit? [WARNING] Standard output: [WARNING] --- [WARNING] chmod: changing permissions of `/basis/users/skearns/svn/trunk_mirror/ greenhouse/jester/distribution/target/jester-all.dir/jester/release_package' (re quested: , actual: 6777): Operation not permitted [WARNING] --- [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to create assembly: Error creating assembly archive all: chmod exi t code was: 1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-460) default file mode of 7777 leads to trouble
[ http://jira.codehaus.org/browse/MASSEMBLY-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204564#action_204564 ] Benson Margulies commented on MASSEMBLY-460: This only happens if we have a element without an explicit . > default file mode of leads to trouble > --- > > Key: MASSEMBLY-460 > URL: http://jira.codehaus.org/browse/MASSEMBLY-460 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-4 >Reporter: Benson Margulies > > We are getting build failures as follows. 1: why and not 0777? Why a > WARNING if the build is going to quit? Why quit? > [WARNING] Standard output: > [WARNING] --- > [WARNING] chmod: changing permissions of > `/basis/users/skearns/svn/trunk_mirror/ > greenhouse/jester/distribution/target/jester-all.dir/jester/release_package' > (re > quested: , actual: 6777): Operation not permitted > > [WARNING] --- > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to create assembly: Error creating assembly archive all: chmod > exi > t code was: 1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3610) Endless loop with relocation jtds:jtds
[ http://jira.codehaus.org/browse/MNG-3610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204568#action_204568 ] Jason van Zyl commented on MNG-3610: Relocation works fine in 3.0: bash-3.2$ mvn clean install [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building dependencybug (jar) 1.0-SNAPSHOT [INFO] Downloading: http://repository.sonatype.org/content/groups/sonatype-grid/jtds/jtds/1.2/jtds-1.2.pom 972 B downloaded at 1.4 KB/sec [WARNING] While downloading jtds:jtds:1.2 This artifact has been relocated to net.sourceforge.jtds:jtds:1.2. Downloading: http://repository.sonatype.org/content/groups/sonatype-grid/net/sourceforge/jtds/jtds/1.2/jtds-1.2.pom 871 B downloaded at 0.9 KB/sec Downloading: http://repository.sonatype.org/content/groups/sonatype-grid/net/sourceforge/jtds/jtds/1.2/jtds-1.2.jar 279 KB downloaded at 332.1 KB/sec [INFO] [INFO] --- maven-clean-plugin:2.3:clean (default-clean) @ dependencybug --- [INFO] [INFO] --- maven-resources-plugin:2.4.1:resources (default-resources) @ dependencybug --- [WARNING] Using platform encoding (MacRoman actually) to copy filtered resources, i.e. build is platform dependent! [INFO] skip non existing resourceDirectory /Users/jvanzyl/work/dependencybug/src/main/resources [INFO] [INFO] --- maven-compiler-plugin:2.0.2:compile (default-compile) @ dependencybug --- Downloading: http://repository.sonatype.org/content/groups/sonatype-grid/org/apache/maven/plugins/maven-compiler-plugin/2.0.2/maven-compiler-plugin-2.0.2.pom 3 KB downloaded at 3.8 KB/sec [INFO] Compiling 1 source file to /Users/jvanzyl/work/dependencybug/target/classes [INFO] [INFO] --- maven-resources-plugin:2.4.1:testResources (default-testResources) @ dependencybug --- [WARNING] Using platform encoding (MacRoman actually) to copy filtered resources, i.e. build is platform dependent! [INFO] skip non existing resourceDirectory /Users/jvanzyl/work/dependencybug/src/test/resources [INFO] [INFO] --- maven-compiler-plugin:2.0.2:testCompile (default-testCompile) @ dependencybug --- [INFO] Compiling 1 source file to /Users/jvanzyl/work/dependencybug/target/test-classes [INFO] [INFO] --- maven-surefire-plugin:2.4.3:test (default-test) @ dependencybug --- [INFO] Surefire report directory: /Users/jvanzyl/work/dependencybug/target/surefire-reports --- T E S T S --- Running com.mycompany.dedendencybug.AppTest class net.sourceforge.jtds.jdbc.Driver Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.041 sec Results : Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] --- maven-jar-plugin:2.2:jar (default-jar) @ dependencybug --- [INFO] Building jar: /Users/jvanzyl/work/dependencybug/target/dependencybug-1.0-SNAPSHOT.jar [INFO] [INFO] --- maven-install-plugin:2.3:install (default-install) @ dependencybug --- [INFO] Installing /Users/jvanzyl/work/dependencybug/target/dependencybug-1.0-SNAPSHOT.jar to /Users/jvanzyl/.m2/repository/com/mycompany/dependencybug/1.0-SNAPSHOT/dependencybug-1.0-SNAPSHOT.jar [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 9.434s [INFO] Finished at: Wed Dec 30 11:12:23 EST 2009 [INFO] Final Memory: 10M/80M [INFO] > Endless loop with relocation jtds:jtds > -- > > Key: MNG-3610 > URL: http://jira.codehaus.org/browse/MNG-3610 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.7, 2.0.8, 2.0.9 > Environment: WinXP maven 2.0.9 >Reporter: bartvdc >Assignee: Brian Fox >Priority: Minor > Fix For: 3.0-alpha-6 > > Attachments: dependencybug.zip > > > I'm getting an endless loop when installing a project using jtds:jtds. > I can see in the pom that it's relocated to net.sourceforge.jtds. > Output says : > [WARNING] While downloading net.sourceforge.jtds:jtds:1.2 > This artifact has been relocated to net.sourceforge.jtds:jtds:1.2. -- 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-3610) Endless loop with relocation jtds:jtds
[ http://jira.codehaus.org/browse/MNG-3610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-3610. -- Resolution: Fixed Fix Version/s: (was: 2.2.2) 3.0-alpha-6 > Endless loop with relocation jtds:jtds > -- > > Key: MNG-3610 > URL: http://jira.codehaus.org/browse/MNG-3610 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.7, 2.0.8, 2.0.9 > Environment: WinXP maven 2.0.9 >Reporter: bartvdc >Assignee: Brian Fox >Priority: Minor > Fix For: 3.0-alpha-6 > > Attachments: dependencybug.zip > > > I'm getting an endless loop when installing a project using jtds:jtds. > I can see in the pom that it's relocated to net.sourceforge.jtds. > Output says : > [WARNING] While downloading net.sourceforge.jtds:jtds:1.2 > This artifact has been relocated to net.sourceforge.jtds:jtds:1.2. -- 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: (MECLIPSE-601) to-maven mojo install source plugins as ordinay plugins. It should install the source plugins as classified as 'sources'
[ http://jira.codehaus.org/browse/MECLIPSE-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204569#action_204569 ] Hasan Ceylan commented on MECLIPSE-601: --- Thanks for the inclusion of the patch Peter... Any news on that issue? Hasan > to-maven mojo install source plugins as ordinay plugins. It should install > the source plugins as classified as 'sources' > > > Key: MECLIPSE-601 > URL: http://jira.codehaus.org/browse/MECLIPSE-601 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: PDE support >Affects Versions: 2.7 > Environment: N/A >Reporter: Hasan Ceylan >Assignee: Peter Lynch > Attachments: source-plugin.patch, source-plugin.patch, > source-plugin.patch > > > to-maven mojo install source plugins as ordinay plugins. It should install > the source plugins as classified as 'sources' > Say you have the source plugins along with your plugins. ie: here's what you > would get: > [hcey...@ceylan ~]$ ll > /home/hceylan/.m2/repository/org/eclipse/core/runtime/3.5.100-v20090629/ > -rw-rw-r-- 1 hceylan hceylan 69652 2009-09-10 22:12 > runtime-3.5.100-v20090629.jar > -rw-rw-r-- 1 hceylan hceylan 1741 2009-09-10 22:12 > runtime-3.5.100-v20090629.pom > drw-rw-r-- 1 hceylan hceylan 86072 2009-09-10 22:12 source > Instead you should get the following: > [hcey...@ceylan ~]$ ll > /home/hceylan/.m2/repository/org/eclipse/core/runtime/3.5.100-v20090629/ > -rw-rw-r-- 1 hceylan hceylan 69652 2009-09-10 22:12 > runtime-3.5.100-v20090629.jar > -rw-rw-r-- 1 hceylan hceylan 1741 2009-09-10 22:12 > runtime-3.5.100-v20090629.pom > -rw-rw-r-- 1 hceylan hceylan 86072 2009-09-10 22:12 > runtime-3.5.100-v20090629-sources.jar > Attached patch resolves that issue. -- 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-3668) maven-eclipse-plugin 2.5 is failing with java.lang.LinkageError
[
http://jira.codehaus.org/browse/MNG-3668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204572#action_204572
]
Jason van Zyl commented on MNG-3668:
Working now with 3.0-alpha-5 and the maven-eclipse-plugin 2.7:
bash-3.2$ mvn eclipse:eclipse
[INFO] Scanning for projects...
Downloading:
http://repository.sonatype.org/content/groups/sonatype-grid/org/apache/maven/plugins/maven-metadata.xml
9 KB downloaded at 9.9 KB/sec
[INFO]
[INFO]
[INFO] Building dependencybug (jar) 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-eclipse-plugin:2.7:eclipse (default-cli) @ dependencybug ---
[INFO] Using Eclipse Workspace: null
[INFO] Adding default classpath container:
org.eclipse.jdt.launching.JRE_CONTAINER
[WARNING] While downloading jtds:jtds:1.2
This artifact has been relocated to net.sourceforge.jtds:jtds:1.2.
[INFO] File /Users/jvanzyl/work/dependencybug/.project already exists.
Additional settings will be preserved, run mvn eclipse:clean if you want
old settings to be removed.
[INFO] Wrote Eclipse project for "dependencybug" to
/Users/jvanzyl/work/dependencybug.
[INFO]
Sources for some artifacts are not available.
Please run the same goal with the -DdownloadSources=true parameter in
order to check remote repositories for sources.
List of artifacts without a source archive:
o net.sourceforge.jtds:jtds:1.2
o junit:junit:4.4
Javadoc for some artifacts is not available.
Please run the same goal with the -DdownloadJavadocs=true parameter in
order to check remote repositories for javadoc.
List of artifacts without a javadoc archive:
o net.sourceforge.jtds:jtds:1.2
o junit:junit:4.4
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 3.815s
[INFO] Finished at: Wed Dec 30 11:24:05 EST 2009
[INFO] Final Memory: 8M/80M
[INFO]
> maven-eclipse-plugin 2.5 is failing with java.lang.LinkageError
> ---
>
> Key: MNG-3668
> URL: http://jira.codehaus.org/browse/MNG-3668
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.0-alpha-1
>Reporter: Eugene Kuleshov
> Fix For: 3.x
>
>
> eclipse:eclipse goal in maven-eclipse-plugin 2.5 is failing with the
> following exception. same thing is working with 2.4
> {code}
> Exception in thread "main" java.lang.LinkageError: loader constraint
> violation: when resolving method
>
> "org.codehaus.plexus.util.xml.Xpp3DomWriter.write(Lorg/codehaus/plexus/util/xml/XMLWriter;Lorg/codehaus/plexus/util/xml/Xpp3Dom;)V"
>
> the class loader (instance of
> org/codehaus/plexus/classworlds/realm/ClassRealm) of the current class,
> org/apache/maven/plugin/eclipse/writers/wtp/EclipseWtpApplicationXMLWriter,
> and the class loader (instance of
> org/codehaus/plexus/classworlds/realm/ClassRealm)
> for resolved class, org/codehaus/plexus/util/xml/Xpp3DomWriter, have
> different Class objects for the type
> org/codehaus/plexus/util/xml/XMLWriter used in the signature
> at
> org.apache.maven.plugin.eclipse.writers.wtp.EclipseWtpApplicationXMLWriter.writePrettyXmlFile(EclipseWtpApplicationXMLWriter.java:624)
> at
> org.apache.maven.plugin.eclipse.writers.wtp.EclipseWtpApplicationXMLWriter.write(EclipseWtpApplicationXMLWriter.java:157)
> at
> org.apache.maven.plugin.eclipse.EclipsePlugin.writeConfiguration(EclipsePlugin.java:957)
> at
> org.apache.maven.plugin.ide.AbstractIdeSupportMojo.execute(AbstractIdeSupportMojo.java:494)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:577)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149)
> at
> org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223)
> at
> org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:
[jira] Closed: (MNG-3668) maven-eclipse-plugin 2.5 is failing with java.lang.LinkageError
[
http://jira.codehaus.org/browse/MNG-3668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-3668.
--
Resolution: Fixed
> maven-eclipse-plugin 2.5 is failing with java.lang.LinkageError
> ---
>
> Key: MNG-3668
> URL: http://jira.codehaus.org/browse/MNG-3668
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.0-alpha-1
>Reporter: Eugene Kuleshov
> Fix For: 3.x
>
>
> eclipse:eclipse goal in maven-eclipse-plugin 2.5 is failing with the
> following exception. same thing is working with 2.4
> {code}
> Exception in thread "main" java.lang.LinkageError: loader constraint
> violation: when resolving method
>
> "org.codehaus.plexus.util.xml.Xpp3DomWriter.write(Lorg/codehaus/plexus/util/xml/XMLWriter;Lorg/codehaus/plexus/util/xml/Xpp3Dom;)V"
>
> the class loader (instance of
> org/codehaus/plexus/classworlds/realm/ClassRealm) of the current class,
> org/apache/maven/plugin/eclipse/writers/wtp/EclipseWtpApplicationXMLWriter,
> and the class loader (instance of
> org/codehaus/plexus/classworlds/realm/ClassRealm)
> for resolved class, org/codehaus/plexus/util/xml/Xpp3DomWriter, have
> different Class objects for the type
> org/codehaus/plexus/util/xml/XMLWriter used in the signature
> at
> org.apache.maven.plugin.eclipse.writers.wtp.EclipseWtpApplicationXMLWriter.writePrettyXmlFile(EclipseWtpApplicationXMLWriter.java:624)
> at
> org.apache.maven.plugin.eclipse.writers.wtp.EclipseWtpApplicationXMLWriter.write(EclipseWtpApplicationXMLWriter.java:157)
> at
> org.apache.maven.plugin.eclipse.EclipsePlugin.writeConfiguration(EclipsePlugin.java:957)
> at
> org.apache.maven.plugin.ide.AbstractIdeSupportMojo.execute(AbstractIdeSupportMojo.java:494)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:577)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149)
> at
> org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223)
> at
> org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1)
> at
> org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:903)
> at
> org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304)
> at
> org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:31)
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSHADE-71) Adjust plexus component descriptors after relocation
Adjust plexus component descriptors after relocation
Key: MSHADE-71
URL: http://jira.codehaus.org/browse/MSHADE-71
Project: Maven 2.x Shade Plugin
Issue Type: Improvement
Affects Versions: 1.2.2
Reporter: Benjamin Bentmann
The {{components.xml}} refers to classes. The lack of relocation support for
the descriptor makes it currently impossible to privately use a Plexus
component by relocating it.
--
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: (MSHADE-71) Adjust plexus component descriptors after relocation
[
http://jira.codehaus.org/browse/MSHADE-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MSHADE-71.
---
Resolution: Fixed
Fix Version/s: 1.3
Assignee: Benjamin Bentmann
Done in [r894664|http://svn.apache.org/viewvc?view=revision&revision=894664].
> Adjust plexus component descriptors after relocation
>
>
> Key: MSHADE-71
> URL: http://jira.codehaus.org/browse/MSHADE-71
> Project: Maven 2.x Shade Plugin
> Issue Type: Improvement
>Affects Versions: 1.2.2
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
> Fix For: 1.3
>
>
> The {{components.xml}} refers to classes. The lack of relocation support for
> the descriptor makes it currently impossible to privately use a Plexus
> component by relocating it.
--
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-2931) DefaultArtifactCollector changes the version of the originatingArtifact if it's in the dependencyManagement with another version
[ http://jira.codehaus.org/browse/MNG-2931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2931. -- Resolution: Cannot Reproduce Fix Version/s: (was: 2.2.2) > DefaultArtifactCollector changes the version of the originatingArtifact if > it's in the dependencyManagement with another version > > > Key: MNG-2931 > URL: http://jira.codehaus.org/browse/MNG-2931 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.5, 2.0.6 >Reporter: Carlos Sanchez > Attachments: MNG-2931.patch > > > DefaultDependencyTreeBuilder > https://svn.apache.org/repos/asf/maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/shared/dependency/tree/DefaultDependencyTreeBuilder.java > calls collect like this > collector.collect( project.getDependencyArtifacts(), > project.getArtifact(), managedVersions, repository, >project.getRemoteArtifactRepositories(), > metadataSource, null, >Collections.singletonList( listener ) ); > Problem: > This pom > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-component-api/1.0-alpha-22/plexus-component-api-1.0-alpha-22.pom > extends > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-containers/1.0-alpha-22/plexus-containers-1.0-alpha-22.pom > that in dependencyManagement has > org.codehaus.plexus:plexus-component-api:1.0-alpha-19 > so during collect project.getArtifact().getVersion() is changed to the > managedVersion instead of the original one > Either this is a bug or an exception should be thrown when > originatingArtifact is in managedVersions -- 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-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ http://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3092: --- Fix Version/s: (was: 2.2.2) 3.0-alpha-7 > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: http://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Mark Hobson > Fix For: 3.0-alpha-7 > > Attachments: MNG-3092.patch > > > Contrary to the 2.0 design docs: > "Resolution of dependency ranges should not resolve to a snapshot > (development version) unless it is included as an explicit boundary." > -- from > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification > The following is equates to true: > VersionRange.createFromVersionSpec( "[1.0,1.1]" ).containsVersion( new > DefaultArtifactVersion( "1.1-SNAPSHOT" ) ) > The attached patch only allows snapshot versions to be contained in a range > if they are equal to one of the boundaries. Note that this is a strict > equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2994) Snapshot repositories are not checked when using ranges
[ http://jira.codehaus.org/browse/MNG-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2994: --- Fix Version/s: (was: 2.2.2) 3.0-alpha-7 > Snapshot repositories are not checked when using ranges > --- > > Key: MNG-2994 > URL: http://jira.codehaus.org/browse/MNG-2994 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.6 > Environment: Windows XP, Cygwin >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.0-alpha-7 > > Attachments: MNG-2994-2.patch, MNG-2994-3.patch, > MNG-2994-core-it.patch, patch.txt > > > The attached patch demonstrates the problem by adding it0121. If the test > repository has releases enabled, the test passes, when they are disabled, the > test fails. This appears to be due to DefaultArtifact.isSnapshot returning > false for unresolved ranges, thus causing snapshot repositories to be > disabled when resolving artifacts. -- 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-4001) Unable to resolve Dashboard mojo from Central
[
http://jira.codehaus.org/browse/MNG-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-4001.
--
Resolution: Not A Bug
Fix Version/s: (was: 2.2.x)
> Unable to resolve Dashboard mojo from Central
> -
>
> Key: MNG-4001
> URL: http://jira.codehaus.org/browse/MNG-4001
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Sites & Reporting
>Affects Versions: 2.0.9
> Environment: Windows, JDK 1.6
>Reporter: Anthony Whitford
>Assignee: Brett Porter
> Attachments: dashbug.zip
>
>
> I have a simple test project that declares the dashboard-maven-plugin (see
> http://mojo.codehaus.org/dashboard-maven-plugin/usage.html ).
> Note that the usage does explicitly state that the Codehaus repository must
> be specified as a plugin repository...
> However, according to:
> http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html
> I'm pretty sure that Maven should be able to resolve the
> dashboard-maven-plugin from the central repo.
> I validated that the [dashboard-maven-plugin residing in
> central|http://repo1.maven.org/maven2/org/codehaus/mojo/dashboard-maven-plugin/1.0.0-beta-1/]
> is indeed the same artifact as that which lives at the [codehaus
> repository|http://repository.codehaus.org/org/codehaus/mojo/dashboard-maven-plugin/1.0.0-beta-1/].
> But as you can see from my attached test case, the codehaus mojo is NOT being
> resolved without the special plugin repository defined. When running
> {noformat}mvn dashboard:dashboard{noformat}, I get the following error
> message:
> {noformat}
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'dashboard'.
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] The plugin 'org.apache.maven.plugins:maven-dashboard-plugin' does not
> exist or no valid version could be found
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: < 1 second
> [INFO] Finished at: Sat Jan 24 12:40:55 PST 2009
> [INFO] Final Memory: 1M/254M
> [INFO]
> {noformat}
> If you edit the pom.xml to uncomment out the plugin repository declaration
> for codehaus, it works as one would expect.
> My understanding is that the only reason why the Dashboard Usage mentions
> their plugin repository is because the artifact was not available on the
> central repository -- but it certainly is today.
> I also thought that perhaps the maven-metadata.xml might be incorrect
> (perhaps the dashboard plugin prefix is missing or different). I checked:
> * http://repo1.maven.org/maven2/org/codehaus/mojo/maven-metadata.xml
> * http://repository.codehaus.org/org/codehaus/mojo/maven-metadata.xml
> and they both look OK to me... I clearly see:{code:xml}
>
> Maven Dashboard Report Plugin
> dashboard
> dashboard-maven-plugin
>
> {code}
> And I don't see any plugin with a dashboard prefix specified as an Apache
> Maven Plugin here:
> * http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-metadata.xml
> If I explicitly specify the dashboard plugin like: {noformat}mvn
> org.codehaus.mojo:dashboard-maven-plugin:dashboard{noformat}
> that works...
> Overall, I am recording a bug because the
> [documentation|http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html]
> states:{quote}
> Maven will always search the following groupId's after searching any plugin
> groups specified in the user's settings:
> * org.apache.maven.plugins
> * org.codehaus.mojo
> {quote}
> I don't see this being done.
> Finally, I even tried adding a {{pluginGroups}} to my
> {{settings.xml}}:{code:xml}
>
> org.codehaus.mojo
>
> {code}
> But that did not work either...
--
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-3235) Profiles in settings.xml not loaded when running maven without a POM
[
http://jira.codehaus.org/browse/MNG-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-3235:
---
Fix Version/s: (was: 3.x)
3.0-alpha-7
> Profiles in settings.xml not loaded when running maven without a POM
>
>
> Key: MNG-3235
> URL: http://jira.codehaus.org/browse/MNG-3235
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Settings
>Affects Versions: 2.0.7
>Reporter: Duncan Doyle
> Fix For: 3.0-alpha-7
>
>
> I've created a custom Maven2 plugin for our SCM system (CA Harvest). This
> plugin is deployed in our internal remote repository. This remote repository
> is configured as a pluginRepository in my 'settings.xml ' file. The
> in which this repository is configured is loaded using the
> section. The plugin's groupId ('org.test.tools.maven.harvest') has been
> specified in the section in my 'settings.xml' file.
> The plugin's 'checkout' goal needs to be executed from the commandline
> without a POM (because the project's POM is in the SCM system). When I
> execute the command 'mvn harvest:checkout' I get the following output:
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'harvest'.
> [INFO] org.test.tools.maven.harvest: checking for updates from central
> Returning NULL
> [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-harvest-plugin: checking for
> updates from central
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] The plugin 'org.apache.maven.plugins:maven-harvest-plugin' does not
> exist or no valid version could be found
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 1 second
> [INFO] Finished at: Wed Oct 10 15:27:54 CEST 2007
> [INFO] Final Memory: 3M/6M
> [INFO]
>
> It looks to me that only the 'central' repository is scanned for the plugin,
> although I have correctly specified my internal remote repository in the
> section of my ' settings.xml' file. Furthermore, when I specify my
> internal remote repository as a mirrorOf 'central' the plugin is found. So,
> it looks like maven doesn't scan my internal remote repository for the needed
> plugin when the repository is specified as a pluginRepository in my '
> settings.xml' file.
> The plugin can be used when it is specified in the build section of a POM
> (which is done to be able to run the harvest:update goal on a project to
> update the sources from the SCM), which to me indicates that my configuration
> is correct. It just doesn't look for the plugin when the maven command is
> issued without a POM.
> What to me indicates that it is a profile problem is the fact that when I
> specify my internal remote repo as a mirrorOf central, it can find my custom
> plugin, but it can't find other needed jars from central. When I then disable
> the mirror section, all the jars from central are loaded, but the build fails
> on a custom jar (the SCM utility jar) which is present in another local
> remote repo (my third-party repo) which is also defined in my profile.
> When using mvn commands on a POM, my configuration (including my profile
> settings) works as expected.
> I have tried to explicitly enable the needed profile using the -P option, but
> that doesn't work either.
--
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-2599) Repository Mirrors in settings.xml need to specify layout
[ http://jira.codehaus.org/browse/MNG-2599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2599. -- Resolution: Won't Fix Fix Version/s: (was: 3.x) > Repository Mirrors in settings.xml need to specify layout > - > > Key: MNG-2599 > URL: http://jira.codehaus.org/browse/MNG-2599 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories, Settings >Reporter: John Casey > > Mirrors are different sites from the main one. Since they could be arranged > in almost any directory structure and still be a logical mirror of the > artifacts on the original site, and since we now support > * in the mirror specification, they also need to > allow/require the element from the repository, to specify how the > mirrored artifact repository should be constructed/accessed. -- 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-3946) user.home not expanded in conf/settngs.xml
[
http://jira.codehaus.org/browse/MNG-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-3946:
---
Fix Version/s: (was: 2.2.x)
3.0-alpha-7
> user.home not expanded in conf/settngs.xml
> --
>
> Key: MNG-3946
> URL: http://jira.codehaus.org/browse/MNG-3946
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Settings
>Affects Versions: 2.0.9
> Environment: MacOS 10.5
>Reporter: Benson Margulies
> Fix For: 3.0-alpha-7
>
>
> I have the following in conf/settings.xml in my maven install tree.
> ${user.home}/.m2/btrepository
> The user.home does not expand. Using a ~ doesn't help. I still end up with a
> .m2 directory in the root.
> [INFO] [install:install]
> [INFO] Installing
> /Users/benson/x/tip/rlp/utilities/source/maven-buildtools/target/common-buildtools-7.0-SNAPSHOT.jar
> to
> /.m2/btrepository/com/basistech/common-buildtools/7.0-SNAPSHOT/common-buildtools-7.0-SNAPSHOT.jar
--
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-2532) System properties cannot be set from Profiles or Settings.xml
[ http://jira.codehaus.org/browse/MNG-2532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2532: --- Fix Version/s: (was: 2.2.x) 3.0-alpha-7 > System properties cannot be set from Profiles or Settings.xml > - > > Key: MNG-2532 > URL: http://jira.codehaus.org/browse/MNG-2532 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Profiles, Settings >Affects Versions: 2.0.4 > Environment: Windows XP >Reporter: Peter Pilgrim > Fix For: 3.0-alpha-7 > > > Hi All > With the maven-antrun-plugin in Maven 2.0.4 is it possibly to define a system > property. Instead of me doing this all the time. > mvn install -Duser.install.root="C:\Program Files\IBM\WebSphere\AppServer" > For more info on the context see my blog > http://www.jroller.com/page/peter_pilgrim?entry=how_to_configure_xemacs_http > Specifically the system properties is not set up following to either a > profiles.xml or settings.xml file by Maven 2 > Possibly the system property I need is not also transfered to the Ant task > using the maven-antrun-plugin. > /* profiles.xml */ > > > user-install-root > > > !user.install.root > > > > C:\\Program > Files\\IBM\\WebSphere\\AppServer > > > > Running mvn help:active-profiles, however, does show that the profile has > been read. > C:\WORKSP~2\M2SPRI~1\ejb>mvn help:active-profiles > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'help'. > [INFO] > - > --- > [INFO] Building Maven 2.0 Spring EJB Research Project (EJB Module) > [INFO]task-segment: [help:active-profiles] (aggregator-style) > [INFO] > - > --- > [INFO] [help:active-profiles] > [INFO] > Active Profiles for Project > 'com.ubs.firc.ptsp.research.ejb:M2SpringEJBExample-e > jb:ejb:1.0-SNAPSHOT': > The following profiles are active: > - user-install-root (source: profiles.xml) > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Tue Aug 29 10:46:31 BST 2006 > [INFO] Final Memory: 2M/5M > [INFO] > > C:\WORKSP~2\M2SPRI~1\ejb> > Thanks Peter Pilgrim -- 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-3208) Injection of an inter-module dependency via profile does not affect reactor projects ordering
[ http://jira.codehaus.org/browse/MNG-3208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3208: --- Fix Version/s: (was: 3.x) 3.0-alpha-7 > Injection of an inter-module dependency via profile does not affect reactor > projects ordering > - > > Key: MNG-3208 > URL: http://jira.codehaus.org/browse/MNG-3208 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Profiles, Reactor and workspace >Affects Versions: 3.0-alpha-1 >Reporter: John Casey >Assignee: John Casey > Fix For: 3.0-alpha-7 > > > I don't know whether this is a problem in 2.0.7 (haven't had time to check > yet), but when I inject a new inter-module dependency via profile it seems > that the reactor build ordering is not affected. This is easy to reproduce: > 1. Create a three-module reactor build: > - first > | > |- second > |- third > 2. in a profile in 'second' put a dependency on 'third' > 3. run the build without triggering the profile...the modules (listed in the > above order) should build in that order > 4. run the build with the profile activated...'third' SHOULD build ahead of > 'second' now, but does not. > I'll try to loop back and test this on 2.0.7 when I can. -- 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-1053) Reactor mediates projects like dependencies
[ http://jira.codehaus.org/browse/MNG-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204577#action_204577 ] Jason van Zyl commented on MNG-1053: Dealing with on G:A in a reactor is by design. > Reactor mediates projects like dependencies > --- > > Key: MNG-1053 > URL: http://jira.codehaus.org/browse/MNG-1053 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 2.0-beta-3 > Environment: Windows XP, Cygwin >Reporter: Mark Hobson > Attachments: test.zip > > > The attached zip contains the following projects: > test:a:1.0 > test:a:2.0 > Running m2 -r install in the project's parent directory results in only > test:a:2.0 being built. It appears that m2 mediates out projects in the > reactor in the same manner as dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-1053) Reactor mediates projects like dependencies
[ http://jira.codehaus.org/browse/MNG-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1053. -- Resolution: Won't Fix Fix Version/s: (was: 3.x) > Reactor mediates projects like dependencies > --- > > Key: MNG-1053 > URL: http://jira.codehaus.org/browse/MNG-1053 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 2.0-beta-3 > Environment: Windows XP, Cygwin >Reporter: Mark Hobson > Attachments: test.zip > > > The attached zip contains the following projects: > test:a:1.0 > test:a:2.0 > Running m2 -r install in the project's parent directory results in only > test:a:2.0 being built. It appears that m2 mediates out projects in the > reactor in the same manner as dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3319) Reactor cannot detect artifact with exist in project and has test-jar type and test scope
[
http://jira.codehaus.org/browse/MNG-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204578#action_204578
]
Jason van Zyl commented on MNG-3319:
Provide more of an explanation, or sample project.
> Reactor cannot detect artifact with exist in project and has test-jar type
> and test scope
> -
>
> Key: MNG-3319
> URL: http://jira.codehaus.org/browse/MNG-3319
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle, Reactor and workspace
>Affects Versions: 2.0.8
>Reporter: Aleksey Solntsev
>
> The fix for MNG-2277 has resolved a lot of problems, first of all for
> release procedure.
> But we will still has the problem with detecting artifact like this.
>
> agillic.models
> agillic-processmodel
> ${project.version}
> test-jar
> test
>
--
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-3319) Reactor cannot detect artifact with exist in project and has test-jar type and test scope
[
http://jira.codehaus.org/browse/MNG-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-3319.
--
Resolution: Incomplete
Fix Version/s: (was: 2.2.x)
> Reactor cannot detect artifact with exist in project and has test-jar type
> and test scope
> -
>
> Key: MNG-3319
> URL: http://jira.codehaus.org/browse/MNG-3319
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle, Reactor and workspace
>Affects Versions: 2.0.8
>Reporter: Aleksey Solntsev
>
> The fix for MNG-2277 has resolved a lot of problems, first of all for
> release procedure.
> But we will still has the problem with detecting artifact like this.
>
> agillic.models
> agillic-processmodel
> ${project.version}
> test-jar
> test
>
--
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-4022) Incorrect merge behavior using profile driven plugin configuration
[ http://jira.codehaus.org/browse/MNG-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-4022: --- Fix Version/s: (was: 2.2.x) 3.0-alpha-7 > Incorrect merge behavior using profile driven plugin configuration > -- > > Key: MNG-4022 > URL: http://jira.codehaus.org/browse/MNG-4022 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Profiles >Affects Versions: 2.0.9 > Environment: Fedora 10 x86_64, not a factor >Reporter: John McNair > Fix For: 3.0-alpha-7 > > Attachments: maven-plugin-merge.zip > > > Plugin configurations are not merged correctly when contained inside a > profile. The attached example demonstrates a failure where the parent > contains the configuration, and the child contains the execution. There is > no configuration whatsoever in the child. The circumstances required to > trigger this are: > - Configuration contains a list of at least 2 complex elements. > - Configuration is inside a profile. This does not happen outside the profile > - The first element in the list contains parameters that the last element > does not contain, e.g.: > > > first > > > > > In this example, there should be a list of three Foo elements. The first > should have name="first" and the last two should have name=null. In reality, > the second element will have name=null, but the third will have name="first". > This behavior holds for all parameters in the first element that do not > exist in the last element. > The attached example includes a test plugin with an Element object that > demonstrates this behavior. > I have traced down the cause and have some high level ideas about the fix, > but I have not coded a patch. > I think there are two bugs that meet under these circumstances to cause the > configuration corruption. Certainly there are multiple opportunities to make > this pom configuration work as expected. > First, there is no configuration in the child. Why should maven even attempt > a merge? I ran maven through the debugger to get a better understanding of > the sequence of events. Maven sources the parent pom and the child pom. > When the child pom is sourced, it contains the full configuration exactly as > it exists in the parent. Then an attempt is made to merge these identical > configurations. Maven has the chance to avoid this issue by recognizing that > the configuration element does not exist at all in the child and simply > inheriting that as is from the parent. > The other bug is not in Maven. It is in Xpp3Dom > (http://fisheye.codehaus.org/browse/plexus/plexus-utils/tags/plexus-utils-1.5.1/src/main/java/org/codehaus/plexus/util/xml/Xpp3Dom.java?r=4475#l346). > Notice that it iterates over the list of recessive children (from the > parent pom) linearly and attempts to do a map-based lookup for the > corresponding element in the dominant children (from the child pom). This > works fine when you have a composition of several complex types, but it fails > when there is a sequence of the identical types. From a bit more abstract > perspective, if Xpp3Dom is attempting to merge two identical Xpp3Doms, I > would expect the result to be the identity rather than data corruption. > I have not done the research to understand why profile plugins go through > this path inside Xpp3Dom but non-profile plugins apparently don't. There may > also be other situations which are affected. I have not tried using a > pluginManagement element for instance. > Lastly, there is something of a workaround. You can tell Xpp3Dom not to > merge by setting the self.combine attribute: > > This tells Xpp3Dom to ignore the recessive Xpp3Dom (parent) and just use the > dominant (child) which seems odd given that there is no child configuration. > However, it will work if you don't have any real merging needs. -- 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-3349) reactor build order doesn't consider plugins modules in build order
[ http://jira.codehaus.org/browse/MNG-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3349: --- Fix Version/s: (was: 2.2.x) 3.0-alpha-7 > reactor build order doesn't consider plugins modules in build order > --- > > Key: MNG-3349 > URL: http://jira.codehaus.org/browse/MNG-3349 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 2.0.8 >Reporter: nicolas de loof >Priority: Minor > Fix For: 3.0-alpha-7 > > > When a project has maven plugins as modules, and some modules use the plugin, > the reactor SHOULD build the plugins before the modules that use it. > A workaround is to declare plugins modules FIRST 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] Closed: (MSHADE-21) NPE when calling mvn shade:shade
[ http://jira.codehaus.org/browse/MSHADE-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MSHADE-21. --- Resolution: Fixed Fix Version/s: 1.1 Assignee: Benjamin Bentmann > NPE when calling mvn shade:shade > > > Key: MSHADE-21 > URL: http://jira.codehaus.org/browse/MSHADE-21 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 1.0 >Reporter: Vincent Siveton >Assignee: Benjamin Bentmann > Fix For: 1.1 > > Attachments: MSHADE-20.diff > > > Take the take case for SHADE-20 and call mvn shade:shade > mvn install works fine -- 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-2933) Declaring the same resource dir in pom and overwriting it in a profile
[ http://jira.codehaus.org/browse/MNG-2933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2933: --- Fix Version/s: (was: 2.x) 3.0-alpha-7 > Declaring the same resource dir in pom and overwriting it in a profile > -- > > Key: MNG-2933 > URL: http://jira.codehaus.org/browse/MNG-2933 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Profiles >Affects Versions: 2.0.6 >Reporter: Dirk Olmes >Priority: Minor > Fix For: 3.0-alpha-7 > > > I have a pom that declares a resource dir in the main section of the pom and > a profile which re-declares the same resource dir in a profile, this time > with excludes. > Example: > > > > > src/main/resources > > > > > > > > > > src/main/resources > > > > > > > Running mvn -X with the profile activated shows that the same resource dir is > added twice to the runtime model. > I would have expected the profile to "overwrite" the resource directory as > this is the behaviour for re-declaring dependencies in a profile over > dependencies in the main section. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-171) link to "Unpacking the Project Dependencies" is broken - website
[ http://jira.codehaus.org/browse/MDEP-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204588#action_204588 ] Dan Tran commented on MDEP-171: --- could you manually generate 2.2-SNAPSHOT site? I dont see your mentioned broken links any more. > link to "Unpacking the Project Dependencies" is broken - website > > > Key: MDEP-171 > URL: http://jira.codehaus.org/browse/MDEP-171 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Jim Sellers >Assignee: Brian Fox >Priority: Trivial > Fix For: 2.1 > > > On the website [1] the link for "Unpacking the Project Dependencies" goes to > the "Copying Project Dependencies" page. It should go to the correct page > [2]. > [1] http://maven.apache.org/plugins/maven-dependency-plugin/ > [2] > http://maven.apache.org/plugins/maven-dependency-plugin/examples/unpacking-project-dependencies.html -- 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-3657) Ampersand characters cannot be used in profiles.xml (XML parsed twice)
[ http://jira.codehaus.org/browse/MNG-3657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3657: --- Fix Version/s: (was: 2.2.x) 3.0-alpha-7 > Ampersand characters cannot be used in profiles.xml (XML parsed twice) > -- > > Key: MNG-3657 > URL: http://jira.codehaus.org/browse/MNG-3657 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Profiles >Affects Versions: 2.0.9 > Environment: OS X (Leopard), Ubunut 8.04 >Reporter: Marcus Spiegel > Fix For: 3.0-alpha-7 > > Attachments: stacktrace.txt > > > It is not possible to use ampersand characters in the profiles.xml because > this is evaluated twice. > My case: > In my profiles.xml, I specify a database connection URL for MySQL where the > ampersand character is > used for separating connection parameters: > jdbc:mysql://localhost/myproject?autoReconnect=true&useUnicode=true&characterEncoding=utf8 > Because of the XML format, amperands are specified as "&". However, this > results in an exception (see attached > excerpt of the stack trace). Is is also not possible to specify the URL in a > CDATA section (or even in a combination > of & and CDATA). -- 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-3524) Profile to be activated when file is missing is always activated
[
http://jira.codehaus.org/browse/MNG-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-3524:
---
Fix Version/s: (was: 2.2.x)
3.0-alpha-7
> Profile to be activated when file is missing is always activated
>
>
> Key: MNG-3524
> URL: http://jira.codehaus.org/browse/MNG-3524
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 2.0.9
>Reporter: Adrian Hempel, Atlassian
> Fix For: 3.0-alpha-7
>
> Attachments: pom.xml
>
>
> When I run "mvn integration-test" with the attached pom.xml, the antrun:run
> goal is always executed, even when the ${project.build.directory}/built file
> is present.
> I would expect that the element would ensure that the profile
> containing the antrun:run goal would only be activated when that file is
> missing.
--
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-3287) profiles.xml does not always override pom.xml, at least when using sub-modules
[ http://jira.codehaus.org/browse/MNG-3287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3287: --- Fix Version/s: (was: 2.2.x) 3.0-alpha-7 > profiles.xml does not always override pom.xml, at least when using sub-modules > -- > > Key: MNG-3287 > URL: http://jira.codehaus.org/browse/MNG-3287 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Inheritance and Interpolation, Profiles >Affects Versions: 2.0.7 >Reporter: Boris Maras > Fix For: 3.0-alpha-7 > > Attachments: TestInheritance.zip > > > I have attached a test case to reproduce the problem. It has to be launched > with profile "dev". > I have a master pom.xml and a child pom.xml > In the master pom.xml is defined a profile "dev", with a property set to the > value "dev_pom.xml". > In the child pom.xml, I display the value of the property with the ant plugin. > There is also a file profiles.xml that overrides the property of the profile, > with the value "dev_profiles.xml". > If you run "mvn install -Pdev" on the child module, it displays > "dev_profiles.xml". > If you run "mvn antrun:run -Pdev" on the child module, it also displays > "dev_profiles.xml". > But if you run "mvn install -Pdev" on the master module, it displays > "dev_pom.xml". > It looks like the child module uses the value defined in the master pom, and > ignores the fact that it has been overriden by profiles.xml. And this > behavior occurs only if this child module is called through the master pom. > Moreover, if you remove the value in the master pom, then the child pom is > able to find the value in profiles.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3122) MAVENPROJECT: getActiveProfiles() returning duplicate activeByDefault profile defined in LOCAL_HOME/.m2/settings.xml
[ http://jira.codehaus.org/browse/MNG-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3122: --- Fix Version/s: (was: 2.2.x) 3.0-alpha-7 > MAVENPROJECT: getActiveProfiles() returning duplicate activeByDefault profile > defined in LOCAL_HOME/.m2/settings.xml > > > Key: MNG-3122 > URL: http://jira.codehaus.org/browse/MNG-3122 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Profiles >Affects Versions: 2.0.7 >Reporter: Ian Berry > Fix For: 3.0-alpha-7 > > Attachments: duplicateActiveProfiles.JPG, > duplicateActiveProfiles.zip, settings.xml > > > MavenProject:getActiveProfiles() is returning duplicate activeByDefault > profiles defined in LOCAL_HOME/.m2/settings.xml. > Attached settings.xml resides in LOCAL_HOME/.m2. > Below is part of the output of a buildInformation plugin i am writing, which > shows profile WLS8 twice. > > >default-repositories >settings.xml > > > WLS8 > settings.xml > > > WLS8 > settings.xml > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3017) Profile activation by file fails when maven is run outside the pom's directory
[ http://jira.codehaus.org/browse/MNG-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3017: --- Fix Version/s: (was: 2.2.x) 3.0-alpha-7 > Profile activation by file fails when maven is run outside the pom's directory > -- > > Key: MNG-3017 > URL: http://jira.codehaus.org/browse/MNG-3017 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Profiles >Affects Versions: 2.0.6 > Environment: Darwin Kernel Version 8.9.1 > java version "1.6.0-dp" > Java(TM) SE Runtime Environment (build 1.6.0-dp-b88-34) > Java HotSpot(TM) Client VM (build 1.6.0-b88-17-release, mixed mode, sharing) >Reporter: Jean-Luc Wasmer > Fix For: 3.0-alpha-7 > > Attachments: maven-test.tgz > > > When calling maven outside the pom's directory, the profile activation fails: > macb:~/Development/maven-test/parent jl$ mvn install > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] Example parent > [INFO] Example module1 > [INFO] Example module2 > [INFO] > > > macb:~/Development/maven-test jl$ mvn -f parent/pom.xml install > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] Example parent > [INFO] Example module1 > [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] Updated: (MNG-3539) Report plugins with inherited=false dropped by profile injector
[
http://jira.codehaus.org/browse/MNG-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-3539:
---
Fix Version/s: (was: 2.2.2)
> Report plugins with inherited=false dropped by profile injector
> ---
>
> Key: MNG-3539
> URL: http://jira.codehaus.org/browse/MNG-3539
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation, Profiles
>Affects Versions: 2.0.9
>Reporter: Benjamin Bentmann
>Priority: Minor
> Attachments: MNG-3539.patch, reporting-profile-merge.patch
>
>
> Consider the following POM snippet:
> {code:xml}
>
>
>
> org.apache.maven.plugins
> maven-surefire-report-plugin
> 2.3
> false
>
>
>
>
>
> extended-site
>
> ... some other plugins but excluding the surefire-report-plugin
>
>
>
> {code}
> When running "mvn site -P extended-site", the Surefire Report Plugin will be
> excluded from the site output.
> For some reason, the {{DefaultProfileInjector}} is dropping plugins which
> have {{inherited=false}}. Inheritance shouldn't matter here, it's all about
> the same POM, no parent-child play.
> Attached is a unit test to show the failure. An IT will follow now that I
> have the JIRA ticket.
--
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-3133) DefaultModelInheritence::appendPath assumes it is operating on interpolated/literal paths
[
http://jira.codehaus.org/browse/MNG-3133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-3133:
---
Fix Version/s: (was: 3.x)
3.0-alpha-7
> DefaultModelInheritence::appendPath assumes it is operating on
> interpolated/literal paths
> -
>
> Key: MNG-3133
> URL: http://jira.codehaus.org/browse/MNG-3133
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: POM
>Affects Versions: 2.0.7
>Reporter: John Allen
>Priority: Critical
> Fix For: 3.0-alpha-7
>
>
> Used by all the assembleXXXInheritance methods within
> assembleModelInheritance, the appendPath method assumes that its dealing with
> literal paths which is not a documented restriction. Thus having
> ${expressions} in any of the paths being operated on (e.g. project URL,
> distroManagement site, SCM, etc etc), the results will not be valid.
> This whole area of Maven's core requires a specification so it can be coded
> too and maintained.
--
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
]
Jason van Zyl updated MNG-2486:
---
Fix Version/s: (was: 3.x)
3.0-alpha-7
> ${project.version} evaluated to timestamped version if referring to SNAPSHOT
>
>
> Key: MNG-2486
> URL: http://jira.codehaus.org/browse/MNG-2486
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies, Inheritance and Interpolation, POM
>Affects Versions: 2.0.4, 2.0.5, 2.0.6, 2.0.7, 3.0-alpha-1
>Reporter: John Casey
>Priority: Critical
> Fix For: 3.0-alpha-7
>
>
> 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] Closed: (MNG-2715) Maven does not comply to XML rules regarding prefixes.
[
http://jira.codehaus.org/browse/MNG-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-2715.
--
Resolution: Won't Fix
Fix Version/s: (was: 3.x)
> Maven does not comply to XML rules regarding prefixes.
> --
>
> Key: MNG-2715
> URL: http://jira.codehaus.org/browse/MNG-2715
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: POM
> Environment: Ubuntu 6.10
> Maven 2.0.4
>Reporter: Seva Safris
>Priority: Critical
>
> I am new to Maven and have been trying to learn how to create a simple
> project.
> Let me walk through my scenario of creating a pom.xml file:
> 1. I bind the {http://maven.apache.org/POM/4.0.0} namespace (defined at
> "http://maven.apache.org/maven-v4_0_0.xsd";) to Java classes using an XML
> Binding solution.
> 2. I use the bound classes to create a simple as one would expect
> to see in a pom.xml file.
> 3. I marshal the bound Java objects into xml and write it into pom.xml. Here
> is the xml I use:
>xmlns:ns1="http://maven.apache.org/POM/4.0.0";>
> 4.0.0
> com.myapp
> sample-project
> Sample Maven Project
> 1.0
>
>
> ssafris
> Seva Safris
>
>
>
> ${basedir}/src/java
>
>
> 4. I run mvn, and am promptly given a "Not a v4.0.0 POM." exception.
> Tracing through Maven's source, I went to the exact location of the exception
> in DefaultMavenProjectBuilder.java. On line 1297 it has:
> if ( modelSource.indexOf( "4.0.0" ) < 0 )
> {
> throw new InvalidProjectModelException( projectId, pomLocation, "Not a
> v4.0.0 POM." );
> }
> Since modelSource is checked explicitly for
> xml as shown above will fail this test because it has: This is most definitely a bug in Maven and should be fixed as soon as
> possible. The workaround is to use a
> xmlns="http://maven.apache.org/POM/4.0.0"; and define all elements without a
> prefix. However, my use of xmlns:ns1="http://maven.apache.org/POM/4.0.0";
> should not break Maven as it is not merely legal by xml conventions, but is
> also a better practice for xml documents.
> I hope you see the importance of getting this bug fixed: My use of a XML
> Binding solution to bind Maven's xml to Java allows me a strongly-typed level
> of indirection that will deterministically create proper xml that will
> validate successfully. If this bug is not fixed, then this level of
> indirection is not possible (or very very very difficult because the XML
> Binding solution would have to be hacked to use the xmlns="[...]"
> convention). I have only found this one instance of where the bug is obvious,
> but perhaps there are more locations in Maven where the same kind of error
> can occur.
> Thank you for your time, and I hope you consider this issue as seriously as I
> do.
> Sincerely,
> Seva Safris
--
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-1944) cyclic dependencies causes maven to not include all transitive dependencies
[ http://jira.codehaus.org/browse/MNG-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1944. -- Resolution: Won't Fix Fix Version/s: (was: 3.x) > cyclic dependencies causes maven to not include all transitive dependencies > --- > > Key: MNG-1944 > URL: http://jira.codehaus.org/browse/MNG-1944 > Project: Maven 2 & 3 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.1 >Reporter: Brian Fox >Priority: Critical > Attachments: MNG-1944.patch > > > Try including dom4j 1.5.2 and see what dependencies are resolved. dom4j > depends on jaxen, which depends on dom4j. When maven sees the cyclic > dependency, it stops processing the jaxen dependency. This leaves everything > else jaxen depends on not included in the final artifact list. This is mvn -x > output: > dom4j:dom4j:jar:1.5.2 (selected for compile) > [DEBUG] stax:stax-api:jar:1.0 (selected for compile) > [DEBUG] pull-parser:pull-parser:jar:2 (selected for compile) > [DEBUG] jaxme:jaxme-api:jar:0.3 (selected for compile) > [WARNING] > This artifact has been relocated to xml-apis:xml-apis:1.0.b2. > [DEBUG] xml-apis:xml-apis:jar:1.0.b2 (selected for compile) > [DEBUG] msv:xsdlib:jar:20030807 (selected for compile) > [DEBUG] xpp3:xpp3:jar:1.1.3.3 (selected for compile) > [DEBUG] dom4j:dom4j:jar:1.5.2 (removed - causes a cycle in the > graph) > [DEBUG] jaxen:jaxen:jar:1.1-beta-4 (selected for compile) > [DEBUG] msv:relaxngDatatype:jar:20030807 (selected for compile) > Notice that xerces and xom and everything else jaxen depends on isn't > included. > Taking dom4j out of the jaxen pom locally causes everything to be included: > [DEBUG] com.stchome.maven.mojo:helloUser:jar:1.0-SNAPSHOT (selected for null) > [DEBUG] dom4j:dom4j:jar:1.5.2 (selected for compile) > [DEBUG] stax:stax-api:jar:1.0 (selected for compile) > [DEBUG] pull-parser:pull-parser:jar:2 (selected for compile) > [DEBUG] jaxme:jaxme-api:jar:0.3 (selected for compile) > [WARNING] > This artifact has been relocated to xml-apis:xml-apis:1.0.b2. > [DEBUG] xml-apis:xml-apis:jar:1.0.b2 (selected for compile) > [DEBUG] msv:xsdlib:jar:20030807 (selected for compile) > [DEBUG] xpp3:xpp3:jar:1.1.3.3 (selected for compile) > [DEBUG] jaxen:jaxen:jar:1.1-beta-4 (selected for compile) > [DEBUG] jdom:jdom:jar:b10 (selected for compile) > [DEBUG] xom:xom:jar:1.0b3 (selected for compile) > [DEBUG] xerces:xmlParserAPIs:jar:2.6.1 (selected for compile) > [DEBUG] xerces:xercesImpl:jar:2.2.1 (selected for compile) > [DEBUG] xalan:xalan:jar:2.6.0 (selected for compile) > [WARNING] > This artifact has been relocated to xml-apis:xml-apis:1.0.b2. > [DEBUG] xml-apis:xml-apis:jar:1.0.b2 (selected for compile) > [WARNING] > This artifact has been relocated to com.ibm.icu:icu4j:2.6.1. > [DEBUG] com.ibm.icu:icu4j:jar:2.6.1 (selected for compile) > [WARNING] > This artifact has been relocated to javax.servlet:servlet-api:2.4. > [DEBUG] javax.servlet:servlet-api:jar:2.4 (selected for compile) > [WARNING] > This artifact has been relocated to org.ccil.cowan.tagsoup:tagsoup:0.9.7. > [DEBUG] org.ccil.cowan.tagsoup:tagsoup:jar:0.9.7 (selected for > compile) > [DEBUG] xerces:xmlParserAPIs:jar:2.6.1 (removed - nearer found: 2.6.2) > [DEBUG] xerces:xmlParserAPIs:jar:2.6.2 (selected for compile) > [DEBUG] xerces:xercesImpl:jar:2.2.1 (removed - nearer found: 2.6.2) > [DEBUG] xerces:xercesImpl:jar:2.6.2 (selected for compile) > [DEBUG] msv:relaxngDatatype:jar:20030807 (selected for compile) -- 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-1840) Increment Model Version and enable stricter checks.
[ http://jira.codehaus.org/browse/MNG-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1840. -- Resolution: Incomplete Fix Version/s: (was: 3.x) > Increment Model Version and enable stricter checks. > --- > > Key: MNG-1840 > URL: http://jira.codehaus.org/browse/MNG-1840 > Project: Maven 2 & 3 > Issue Type: Bug > Components: POM >Affects Versions: 2.0-alpha-1 >Reporter: Joakim Erdfelt > > Based on discussion with Brett. > The 2.1 codebase will introduce some new elements into the pom. > * Increment the POM modelVersion. > * Enable strict checks option in ModelReader. > * Commit MODELLO-44 for required pom elements. -- 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-3397) [RFC] change the POM to use attributes
[ http://jira.codehaus.org/browse/MNG-3397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3397: --- Fix Version/s: (was: 2.3.x) 3.1.alpha1 > [RFC] change the POM to use attributes > -- > > Key: MNG-3397 > URL: http://jira.codehaus.org/browse/MNG-3397 > Project: Maven 2 & 3 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.8 >Reporter: Brett Porter > Fix For: 3.1.alpha1 > > -- 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-2817) Add identity specification in maven-model and maven-settings
[ http://jira.codehaus.org/browse/MNG-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2817. -- Resolution: Not A Bug Fix Version/s: (was: 2.3.x) > Add identity specification in maven-model and maven-settings > > > Key: MNG-2817 > URL: http://jira.codehaus.org/browse/MNG-2817 > Project: Maven 2 & 3 > Issue Type: Bug > Components: POM, Settings >Reporter: Vincent Siveton >Assignee: John Casey > > Some generated objects are used in lists. Thus, it will be very useful to > have identity specification for them: equals(..) and hashcode() (see > MODELLO-43) > For instance, see org.apache.maven.model.Resource used in > model/build/resources -- 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-3448) Infinite Loop When Using project.version in Modules Build
[
http://jira.codehaus.org/browse/MNG-3448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204589#action_204589
]
Jason van Zyl commented on MNG-3448:
Please make a test project.
> Infinite Loop When Using project.version in Modules Build
> -
>
> Key: MNG-3448
> URL: http://jira.codehaus.org/browse/MNG-3448
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: POM
>Affects Versions: 2.0.8
>Reporter: Hilco Wijbenga
>
> I have the following setup:
> org.example.pom/pom.xml:
>
> xmlns="http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";
> >
> 4.0.0
> org.example
> pom
> pom
> 1
> POM
>
> ${project.version}
>
>
> and org.example.jar/pom.xml:
>
> xmlns="http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";
> >
> 4.0.0
>
> org.example
> pom
> 1
> ../org.example.pom/pom.xml
>
> org.example
> jar
> jar
> ${webapp.version}
> JAR
>
> Running "mvn clean" in org.example.jar yields just
> [INFO] Scanning for projects...
> and then Maven hangs. Replacing "${project.version}" with a simple "0.1"
> allows things to work properly.
> My environment:
> Maven version: 2.0.8
> Java version: 1.5.0_14
> OS name: "linux" version: "2.6.24-gentoo-r2" arch: "i386" Family: "unix"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3448) Infinite Loop When Using project.version in Modules Build
[
http://jira.codehaus.org/browse/MNG-3448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-3448.
--
Resolution: Incomplete
Fix Version/s: (was: 2.2.x)
> Infinite Loop When Using project.version in Modules Build
> -
>
> Key: MNG-3448
> URL: http://jira.codehaus.org/browse/MNG-3448
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: POM
>Affects Versions: 2.0.8
>Reporter: Hilco Wijbenga
>
> I have the following setup:
> org.example.pom/pom.xml:
>
> xmlns="http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";
> >
> 4.0.0
> org.example
> pom
> pom
> 1
> POM
>
> ${project.version}
>
>
> and org.example.jar/pom.xml:
>
> xmlns="http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";
> >
> 4.0.0
>
> org.example
> pom
> 1
> ../org.example.pom/pom.xml
>
> org.example
> jar
> jar
> ${webapp.version}
> JAR
>
> Running "mvn clean" in org.example.jar yields just
> [INFO] Scanning for projects...
> and then Maven hangs. Replacing "${project.version}" with a simple "0.1"
> allows things to work properly.
> My environment:
> Maven version: 2.0.8
> Java version: 1.5.0_14
> OS name: "linux" version: "2.6.24-gentoo-r2" arch: "i386" Family: "unix"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3398) Multiple Plugin Declarations Ignored with no warning
[ http://jira.codehaus.org/browse/MNG-3398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3398: --- Fix Version/s: (was: 2.2.x) 3.0-alpha-7 > Multiple Plugin Declarations Ignored with no warning > > > Key: MNG-3398 > URL: http://jira.codehaus.org/browse/MNG-3398 > Project: Maven 2 & 3 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.7, 2.0.8, 2.0.9 >Reporter: Ben Tatham > Fix For: 3.0-alpha-7 > > > If I (accidentally) declare the same plugin in the pom twice, with different > executions,only the executions from the first declaration are run. And no > warning is given saying that it is ignoring the others. I figure there are > two options to solve this: either use both declarations, or fail the build > (fail -- not warning) to tell the user to fix their 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] Closed: (MNG-3289) unable to resolve profile properties from a parent pom
[
http://jira.codehaus.org/browse/MNG-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-3289.
--
Resolution: Incomplete
Fix Version/s: (was: 2.2.x)
> unable to resolve profile properties from a parent pom
> --
>
> Key: MNG-3289
> URL: http://jira.codehaus.org/browse/MNG-3289
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: POM
>Affects Versions: 2.0.7
>Reporter: Rot Ulet
>
> I defined some properties in the default profile in the settings.xml :
>
>
>
> profile01
>
> true
>
>
> scm:svn:svn://linux-dev/source
> http://linux-dev/bugzilla
>
>
>
>
> I have defined a parent pom file named BaseProject (for default
> configuration, report, etc.) used in all project I use. I can compile and
> install this pom to my local repository. I reference this pom as the parent
> for my other projects.
> * For a project with parent defined to my BaseProject-pom and without
> dependencies to other project, there is no problem : I can compile and
> install without any warning.
> * But for a project with parent defined to my BaseProject-pom and with some
> dependencies to other project (previously compiled and installed), I have
> this warning :
> [WARNING] POM for 'net.dummy:FW-Interfaces:pom:1.0-SNAPSHOT:compile' is
> invalid. It will be ignored for artifact resolution. Reason: The POM
> expression: ${pom.scm.connection} could not be evaluated. Reason: Expression
> value '${pom.scm.connection}/FW/FW-Interfaces' references itself in
> 'net.dummy:FW-Interfaces:jar:1.0-SNAPSHOT'. for project
> net.dummy:FW-Interfaces at Artifact
> [net.dummy:FW-Interfaces:pom:1.0-SNAPSHOT:compile]
> But ${pom.scm.connection} (or ${scm.connection}) is defined in the default
> profile of the settings.xml.
> But It is just a warning and can go through all the compilation steps.
> * And for an helper project (called 'all_project.pom') without parent and
> dependencies but with all the project in need to compile in the 'modules'
> section. I got this :
> [WARNING] POM for 'net.dummy:BaseProject-Conf:pom:1.0-SNAPSHOT:runtime' is
> invalid. It will be ignored for artifact resolution. Reason: The POM
> expression: ${pom.scm.connection} could not be evaluated. Reason: Expression
> value '${pom.scm.connection}/BaseProject-Conf' references itself in
> 'net.dummy:BaseProject-Conf:jar:1.0-SNAPSHOT'. for project
> net.dummy:BaseProject-Conf at Artifact
> [net.dummy:BaseProject-Conf:pom:1.0-SNAPSHOT:runtime]
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.UnsupportedOperationException
> at java.util.AbstractCollection.add(AbstractCollection.java:221)
> at
> org.apache.maven.plugin.DefaultPluginManager.checkPlexusUtils(DefaultPluginManager.java:743)
> at
> org.apache.maven.extension.DefaultExtensionManager.addExtension(DefaultExtensionManager.java:112)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.findExtensions(DefaultLifecycleExecutor.java:158)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:141)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> (BaseProject-Conf is the first 'module' of BaseProject)
> Also see Wish n° MNG-2896.
> Regards.
--
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-3289) unable to resolve profile properties from a parent pom
[
http://jira.codehaus.org/browse/MNG-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204590#action_204590
]
Jason van Zyl commented on MNG-3289:
Please reopen with a test project.
> unable to resolve profile properties from a parent pom
> --
>
> Key: MNG-3289
> URL: http://jira.codehaus.org/browse/MNG-3289
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: POM
>Affects Versions: 2.0.7
>Reporter: Rot Ulet
>
> I defined some properties in the default profile in the settings.xml :
>
>
>
> profile01
>
> true
>
>
> scm:svn:svn://linux-dev/source
> http://linux-dev/bugzilla
>
>
>
>
> I have defined a parent pom file named BaseProject (for default
> configuration, report, etc.) used in all project I use. I can compile and
> install this pom to my local repository. I reference this pom as the parent
> for my other projects.
> * For a project with parent defined to my BaseProject-pom and without
> dependencies to other project, there is no problem : I can compile and
> install without any warning.
> * But for a project with parent defined to my BaseProject-pom and with some
> dependencies to other project (previously compiled and installed), I have
> this warning :
> [WARNING] POM for 'net.dummy:FW-Interfaces:pom:1.0-SNAPSHOT:compile' is
> invalid. It will be ignored for artifact resolution. Reason: The POM
> expression: ${pom.scm.connection} could not be evaluated. Reason: Expression
> value '${pom.scm.connection}/FW/FW-Interfaces' references itself in
> 'net.dummy:FW-Interfaces:jar:1.0-SNAPSHOT'. for project
> net.dummy:FW-Interfaces at Artifact
> [net.dummy:FW-Interfaces:pom:1.0-SNAPSHOT:compile]
> But ${pom.scm.connection} (or ${scm.connection}) is defined in the default
> profile of the settings.xml.
> But It is just a warning and can go through all the compilation steps.
> * And for an helper project (called 'all_project.pom') without parent and
> dependencies but with all the project in need to compile in the 'modules'
> section. I got this :
> [WARNING] POM for 'net.dummy:BaseProject-Conf:pom:1.0-SNAPSHOT:runtime' is
> invalid. It will be ignored for artifact resolution. Reason: The POM
> expression: ${pom.scm.connection} could not be evaluated. Reason: Expression
> value '${pom.scm.connection}/BaseProject-Conf' references itself in
> 'net.dummy:BaseProject-Conf:jar:1.0-SNAPSHOT'. for project
> net.dummy:BaseProject-Conf at Artifact
> [net.dummy:BaseProject-Conf:pom:1.0-SNAPSHOT:runtime]
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.UnsupportedOperationException
> at java.util.AbstractCollection.add(AbstractCollection.java:221)
> at
> org.apache.maven.plugin.DefaultPluginManager.checkPlexusUtils(DefaultPluginManager.java:743)
> at
> org.apache.maven.extension.DefaultExtensionManager.addExtension(DefaultExtensionManager.java:112)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.findExtensions(DefaultLifecycleExecutor.java:158)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:141)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> (BaseProject-Conf is the first 'module' of BaseProject)
> Also see Wish n° MNG-2896.
> Regards.
--
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-3700) ModelUtils.clone doesn't clone plugin entries where inherited == false
[ http://jira.codehaus.org/browse/MNG-3700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3700: --- Fix Version/s: (was: 2.2.2) 3.0-alpha-7 > ModelUtils.clone doesn't clone plugin entries where inherited == false > -- > > Key: MNG-3700 > URL: http://jira.codehaus.org/browse/MNG-3700 > Project: Maven 2 & 3 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.10 >Reporter: John Casey > Fix For: 3.0-alpha-7 > > Attachments: ModelUtilsTest.patch > > > ModelUtils.clone(..) uses the ModelInheritanceAssembler under the covers, > with assembleAsInheritance == true. This is not strictly true, since > inheritance semantics are different in some ways from clone semantics. > This becomes an issue where plugins are concerned, especially when the plugin > entry in the POM contains inherited == "false", which will lead to the > cloning process *excluding* that plugin from the clone result. -- 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-3238) property not resolved in for war projects
[ http://jira.codehaus.org/browse/MNG-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-3238. -- Resolution: Won't Fix Fix Version/s: (was: 2.2.x) > property not resolved in for war projects > > > Key: MNG-3238 > URL: http://jira.codehaus.org/browse/MNG-3238 > Project: Maven 2 & 3 > Issue Type: Bug > Components: POM >Reporter: Jerome Lacoste > Attachments: optional-properties-taken-from-pom.tar > > > I am trying to make some sort of custom skinny war files without having to > use profiles which tend to be very verbose. > So I am using true to make those dependencies not being > packaged. > In order to make this conditional, I tried to use a to define the > default value, which I can override in the command line. > This doesn't work. See attached test case. -- 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-2632) Setting property in profiles is not evaluated for POM validation
[
http://jira.codehaus.org/browse/MNG-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204592#action_204592
]
Jason van Zyl commented on MNG-2632:
This now works in trunk.
> Setting property in profiles is not evaluated for POM validation
>
>
> Key: MNG-2632
> URL: http://jira.codehaus.org/browse/MNG-2632
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: POM
>Affects Versions: 2.0.4
> Environment: WinXP
>Reporter: Christoph Amshoff
> Fix For: 3.x
>
> Attachments: fix.patch
>
>
> There seems to be a problem concerning POM validation and setting properties
> in profiles.xml: when I set a property in my profiles.xml it is not evaluated
> for POM validation in a multi module build.
> The details: My project C depends on module B, which itself is a child of
> module A. Module A defines a system scope dependency like this:
> {code}
>
> db2
> db2
> 8.2
> system
> ${path.db2jar}
>
> {code}
> The path to db2.jar depends on the developer's machine and is specified in
> the profiles.xml, toghether with other settings. Both A and B are building
> and deploying fine.
> Now, when I try to build C, it complains about missing definition for
> 'path.db2jar':
> {code}
> [WARNING] POM for '...B:pom:4.4.0-SNAPSHOT:compile' is invalid. It will be
> ignored for artifact resolution. Reason:
> Failed to validate POM
> [DEBUG] Reason: Failed to validate POM
> [DEBUG]
> Validation Errors:
> [DEBUG] For dependency Dependency {groupId=db2, artifactId=db2, version=8.2,
> type=jar}: system-scoped dependency
> must specify an absolute path systemPath.
> {code}
> I'm using a profiles.xml section like this one:
> {code}
>
> env-nb
>
>
> env
> nb
>
>
>
> c:/programme/IBM/SQLLIB/java/db2java.zip
> ...
>
>
> {code}
> which is triggered by -Denv=nb, and this activation is working fine since
> 'help:effective-pom' is correctly showing me something like
> {code}
>
> c:/programme/IBM/SQLLIB/java/db2java.zip
> ...
>
> {code}
> So the profiles.xml seems to be evaluated correctly, but the property is not
> used for validating the POM of dependent modules.
> And yes, when I run Maven without the profiles.xml, but with specifying the
> property on command line (like '-Dpath.db2jar=...'), all is working fine! But
> that's not exactly what we want, since profiles are meant to encapsulate
> those kind of settings...
--
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-2632) Setting property in profiles is not evaluated for POM validation
[
http://jira.codehaus.org/browse/MNG-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-2632.
--
Resolution: Fixed
Fix Version/s: (was: 2.2.x)
3.x
> Setting property in profiles is not evaluated for POM validation
>
>
> Key: MNG-2632
> URL: http://jira.codehaus.org/browse/MNG-2632
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: POM
>Affects Versions: 2.0.4
> Environment: WinXP
>Reporter: Christoph Amshoff
> Fix For: 3.x
>
> Attachments: fix.patch
>
>
> There seems to be a problem concerning POM validation and setting properties
> in profiles.xml: when I set a property in my profiles.xml it is not evaluated
> for POM validation in a multi module build.
> The details: My project C depends on module B, which itself is a child of
> module A. Module A defines a system scope dependency like this:
> {code}
>
> db2
> db2
> 8.2
> system
> ${path.db2jar}
>
> {code}
> The path to db2.jar depends on the developer's machine and is specified in
> the profiles.xml, toghether with other settings. Both A and B are building
> and deploying fine.
> Now, when I try to build C, it complains about missing definition for
> 'path.db2jar':
> {code}
> [WARNING] POM for '...B:pom:4.4.0-SNAPSHOT:compile' is invalid. It will be
> ignored for artifact resolution. Reason:
> Failed to validate POM
> [DEBUG] Reason: Failed to validate POM
> [DEBUG]
> Validation Errors:
> [DEBUG] For dependency Dependency {groupId=db2, artifactId=db2, version=8.2,
> type=jar}: system-scoped dependency
> must specify an absolute path systemPath.
> {code}
> I'm using a profiles.xml section like this one:
> {code}
>
> env-nb
>
>
> env
> nb
>
>
>
> c:/programme/IBM/SQLLIB/java/db2java.zip
> ...
>
>
> {code}
> which is triggered by -Denv=nb, and this activation is working fine since
> 'help:effective-pom' is correctly showing me something like
> {code}
>
> c:/programme/IBM/SQLLIB/java/db2java.zip
> ...
>
> {code}
> So the profiles.xml seems to be evaluated correctly, but the property is not
> used for validating the POM of dependent modules.
> And yes, when I run Maven without the profiles.xml, but with specifying the
> property on command line (like '-Dpath.db2jar=...'), all is working fine! But
> that's not exactly what we want, since profiles are meant to encapsulate
> those kind of settings...
--
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-2157) Properties defined in top-level profiles.xml do no propagate to child modules
[
http://jira.codehaus.org/browse/MNG-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-2157:
---
Fix Version/s: (was: 2.2.x)
3.0-alpha-7
> Properties defined in top-level profiles.xml do no propagate to child modules
> -
>
> Key: MNG-2157
> URL: http://jira.codehaus.org/browse/MNG-2157
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: POM
>Affects Versions: 2.0.2
>Reporter: Jason Dillon
>Priority: Blocker
> Fix For: 3.0-alpha-7
>
>
> I have a multi-module build, and at the top-level I have a profile called
> 'release-environment', which is activated by -Denv=release.
> I need the local release build to use different values for JDBC configuration
> to run integration tests, and defined them in a profiles.xml:
> {code}
>
>
>
>
> local-release-environment
>
>
> env
> release
>
>
>
>
> mif_jason
> mif_jason
> MIF_JASON
>
>
>
>
>
> {code}
> My project looks like:
> pom.xml
> merchant/pom.xml
> merchant/core/pom.xml
> merchant/services/pom.xml
> If i put profiles.xml as a peer to pom.xml and run {{mvn clean install
> -Denv=release}} from the top-level, I get errors because the properties are
> not propagated to the merchant/core/pom.xml module.
> If I put profiles.xml as a peer to merchant/core/pom.xml and run {{mvn clean
> install -Denv=release}}, then it works as expected... properties are set as
> they are defined in profiles.xml.
> But, this is not manageable, as I need to set some properties for all of the
> modules in a multi-module build... But I don't want to use those properties
> for all Maven2 projects, so I can not really put it into ~/.m2/settings.xml
> I had expected that a top-level profiles.xml would work, but it does not. Is
> this by design, is there another recommend way to provide per-top-level
> multi-module project configuration on a local user basis (ie. no pom.xml
> modifications)?
--
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-3262) Problem accessing dependency resource via reflection in maven 2 plugin
[
http://jira.codehaus.org/browse/MNG-3262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-3262:
---
Fix Version/s: (was: 2.2.x)
3.0-alpha-7
> Problem accessing dependency resource via reflection in maven 2 plugin
> --
>
> Key: MNG-3262
> URL: http://jira.codehaus.org/browse/MNG-3262
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 2.0.7
>Reporter: Gary S. Weaver
> Fix For: 3.0-alpha-7
>
> Attachments: trunk-exampleproject.tgz, trunk-i18nsanity-pt.tgz
>
>
> I've written a Maven 2 mojo that is having trouble instantiating (via
> reflection) a properties resource of dependency that is included as a
> "compile"-scope dependency in the project (pom.xml) that is utilizing my
> plugin.
> (Even though I need the plugin to access a dependency that is in "provided"
> scope, for now I'm using compile scope since the maven documentation states
> that @requiresDependencyResolution doesn't support provided scope.)
> Here are the details:
> 1) I have the following dependency:
> ---start---
>
>
> com.atlassian.confluence
> confluence
> 2.6.0
> compile
>
>
> ---end---
> 2) In the pom.xml of the project that utilizes my plugin, the mojo of the
> plugin I wrote is configured with the execution:
> ---start---
>
> get_ConfluenceActionSupport.properties
> compile
>
> extractProperties
>
>
>
> com.atlassian.confluence.core.ConfluenceActionSupport.properties
>
> target/classes/com/atlassian/confluence/core/ConfluenceActionSupport.properties
>
>
> ---end---
> 3) In the Maven 2 mojo it calls the following code (just copied/pasted the
> relevant portion):
> ---start---
> // load properties with reflection and save to file
> InputStream in = null;
> OutputStream out = null;
> boolean foundFile = false;
> try {
> String resource = cleanResourceName(fullyQualifiedProperties);
> System.out.println("Getting " + resource);
> in = getClass().getResourceAsStream (resource);
> if (in != null)
> {
> Properties result = new Properties();
> result.load (in); // Can throw IOException
> out = new BufferedOutputStream(new
> FileOutputStream(outputPathname));
> result.store(out, "");
> foundFile = true;
> }
> }
> ---end---
> When executed, it can't find the properties file in the classloader. As you
> can see from the following output, I'm putting the resource string together
> correctly as
> "/com/atlassian/confluence/core/ConfluenceActionSupport.properties" which if
> you interrogate the above confluence dependency, you should be able to find.
> ---start---
> [INFO] [i18nsanity-pt:extractProperties {execution:
> get_ConfluenceActionSupport.properties}]
> [INFO] Extracting properties file from classpath...
> fullyQualifiedProperties=com.atlassian.confluence.core.ConfluenceActionSupport.properties
>
> outputFile=/usr/svn/community/confluence/plugins/americanenglishlanguagepack/trunk/target/classes/com/atlassian/confluence/core/ConfluenceActionSupport.properties
> Getting /com/atlassian/confluence/core/ConfluenceActionSupport.properties
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed properties extraction!
> Embedded error: Could not find properties file on classpath:
> com.atlassian.confluence.core.ConfluenceActionSupport.properties
> ---end---
> 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] Commented: (MNG-3383) Downloaded plugin dependencies influence project dependencies
[
http://jira.codehaus.org/browse/MNG-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204593#action_204593
]
Jason van Zyl commented on MNG-3383:
Application and plugin repositories are fully partitioned in 3.0.
> Downloaded plugin dependencies influence project dependencies
> -
>
> Key: MNG-3383
> URL: http://jira.codehaus.org/browse/MNG-3383
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies, Plugins and
> Lifecycle
>Affects Versions: 2.0.8
>Reporter: Stefan Seidel
> Fix For: 3.x
>
> Attachments: pom.xml
>
>
> Currently, a plugin may define additional pluginRepositories, which are used
> to resolve dependencies of that plugin.
> This leads to the fact that a plugin might resolve a dependency which would
> normally not be available to the project.
> When it does that, it seems to write a metadata-central (although on the
> central repo this artifact does not exist) and thus, the project will use
> that dependency, too.
> How to reproduce:
> 1. remove xstream from local repo:
> {code}rm -Rf ~/.m2/repository/com/thoughtworks/xstream{code}
> 2. run mvn clean install on the attached pom.xml
> -> the build should fail because the version 1.3.0-SNAPSHOT is not available
> at repo1.maven.org
> 3. edit the pom.xml, uncomment the plugin definition (jspc used for
> demonstration purposes only)
> 3. run mvn clean install again
> -> the build succeeds and the 1.3.0-SNAPSHOT is being built into the
> artifact, which is wrong.
--
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-3383) Downloaded plugin dependencies influence project dependencies
[
http://jira.codehaus.org/browse/MNG-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-3383.
--
Resolution: Fixed
Fix Version/s: (was: 2.2.x)
3.x
> Downloaded plugin dependencies influence project dependencies
> -
>
> Key: MNG-3383
> URL: http://jira.codehaus.org/browse/MNG-3383
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies, Plugins and
> Lifecycle
>Affects Versions: 2.0.8
>Reporter: Stefan Seidel
> Fix For: 3.x
>
> Attachments: pom.xml
>
>
> Currently, a plugin may define additional pluginRepositories, which are used
> to resolve dependencies of that plugin.
> This leads to the fact that a plugin might resolve a dependency which would
> normally not be available to the project.
> When it does that, it seems to write a metadata-central (although on the
> central repo this artifact does not exist) and thus, the project will use
> that dependency, too.
> How to reproduce:
> 1. remove xstream from local repo:
> {code}rm -Rf ~/.m2/repository/com/thoughtworks/xstream{code}
> 2. run mvn clean install on the attached pom.xml
> -> the build should fail because the version 1.3.0-SNAPSHOT is not available
> at repo1.maven.org
> 3. edit the pom.xml, uncomment the plugin definition (jspc used for
> demonstration purposes only)
> 3. run mvn clean install again
> -> the build succeeds and the 1.3.0-SNAPSHOT is being built into the
> artifact, which is wrong.
--
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-1465) Maven not able to find setter for MavenProjectHelper property
[
http://jira.codehaus.org/browse/MNG-1465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-1465.
--
Resolution: Won't Fix
Fix Version/s: (was: 3.x)
> Maven not able to find setter for MavenProjectHelper property
> -
>
> Key: MNG-1465
> URL: http://jira.codehaus.org/browse/MNG-1465
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Reporter: David Jackman
>
> This might really be a plexus issue (I don't know enough about the code to
> know for sure).
> I have a Mojo class with a field of type MavenProjectHelper. For all other
> field, I've followed the pattern of using a private member field with a
> prefix of "m_", then using the property parameter to indicate a setter method
> for that field that Maven should use. This seems to work find for most of my
> properties, but the one that takes a MavenProjectHelper won't work that way.
> For some reason, it looks for a field of that name and not a setter method
> for that property.
> Here's the field definition and the setter method:
> /**
> * @parameter
> expression="${component.org.apache.maven.project.MavenProjectHelper}"
> property="projectHelper"
> */
> private MavenProjectHelper m_projectHelper;
> /**
> * Sets the project helper.
> *
> * @param projectHelper the project helper to use.
> */
> public void setProjectHelper(MavenProjectHelper projectHelper)
> {
> this.m_projectHelper = projectHelper;
> }
> And the error I get back when attempting to use the Mojo looks like this:
> [INFO] Internal error in the plugin manager executing goal
> 'no.fast.buildprocess:docextractor:1.0-SNAPSHOT:configdocjar': Unable to find
> the mojo 'no.fast.buildprocess:docextractor:1.0-SNAPSHOT:configdocjar' in the
> plugin 'no.fast.buildprocess:docextractor'
> Component Composition failed. No field of name: 'projectHelper' exists in
> component: role: 'null', implementation:
> 'no.fast.buildprocess.ConfigdocJarMojo'
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the
> plugin manager executing goal
> 'no.fast.buildprocess:docextractor:1.0-SNAPSHOT:configdocjar': Unable to find
> the mojo 'no.fast.buildprocess:docextractor:1.0-SNAPSHOT:configdocjar' in the
> plugin 'no.fast.buildprocess:docextractor'
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:523)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:482)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:452)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.PluginManagerException: Unable to find the
> mojo 'no.fast.buildprocess:docextractor:1.0-SNAPSHOT:configdocjar' in the
> plugin 'no.fast.buildprocess:docextractor'
> at
> org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:533)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:390)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519)
> ... 16 more
> Caused by:
> org.codehaus.plexus.component.repository.exception.ComponentLookupException:
> Unable to lookup component
> 'org.apache.maven.plugin.Mojono.fast.buildprocess:docextractor:1.0-SNAPSHOT:configdocjar',
>
[jira] Commented: (MNG-3518) Handle date qualifier in DefaultArtifactVersion
[
http://jira.codehaus.org/browse/MNG-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204594#action_204594
]
Johan Walles commented on MNG-3518:
---
Hi! What's the rationale for not merging this patch (or something else solving
this problem) for 2.x?
Regards //Johan
> Handle date qualifier in DefaultArtifactVersion
> ---
>
> Key: MNG-3518
> URL: http://jira.codehaus.org/browse/MNG-3518
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 2.0.9
>Reporter: Vincent Siveton
> Fix For: 3.x
>
> Attachments: DefaultArtifactVersion-handledate.diff, pom.xml
>
>
> Eclipse artifacts use a date pattern in version qualifier and build fail with
> the following error
> {noformat}
> [INFO] Failed to resolve artifact.
> Couldn't find a version in [1.0.0-v20070606] to match range [1.0.0,2.0)
> org.eclipse.equinox:app:jar:null
> {noformat}
> The following patch adds javadoc for compareTo() to be more clear.
> Also, it handles date pattern in the version to allow "1.0.0" <
> "1.0.0-v20070606". Internally, it compares "1.0.0-19068845215" (ie new
> Date(Integer.MAX_VALUE, 12, 31 )) to "1.0.0-20070606"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-3518) Handle date qualifier in DefaultArtifactVersion
[
http://jira.codehaus.org/browse/MNG-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204594#action_204594
]
Johan Walles edited comment on MNG-3518 at 12/30/09 1:33 PM:
-
Hi! What's the rationale for not merging this patch (or something else solving
this problem) for 2.x?
Regards //Johan (suffering from this)
was (Author: walles):
Hi! What's the rationale for not merging this patch (or something else
solving this problem) for 2.x?
Regards //Johan
> Handle date qualifier in DefaultArtifactVersion
> ---
>
> Key: MNG-3518
> URL: http://jira.codehaus.org/browse/MNG-3518
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 2.0.9
>Reporter: Vincent Siveton
> Fix For: 3.x
>
> Attachments: DefaultArtifactVersion-handledate.diff, pom.xml
>
>
> Eclipse artifacts use a date pattern in version qualifier and build fail with
> the following error
> {noformat}
> [INFO] Failed to resolve artifact.
> Couldn't find a version in [1.0.0-v20070606] to match range [1.0.0,2.0)
> org.eclipse.equinox:app:jar:null
> {noformat}
> The following patch adds javadoc for compareTo() to be more clear.
> Also, it handles date pattern in the version to allow "1.0.0" <
> "1.0.0-v20070606". Internally, it compares "1.0.0-19068845215" (ie new
> Date(Integer.MAX_VALUE, 12, 31 )) to "1.0.0-20070606"
--
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-3449) direct invocation of plugin after lifecycle calls that build it causes lifecycle-planning problem
[ http://jira.codehaus.org/browse/MNG-3449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204595#action_204595 ] Jason van Zyl commented on MNG-3449: This code has been replaced. > direct invocation of plugin after lifecycle calls that build it causes > lifecycle-planning problem > - > > Key: MNG-3449 > URL: http://jira.codehaus.org/browse/MNG-3449 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0-alpha-1 >Reporter: John Casey >Assignee: John Casey > Attachments: maven-find-local-repo-plugin.zip > > > When you run a plugin build using something like: > maven-foo-plugin$ mvn clean install foo:bar > Maven fails to construct a build plan for this build, since it cannot resolve > the prefix for the 'foo' plugin. We need to allow this to fail during > build-planning, then do another late-bound approach to resolve the prefix and > run the mojo. I'm attaching a test plugin for this. -- 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-3449) direct invocation of plugin after lifecycle calls that build it causes lifecycle-planning problem
[ http://jira.codehaus.org/browse/MNG-3449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-3449. -- Resolution: Cannot Reproduce Fix Version/s: (was: 3.x) > direct invocation of plugin after lifecycle calls that build it causes > lifecycle-planning problem > - > > Key: MNG-3449 > URL: http://jira.codehaus.org/browse/MNG-3449 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0-alpha-1 >Reporter: John Casey >Assignee: John Casey > Attachments: maven-find-local-repo-plugin.zip > > > When you run a plugin build using something like: > maven-foo-plugin$ mvn clean install foo:bar > Maven fails to construct a build plan for this build, since it cannot resolve > the prefix for the 'foo' plugin. We need to allow this to fail during > build-planning, then do another late-bound approach to resolve the prefix and > run the mojo. I'm attaching a test plugin for this. -- 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-3297) maven should not give dependencies to plugins that don't @requireDependencyResolution
[ http://jira.codehaus.org/browse/MNG-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-3297. -- Resolution: Incomplete Fix Version/s: (was: 3.x) > maven should not give dependencies to plugins that don't > @requireDependencyResolution > - > > Key: MNG-3297 > URL: http://jira.codehaus.org/browse/MNG-3297 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.7 >Reporter: Brian Fox > > Currently we seem to hand over the dependencies as resolved by the last > plugin. This leads to scenarios where sometimes plugins work because they get > the right ones but it is subject to break at any time in subtle ways. > Therefore, we should give nothing to the plugin so the plugin author will > realize the mistake immediately. -- 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-1968) allow disabling of plugin version discovery
[ http://jira.codehaus.org/browse/MNG-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204596#action_204596 ] Jason van Zyl commented on MNG-1968: The Super POM specifies a version and in 3.1 you will have to specify a version. > allow disabling of plugin version discovery > --- > > Key: MNG-1968 > URL: http://jira.codehaus.org/browse/MNG-1968 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories, Plugins and Lifecycle >Reporter: Brett Porter > Fix For: 3.x > > > for verifying reproducibility (and enable it on release:perform) -- 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-1968) allow disabling of plugin version discovery
[ http://jira.codehaus.org/browse/MNG-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1968. -- Resolution: Fixed > allow disabling of plugin version discovery > --- > > Key: MNG-1968 > URL: http://jira.codehaus.org/browse/MNG-1968 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories, Plugins and Lifecycle >Reporter: Brett Porter > Fix For: 3.x > > > for verifying reproducibility (and enable it on release:perform) -- 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-1362) Several problems when specifying custom target dir
[
http://jira.codehaus.org/browse/MNG-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-1362.
--
Resolution: Incomplete
Fix Version/s: (was: 2.2.x)
> Several problems when specifying custom target dir
> --
>
> Key: MNG-1362
> URL: http://jira.codehaus.org/browse/MNG-1362
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0
>Reporter: Vincent Massol
>
> I'd like to change my target dir to be target/maven instead of target/
> First problem:
> ===
> If I add the following to my pom.xml:
> ${basedir}/target/maven
> Then the compiled classes still go to target/classes and not to
> target/maven/classes.
> Second problem:
> ==
> If I add the following to my pom.xml:
> ${basedir}/target/maven
> ${project.build.directory}/classes
> Then the compiler fails to compile classe:
> [INFO] [compiler:compile]
> Compiling 10 source files to
> C:\dev\cargo\trunk\core\util\C:\dev\cargo\trunk\core\util\target\maven\classes
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Compilation failure
> C:\dev\cargo\trunk\core\util\src\main\java\org\codehaus\cargo\util\monitor\NullMonitor.java:[27,7]
> error while writing org.codehau
> s.cargo.util.monitor.NullMonitor:
> C:\dev\cargo\trunk\core\util\C:\dev\cargo\trunk\core\util\target\maven\classes\org\codehaus\carg
> o\util\monitor\NullMonitor.class (The filename, directory name, or volume
> label syntax is incorrect)
--
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-1362) Several problems when specifying custom target dir
[
http://jira.codehaus.org/browse/MNG-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204598#action_204598
]
Jason van Zyl commented on MNG-1362:
Extremely old. I believe this is fixed, reopen if it's an issue.
> Several problems when specifying custom target dir
> --
>
> Key: MNG-1362
> URL: http://jira.codehaus.org/browse/MNG-1362
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0
>Reporter: Vincent Massol
>
> I'd like to change my target dir to be target/maven instead of target/
> First problem:
> ===
> If I add the following to my pom.xml:
> ${basedir}/target/maven
> Then the compiled classes still go to target/classes and not to
> target/maven/classes.
> Second problem:
> ==
> If I add the following to my pom.xml:
> ${basedir}/target/maven
> ${project.build.directory}/classes
> Then the compiler fails to compile classe:
> [INFO] [compiler:compile]
> Compiling 10 source files to
> C:\dev\cargo\trunk\core\util\C:\dev\cargo\trunk\core\util\target\maven\classes
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Compilation failure
> C:\dev\cargo\trunk\core\util\src\main\java\org\codehaus\cargo\util\monitor\NullMonitor.java:[27,7]
> error while writing org.codehau
> s.cargo.util.monitor.NullMonitor:
> C:\dev\cargo\trunk\core\util\C:\dev\cargo\trunk\core\util\target\maven\classes\org\codehaus\carg
> o\util\monitor\NullMonitor.class (The filename, directory name, or volume
> label syntax is incorrect)
--
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-1390) @requiresDependencyResolution in process-classes post compile
[
http://jira.codehaus.org/browse/MNG-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-1390:
---
Fix Version/s: (was: 2.2.x)
3.0-alpha-7
> @requiresDependencyResolution in process-classes post compile
> -
>
> Key: MNG-1390
> URL: http://jira.codehaus.org/browse/MNG-1390
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0
>Reporter: Jesse McConnell
> Fix For: 3.0-alpha-7
>
> Original Estimate: 3 hours
> Remaining Estimate: 3 hours
>
> I was looking back into some plugins I had written a while back and ran
> across an oddity.
> it appears that when using a plugin in the process-classes phase, after the
> compiler plugin has done its thing, the @requiresDependencyResolution javadoc
> flag will toggle the presense of dependencies that are scoped to provided in
> the dependencies section when calling project.getCompileClasspathElements();
> (a difference of 80 vs 24 when not using the flag and then using it)
> ---
> this are two snippits of code from the plugin
> /**
> * A plugin for generating * java file containing all the classes in a src
> tree.
> *
> * @goal generate
> * @requiresDependencyResolution
> * @description Functions Generator plugin
> * @author jesse
> */
>
>
>
> List classpathFiles = project.getCompileClasspathElements();
>
> URL[] urls = new URL[classpathFiles.size() + 1];
>
> getLog().debug("" + classpathFiles.size());
>
> for (int i = 0; i < classpathFiles.size(); ++i) {
> getLog().debug((String)classpathFiles.get(i));
> urls[i] = new File((String)classpathFiles.get(i)).toURL();
> }
>
> urls[classpathFiles.size()] = new File( buildDirectory + "/classes"
> ).toURL();
>
> URLClassLoader ucl = new URLClassLoader(urls,
> Thread.currentThread().getContextClassLoader());
> being used with the following plugin declaration:
>
> gallup.maven
> services-provider-maven-plugin
> 1.0.1
>
>
> com/g/util/ServiceProvider.java
>
>
>
> process-classes
>
> generate
>
>
>
>
>
> analyzing the debug output when I run the plugin without the
> @requiresDependencyResolution I get 80 dependencies and it builds out the
> classloader correctly..
> but if I add the @requiresDependencyResolution statement I go down to 24
> dependencies being put into the classloader...and the discrepency corresponds
> to the presense of the provided statement.
--
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-1775) No property expansion in profile activation
[
http://jira.codehaus.org/browse/MNG-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-1775:
---
Fix Version/s: (was: 2.2.x)
3.0-alpha-7
> No property expansion in profile activation
> ---
>
> Key: MNG-1775
> URL: http://jira.codehaus.org/browse/MNG-1775
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0, 2.0.1
> Environment: Linux
>Reporter: Eric Andresen
> Fix For: 3.0-alpha-7
>
>
> I have a profile specified in the pom.xml of a project. It is inteded to be
> activated based on the presence or absence of a file, using the
> profile activator.
> The profiles are simple:
>
> metis
>
> ${basedir}/../build.properties
>
>
>
> ${basedir}/../build.properties.metis
>
>
>
> dev
>
> ${basedir}/../build.properties
>
>
>
> ${basedir}/../build.properties
>
>
> The problem comes in with ${basedir} -- it isn't being expanded for purposes
> of evaluating the file. It's trying to look for a file named
> "${basedir}/../build.properties", rather than
> "/home/joe/projectX/projY/../build.properties"; as a result, the "missing"
> directive is always true, and the dev profile is never activated. When the
> filter path is evaluated, the ${basedir} property *is* evaluated, however.
--
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-1486) Can't use pom properties inside resource directory tag
[
http://jira.codehaus.org/browse/MNG-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-1486:
---
Fix Version/s: (was: 2.2.x)
3.0-alpha-7
> Can't use pom properties inside resource directory tag
> ---
>
> Key: MNG-1486
> URL: http://jira.codehaus.org/browse/MNG-1486
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0
>Reporter: Filip Vuksanovic
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 3.0-alpha-7
>
>
> I have pom.xml with following snippet:
>
>src\JavaSource
>
>
> src\JavaSource
> and it works.
> If I use property like this
>
>src\JavaSource
>
>
> ${project.build.sourceDirectory}
> it doesn't work.
--
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-2957) attached artifact is not included in classpath when a sub-project depended on it is compiled in multi-project
[ http://jira.codehaus.org/browse/MNG-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204599#action_204599 ] Jason van Zyl commented on MNG-2957: Code in 3.x is entirely different. Reopen with a sample project if the problem is still present. > attached artifact is not included in classpath when a sub-project depended on > it is compiled in multi-project > - > > Key: MNG-2957 > URL: http://jira.codehaus.org/browse/MNG-2957 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.6 >Reporter: YOKOTA Takehiko > > I have a mult-project. It contains two sub-project A and B, and A has an > attached artifact A.jar (main artifact is A.zip). > In addition, B depends on A.jar in compile scope. When I build this > mult-project like 'mvn install', it fails because > A.jar is not included in the classpath for compiling B. > The reason is that, as for A.jar, > org.apache.maven.project.MavenProject#replaceWithActiveArtifact() returns a > copied Artifact > of the AttachedArtifact object created by > org.apache.maven.projectMavenProjectHelper#attachArtifact() and > the value of its scope property is null. So this Artifact is ignored in > MavenProject#getCompileClasspathElements(). > In MavenProject#replaceWithActiveArtifact(), the scope property's value of a > copied Artifact from attached should be the > same as one's value of pluginArtifact. -- 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-2957) attached artifact is not included in classpath when a sub-project depended on it is compiled in multi-project
[ http://jira.codehaus.org/browse/MNG-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2957. -- Resolution: Incomplete Fix Version/s: (was: 2.2.x) > attached artifact is not included in classpath when a sub-project depended on > it is compiled in multi-project > - > > Key: MNG-2957 > URL: http://jira.codehaus.org/browse/MNG-2957 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.6 >Reporter: YOKOTA Takehiko > > I have a mult-project. It contains two sub-project A and B, and A has an > attached artifact A.jar (main artifact is A.zip). > In addition, B depends on A.jar in compile scope. When I build this > mult-project like 'mvn install', it fails because > A.jar is not included in the classpath for compiling B. > The reason is that, as for A.jar, > org.apache.maven.project.MavenProject#replaceWithActiveArtifact() returns a > copied Artifact > of the AttachedArtifact object created by > org.apache.maven.projectMavenProjectHelper#attachArtifact() and > the value of its scope property is null. So this Artifact is ignored in > MavenProject#getCompileClasspathElements(). > In MavenProject#replaceWithActiveArtifact(), the scope property's value of a > copied Artifact from attached should be the > same as one's value of pluginArtifact. -- 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-3226) Developers and Contributors information is not being inherited
[ http://jira.codehaus.org/browse/MNG-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3226: --- Fix Version/s: (was: 2.2.x) 3.0-alpha-7 > Developers and Contributors information is not being inherited > -- > > Key: MNG-3226 > URL: http://jira.codehaus.org/browse/MNG-3226 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.7 >Reporter: Brad Szabo > Fix For: 3.0-alpha-7 > > > The developers and contributors information is not being merged into the > effective POM of child projects. > According to the Project Inheritance section of the following two POM > references, this info should be merged. > http://maven.apache.org/guides/introduction/introduction-to-the-pom.html > http://maven.apache.org/pom.html#Inheritance -- 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-3315) Path normalization during inheritance prohibits usage of properties
[
http://jira.codehaus.org/browse/MNG-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-3315:
---
Fix Version/s: (was: 2.2.x)
3.0-alpha-7
> Path normalization during inheritance prohibits usage of properties
> ---
>
> Key: MNG-3315
> URL: http://jira.codehaus.org/browse/MNG-3315
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.8
>Reporter: Benjamin Bentmann
> Fix For: 3.0-alpha-7
>
> Attachments: project.zip
>
>
> Assume a multi-module scenario with the following (non-standard) directory
> layout:
> project/
> project-parent/
> project-module-1/
> project-module-2/
> That is, the parent POM is placed in a sibling directory rather than the
> parent directory of the module projects such that the "module path
> adjustment" is "../" when inheriting paths/URLs from the project-parent.
> Now, consider the following POM snippet for the site distribution (or any
> other element where Maven adjusts paths for sub modules):
> {code:xml}
>
> website
> dav:http://www.company.org/project
>
> {code}
> All fine so far, but this slightly modified snippet does not work any more:
> {code:xml}
>
> dav:http://www.company.org/project
>
> ...
>
> website
> ${site.url}
>
> {code}
> Just replacing the string by a property produces a bad URL for any sub
> project. This problems originates from
> DefaultModelInheritanceAssembler.resolvePath() that "normalizes" a string
> like "${site.url}/../project-module-1" to "project-module-1".
> While the usage of the property is not mandatory, I nevertheless think the
> moral from this subtle issue should be not to do any path normalization
> until all properties have been interpolated, i.e.:
> - inheritance ( URL = "${site.url}/../project-module-1" )
> - interpolation ( URL =
> "dav:http://www.company.org/project/../project-module-1"; )
> - path/URL normalization ( URL =
> "dav:http://www.company.org/project-module-1"; )
> Otherwise, Maven calls another weird pitfall its own.
--
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&focusedCommentId=204600#action_204600
]
Brian Fox commented on MNG-2486:
I'm pretty sure this is already fixed even in 2.x.
> ${project.version} evaluated to timestamped version if referring to SNAPSHOT
>
>
> Key: MNG-2486
> URL: http://jira.codehaus.org/browse/MNG-2486
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies, Inheritance and Interpolation, POM
>Affects Versions: 2.0.4, 2.0.5, 2.0.6, 2.0.7, 3.0-alpha-1
>Reporter: John Casey
>Priority: Critical
> Fix For: 3.0-alpha-7
>
>
> 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-2438) search for metadata in legacy repositories causes wrong repository source to be used for artifact resolution
[ http://jira.codehaus.org/browse/MNG-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204601#action_204601 ] Jason van Zyl commented on MNG-2438: Legacy repos go away in Maven 3.0, and most people don't use them in 2.0. > search for metadata in legacy repositories causes wrong repository source to > be used for artifact resolution > > > Key: MNG-2438 > URL: http://jira.codehaus.org/browse/MNG-2438 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: John Casey > > legacy repositories store all version metadata in a single file under the > /poms/ subdirectory of the artifactId dir. This means that snapshot > resolution will result in the legacy repository being marked as the source > for the artifact, regardless of whether that metadata file contains the > snapshot is actually in that repository's metadata file or not. This is > because the metadata manager (and metadata class itself, possibly) assumes > that all metadata files resolved for a particular artifact/snapshot are > relevant to that snapshot...when the legacy repo's metadata is merged into > the rest of the in-progress metadata, changes are detected, and the legacy > repo is adopted as the source for the latest artifact information, regardless > of whether it actually contains information about that snapshot or not. -- 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-2438) search for metadata in legacy repositories causes wrong repository source to be used for artifact resolution
[ http://jira.codehaus.org/browse/MNG-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2438. -- Resolution: Won't Fix Fix Version/s: (was: 2.2.x) > search for metadata in legacy repositories causes wrong repository source to > be used for artifact resolution > > > Key: MNG-2438 > URL: http://jira.codehaus.org/browse/MNG-2438 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: John Casey > > legacy repositories store all version metadata in a single file under the > /poms/ subdirectory of the artifactId dir. This means that snapshot > resolution will result in the legacy repository being marked as the source > for the artifact, regardless of whether that metadata file contains the > snapshot is actually in that repository's metadata file or not. This is > because the metadata manager (and metadata class itself, possibly) assumes > that all metadata files resolved for a particular artifact/snapshot are > relevant to that snapshot...when the legacy repo's metadata is merged into > the rest of the in-progress metadata, changes are detected, and the legacy > repo is adopted as the source for the latest artifact information, regardless > of whether it actually contains information about that snapshot or not. -- 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-2190) -Dkey=value parameters cannot include spaces in the value
[ http://jira.codehaus.org/browse/MNG-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2190. -- Resolution: Cannot Reproduce Fix Version/s: (was: 2.2.x) > -Dkey=value parameters cannot include spaces in the value > - > > Key: MNG-2190 > URL: http://jira.codehaus.org/browse/MNG-2190 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0.2 > Environment: Darwin >Reporter: Gordon Henriksen > Attachments: MNG-2190.patch > > > Even if I properly escape spaces in a path at the shell level, Maven seems to > re-split the command parameters. For instance, on Unix, the following should > all run the compile goal with a property foo="bar baz": > $ mvn compile "-Dfoo=bar baz" > $ mvn compile -Dfoo="bar baz" > $ mvn compile -Dfoo=bar\ baz > But in fact, Maven fails, complaining that "baz" is an invalid task: > [INFO] Scanning for projects... > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Invalid task 'baz': you must specify a valid lifecycle phase, or a > goal in the format plugin:goal or > pluginGroupId:pluginArtifactId:pluginVersion:goal > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: < 1 second > [INFO] Finished at: Wed Mar 29 15:21:01 EST 2006 > [INFO] Final Memory: 1M/2M > [INFO] > > Is this intended behavior? Seems as if Maven is unnecessarily splitting the > string, when the OS already does as much. > I was merely trying to run: > mvn deploy:deploy-file "-Dfile=/Users/me/Desktop/Bellicose > SDK/lib/Bellicose.jar" ... > In my case, it's practical to work around by renaming the Bellicose SDK > folder, but it seems as if Windows users stuck with "C:\Documents and > Settings\..." might have a harder time of it. -- 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-2190) -Dkey=value parameters cannot include spaces in the value
[ http://jira.codehaus.org/browse/MNG-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204602#action_204602 ] Jason van Zyl commented on MNG-2190: The commands all work in Maven 3.x. > -Dkey=value parameters cannot include spaces in the value > - > > Key: MNG-2190 > URL: http://jira.codehaus.org/browse/MNG-2190 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0.2 > Environment: Darwin >Reporter: Gordon Henriksen > Attachments: MNG-2190.patch > > > Even if I properly escape spaces in a path at the shell level, Maven seems to > re-split the command parameters. For instance, on Unix, the following should > all run the compile goal with a property foo="bar baz": > $ mvn compile "-Dfoo=bar baz" > $ mvn compile -Dfoo="bar baz" > $ mvn compile -Dfoo=bar\ baz > But in fact, Maven fails, complaining that "baz" is an invalid task: > [INFO] Scanning for projects... > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Invalid task 'baz': you must specify a valid lifecycle phase, or a > goal in the format plugin:goal or > pluginGroupId:pluginArtifactId:pluginVersion:goal > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: < 1 second > [INFO] Finished at: Wed Mar 29 15:21:01 EST 2006 > [INFO] Final Memory: 1M/2M > [INFO] > > Is this intended behavior? Seems as if Maven is unnecessarily splitting the > string, when the OS already does as much. > I was merely trying to run: > mvn deploy:deploy-file "-Dfile=/Users/me/Desktop/Bellicose > SDK/lib/Bellicose.jar" ... > In my case, it's practical to work around by renaming the Bellicose SDK > folder, but it seems as if Windows users stuck with "C:\Documents and > Settings\..." might have a harder time of it. -- 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-3529) mvn -Da=" " throws an excepltion
[ http://jira.codehaus.org/browse/MNG-3529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3529: --- Fix Version/s: (was: 2.2.x) 3.0-alpha-7 > mvn -Da=" " throws an excepltion > > > Key: MNG-3529 > URL: http://jira.codehaus.org/browse/MNG-3529 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0.8 >Reporter: Sean Bridges >Priority: Trivial > Fix For: 3.0-alpha-7 > > > Doing, > mvn -Da=" " > throws, > --- > java.lang.StringIndexOutOfBoundsException: String index out of range: -1 > at > java.lang.AbstractStringBuilder.setLength(AbstractStringBuilder.java:146) > at java.lang.StringBuffer.setLength(StringBuffer.java:154) > at > org.apache.maven.cli.MavenCli$CLIManager.cleanArgs(MavenCli.java:793) > at org.apache.maven.cli.MavenCli$CLIManager.parse(MavenCli.java:746) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:100) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- 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-3555) transitive dependency exclusion fails when classifier specified
[
http://jira.codehaus.org/browse/MNG-3555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-3555:
---
Fix Version/s: (was: 2.2.x)
3.0-alpha-7
> transitive dependency exclusion fails when classifier specified
> ---
>
> Key: MNG-3555
> URL: http://jira.codehaus.org/browse/MNG-3555
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.9
> Environment: Gentoo linux
>Reporter: Trenton
>Priority: Blocker
> Fix For: 3.0-alpha-7
>
> Attachments: pom.xml
>
>
> I have a profile like the one below. When I enable that profile, maven
> refuses to exclude the dependencies as specified, unless I remove the
> classifier. This is basically preventing us from using maven. We will have
> to stick with ant until this is resolved.
> A little bit of background. We have an rmi module and a web module. This
> profile is in the web module pom. The rmi project creates two different
> types of jars. One is the rmi server jar, the other the rmi client jar. In
> the case of the rmi server jar, all the dependencies would be required. And,
> we allow the rmi server to be run in process (under tomcat). In a case like
> that, we require all the dependencies. But, when running in standard RMI
> mode, and using the client jar, we do not need all those dependencies, nor do
> we want them to be there.
>
>
> client
>
>
>
>
> true
> ${basedir}/src/main/resources
>
> server.properties
> response_codes.properties
>
>
>
>
>
>
> ca.athabascau.banner.oros
> rmi
> 1.1.23-SNAPSHOT
> compile
> client
>
>
> ca.athabascau
> moneris-test
>
>
> com.oracle.ojdbc
> ojdbc14
>
>
> com.novell
> java-ldap
>
>
> commons-dbcp
> commons-dbcp
>
>
> commons-collections
> commons-collections
>
>
> commons-pool
> commons-pool
>
>
> cas
> casclient
>
>
> xerces
> xercesImpl
>
>
> oro
> oro
>
>
> xml-apis
> xml-apis
>
>
> javax.activation
> activation
>
>
>
>
>
--
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-3987) No attempts to connect to remote repositories under Sun JDK 1.6.0.06 (i386 and x86_64)
[ http://jira.codehaus.org/browse/MNG-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-3987. -- Resolution: Cannot Reproduce Fix Version/s: (was: 2.2.x) > No attempts to connect to remote repositories under Sun JDK 1.6.0.06 (i386 > and x86_64) > --- > > Key: MNG-3987 > URL: http://jira.codehaus.org/browse/MNG-3987 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies > Environment: Fedora 10 (2.6.27.5-117.fc10.x86_64) > Sun jdk1.6.0_06-x86_64 > Maven 2.0.9 >Reporter: Andrew Lee Rubinger >Assignee: Brian Fox > Attachments: maven_dependency_resolution_fail-jdk1.6.0_06-x86_64.txt, > maven_dependency_resolution_works-jdk1.6.0_11-x86_64.txt > > > While using Sun jdk1.6.0_06-x86_64 as JAVA_HOME, remote dependencies are not > downloaded. Wireshark network analysis shows no TCP requests sent out of > port 80. Using jdk1.6.0_11-x86_64 resolves the issue. > Steps to duplicate (on the reporter's local environment) > 1) Clean local M2 repo (ie. ~/.m2/repository) > 2) Set JAVA_HOME to jdk1.6.0_06-x86_64 > 3) Attempt "mvn install"..Observe dependency resolution problems as artifacts > and POMs cannot be downloaded. Maven reports as not found. The URLs noted > in the trace are accessible via wget or browser. > 4) Set JAVA_HOME to jdk1.6.0_11-x86_64 > 5) Attempt "mvn install" Dependencies will be downloaded. -- 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-3477) Authentication failures on dependency download aren't reported
[ http://jira.codehaus.org/browse/MNG-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3477: --- Fix Version/s: (was: 2.2.x) 3.0-alpha-7 > Authentication failures on dependency download aren't reported > -- > > Key: MNG-3477 > URL: http://jira.codehaus.org/browse/MNG-3477 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.8 >Reporter: Justin Edelson > Fix For: 3.0-alpha-7 > > > We have a Maven proxy server (using Proximity) that requires authentication. > Users store their username and passwords in settings.xml. If the login > information is incorrect, they are not informed the the problem is due to bad > credentials, just that the dependencies are missing. -e and -X don't add > anything useful. > This is true for both dependencies and plugins. -- 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-3751) Multi-module project is non-deterministic in evaluating reactor artifacts defined as dependencies unless they are installed in the local repository
[ http://jira.codehaus.org/browse/MNG-3751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3751: --- Fix Version/s: (was: 2.x) 3.0-alpha-7 > Multi-module project is non-deterministic in evaluating reactor artifacts > defined as dependencies unless they are installed in the local repository > --- > > Key: MNG-3751 > URL: http://jira.codehaus.org/browse/MNG-3751 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories, Dependencies, Reactor and > workspace >Affects Versions: 2.0.8, 2.0.9 > Environment: Mac OS X 10.5.4, Windows XP SPx, CentOS 5.2 >Reporter: Stephen Evanchik > Fix For: 3.0-alpha-7 > > Attachments: full-dependency-tree.txt, master-compile-run.txt, > maven-test.tar.gz > > > Summary: Multi-module project is non-deterministic in evaluating reactor > artifacts defined as dependencies unless they are installed in the local > repository > I cannot build either a leaf project (sub1-module1) or the master project > (master) until I 'mvn install' the sub-modules (sub-module). > I believe that dependency modules found only in the reactor should be added > to: > [DEBUG] (f) classpathElements = > [/Users/evanchsa/src/maven-test/subproject1/sub1-module1/target/classes] > Detailed setup: > I have a multi-module project that is laid out in the following POM > inheritance (this is not the filesystem layout): > master > + sub1-master > - sub1-module1 > - sub1-module2 > + sub2-master > - sub2-module1 > - sub2-module2 > Sub-modules are type "jar" and 1 "war" and there are dependencies within the > sub-modules as follows (using mvn dependency:tree): > 1. sub1-module1 > - Depends on no other modules > 2. sub1-module2 > - test-group:sub1-module2:jar:0.0.1 >\- test-group:sub1-module1:jar:0.0.1:compile > 3. sub2-module1 > - test-group:sub2-module1:jar:0.0.1 >\- test-group:sub1-module2:jar:0.0.1:compile > \- test-group:sub1-module1:jar:0.0.1:compile > 4. sub2-module2 (this is the WAR) > - test-group:sub2-module2:jar:0.0.1 >\- test-group:sub2-module1:jar:0.0.1:compile > \- test-group:sub1-module2:jar:0.0.1:compile > \- test-group:sub1-module1:jar:0.0.1:compile > Project filesystem layout: > build/master/pom.xml > subproject1/sub1-master/pom.xml > subproject1/sub1-module1/pom.xml > subproject1/sub1-module2/pom.xml > subproject2/sub2-master/pom.xml > subproject2/sub2-module1/pom.xml > subproject2/sub2-module2/pom.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3222) Compile dependency resolution is slow
[ http://jira.codehaus.org/browse/MNG-3222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-3222. -- Resolution: Cannot Reproduce Fix Version/s: (was: 2.2.x) > Compile dependency resolution is slow > - > > Key: MNG-3222 > URL: http://jira.codehaus.org/browse/MNG-3222 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.4 >Reporter: Stefan Behnel > > Compile dependency resolution is slow. I just wrote an empty module (only > test sources that were not compiled), and it took Maven more than five > minutes to build it, without any compilation/generation/testing/whatsoever. I > just took literally minutes to resolve a couple of hundred compile time > dependencies for the compiler plugin, which was then executed twice. > To me, this sounds like a problem with the algorithmic complexity of the > dependency resolution. -- 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-3884) Command line arguments don't overwrite settings.xml properties when invoking a plugin
[ http://jira.codehaus.org/browse/MNG-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3884: --- Fix Version/s: (was: 2.x) 3.0-alpha-7 > Command line arguments don't overwrite settings.xml properties when invoking > a plugin > - > > Key: MNG-3884 > URL: http://jira.codehaus.org/browse/MNG-3884 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0.9, 2.1.0-M1 > Environment: All environments >Reporter: laurent gousenbourger > Fix For: 3.0-alpha-7 > > > To explain the issue, let's start with the following example: > 1°) Run a plugin goal with an argument specified in the command line with the > "-D" option only > mvn eclipse:eclipse -Declipse.projectNameTemplate=CommandLineProjectName > We can see if we open the generated .project file that the name of the > project is as we expect: "CommandLineProjectName" > This is normal, the goal input parameter is set with the command line > property. > 2°) Run a plugin goal with an argument specified in the "settings.xml" file > only > mvn eclipse:eclipse > with settings.xml containing the following enabled profile: > > > testProfile > > > SettingsProjectName > > > > > testProfile > > We can see if we open the generated .project file that the name of the > project is as we expect: "SettingsProjectName". > This is normal, the input parameter of the goal is set with the > "settings.xml" file property. > 3°) Run a plugin goal with an argument specified in the command line with the > "-D" option and with another value in the "settngs.xml" file > If we use both scenarios, the property value set in the "settings.xml" file > will overwrite the value set via the command line with the "-D" option. > Maven should not react in that way but in the opposite: the command line > value should overwite the "settings.xml" file value. > It is already the case if we reuse the value somewhere in the pom.xml file. > It should be the same when invoking a plugin goal. -- 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-3222) Compile dependency resolution is slow
[ http://jira.codehaus.org/browse/MNG-3222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204603#action_204603 ] Jason van Zyl commented on MNG-3222: Caching is a lot smarter with 3.x. Please reopen if the speed is still a problem. > Compile dependency resolution is slow > - > > Key: MNG-3222 > URL: http://jira.codehaus.org/browse/MNG-3222 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.4 >Reporter: Stefan Behnel > > Compile dependency resolution is slow. I just wrote an empty module (only > test sources that were not compiled), and it took Maven more than five > minutes to build it, without any compilation/generation/testing/whatsoever. I > just took literally minutes to resolve a couple of hundred compile time > dependencies for the compiler plugin, which was then executed twice. > To me, this sounds like a problem with the algorithmic complexity of the > dependency resolution. -- 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-3725) Cannot override plugin dependencies in maven 2.0.9
[
http://jira.codehaus.org/browse/MNG-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-3725:
---
Fix Version/s: (was: 3.x)
3.0-alpha-7
> Cannot override plugin dependencies in maven 2.0.9
> --
>
> Key: MNG-3725
> URL: http://jira.codehaus.org/browse/MNG-3725
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.9
> Environment: Maven version: 2.0.9
> Java version: 1.5.0_13
> OS name: "mac os x" version: "10.5.4" arch: "ppc" Family: "unix"
>Reporter: Graham Leggett
> Fix For: 3.0-alpha-7
>
>
> When an attempt is made to override the version of torque-templates used by
> the maven-torque-plugin as below, maven still tries to use the original
> version of the torque-templates jar. The overridden jar is ignored.
> According to http://jira.codehaus.org/browse/MNG-2972, this behaviour used to
> be broken in maven v2.0.8 and earlier, and was apparently fixed. This doesn't
> seem to be the case though.
> The configuration looks like this:
> {code:xml}
>
> org.apache.torque
> torque-maven-plugin
> 3.3
>
>
> org.apache.derby
> derby
> 10.4.1.3
>
>
> org.apache.torque
> torque-templates
> 3.3.1
>
>
>
> {code}
> The original torque-templates jar is v3.3. The overridden torque-templates
> jar is v3.3.1.
> As the plugin gives no clues as to which version is being used, I deleted the
> original torque-templates v3.3 release from the local repository. What I
> expected to see was maven ignoring the v3.3 jar and using the v3.3.1 jar
> instead, but maven tries to re-download the v3.3 release and use it instead.
> maven-torque-plugin depends on torque-gen, which in turn depends on
> torque-templates. It may be that direct plugin dependencies can be
> overridden, but transitive plugin dependencies cannot be overridden.
--
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: (MSHADE-52) non-attached shade in pom package fails
[
http://jira.codehaus.org/browse/MSHADE-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MSHADE-52.
---
Resolution: Fixed
Fix Version/s: 1.3
Assignee: Benjamin Bentmann
Fixed in [r894704|http://svn.apache.org/viewvc?view=revision&revision=894704].
@Benson:
The next plugin version will exclude the project main artifact if it is of type
"pom" just like the plugin already does for the dependencies. Furthermore, a
new parameter {{outputFile}} has been added to simply save the shaded artifact
somewhere rather than attaching it or replacing the main artifact.
@Larry:
You seem to describe a different use case than Benson. The general way to
define plugin configuration/executions to be inherited by child modules is to
declare the plugin inside the {{}} section of the parent POM
and to use
{code:xml}
maven-shade-plugin
{code}
inside the child modules that want to actually use/run the plugin as defined by
the parent.
> non-attached shade in pom package fails
> ---
>
> Key: MSHADE-52
> URL: http://jira.codehaus.org/browse/MSHADE-52
> Project: Maven 2.x Shade Plugin
> Issue Type: Bug
>Affects Versions: 1.2.1
>Reporter: Benson Margulies
>Assignee: Benjamin Bentmann
> Fix For: 1.3
>
> Attachments: MSHADE-52.patch, MSHADE-52.patch
>
>
> I have a project with POM packaging. It's purpose is to run the assembly
> plugin to prepare releases. I don't want any artifacts except the POM, since
> the resulting release is a zip file that isn't a maven artifact.
> As part of the process, I configure shade to mush together various other
> artifacts into a big jar that goes into the releases. So, I specified
> finalName and turned off attachment, and I am rewarded with the following.
> Note that i do have the right phase and goal.
> INFO] Unpacking
> /Users/benson/.m2/repository/com/basistech/rlpj/dictionaries/0.8-SNAPSHOT/dictionaries-0.8-SNAPSHOT.jarto
> /Users/benson/x/trunk/greenhouse/etrog/distribution/target/dicts
> with Includes null and excludes:null
> [INFO] [site:attach-descriptor]
> [INFO] [shade:shade {execution: default}]
> [ERROR] The project main artifact does not exist. This could have the
> following
> [ERROR] reasons:
> [ERROR] - You have invoked the goal directly from the command line. This is
> not
> [ERROR] supported. Please add the goal to the default lifecycle via an
> [ERROR]element in your POM and use "mvn package" to have it
> run.
> [ERROR] - You have bound the goal to a lifecycle phase before "package".
> Please
> [ERROR] remove this binding from your POM such that the goal will be run in
> [ERROR] the proper phase.
--
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-3339) Embedder does not resolve transitive dependencies in multi-module project, unless the modules were installed into local repository previously.
[ http://jira.codehaus.org/browse/MNG-3339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-3339. -- Resolution: Cannot Reproduce Fix Version/s: (was: 3.x) > Embedder does not resolve transitive dependencies in multi-module project, > unless the modules were installed into local repository previously. > -- > > Key: MNG-3339 > URL: http://jira.codehaus.org/browse/MNG-3339 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0 >Reporter: Anton Makeev > Attachments: transitive-deps.zip > > > I've attached the project that have three modules: > m1 (depends on m2) > m2 (depends on m3) > m3 (depends on junit) > all the dependencies are of the 'compile' scope. > I would expect that embedder resolves dependencies for m1 into m2, m3, and > junit. > But it doesn't do that if repository does not contain these modules > installed. The only dependency is the direct one (m2). > On the other hand, if I previously install the entire project into > repository, I'll have the expected behaviour. -- 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-3408) Artifacts with the same pair groupId:artifactId but different type are not resolved independently
[ http://jira.codehaus.org/browse/MNG-3408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3408: --- Fix Version/s: (was: 3.x) 3.0-alpha-7 > Artifacts with the same pair groupId:artifactId but different type are not > resolved independently > - > > Key: MNG-3408 > URL: http://jira.codehaus.org/browse/MNG-3408 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.8 >Reporter: Nicolas Malassigné > Fix For: 3.0-alpha-7 > > > This problem is preventing for instance parallel builds to run in a > continuous server, without broken builds being falsely reported from time to > time. > Ex: > - Project B is depending on artifacts from Project A. > - Builds for Project A and Project B are both triggered at the same time. > - The build of project A finishes earlier, so that Project A deploys its > artifacts while Project B is still building (replacing the previous > artifacts). > What can happen is that the build of Project B suddenly breaks, because it > needs an artifact of Project A for which it already resolved the dependency, > but yet of a different type. Maven is writing the local metadata file when > resolving the pair groupId:artifactId of the first type, and is reading the > same metadata file when resolving the same pair of the second type (which may > come later in the build). > Actually I think that groupId:artifactId:type should be considered for the > uniqueness of artifacts instead of groupId:artifactId, and this information > be contained in the local metadata files. -- 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-3656) Collect all version information in the top-level POM, and manage with a set of properties
[ http://jira.codehaus.org/browse/MNG-3656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-3656. -- Resolution: Incomplete Fix Version/s: (was: 3.x) > Collect all version information in the top-level POM, and manage with a set > of properties > - > > Key: MNG-3656 > URL: http://jira.codehaus.org/browse/MNG-3656 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.0-alpha-1, 3.0-alpha-1 >Reporter: Jason van Zyl > > The impetus is to control the versions used from one simple location. We have > had many proposals in the past, but in the short term a set of properties is > easy to manipulate using execution request properties. This allows the > collection in small, short span in the POM and will allow the easy swapping > of versions for inter-component/library integration builds. -- 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-3656) Collect all version information in the top-level POM, and manage with a set of properties
[ http://jira.codehaus.org/browse/MNG-3656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204607#action_204607 ] Jason van Zyl commented on MNG-3656: This is really a best practice at this point. Not a bug. > Collect all version information in the top-level POM, and manage with a set > of properties > - > > Key: MNG-3656 > URL: http://jira.codehaus.org/browse/MNG-3656 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.0-alpha-1, 3.0-alpha-1 >Reporter: Jason van Zyl > > The impetus is to control the versions used from one simple location. We have > had many proposals in the past, but in the short term a set of properties is > easy to manipulate using execution request properties. This allows the > collection in small, short span in the POM and will allow the easy swapping > of versions for inter-component/library integration builds. -- 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-4176) Proxy settings are ignored
[ http://jira.codehaus.org/browse/MNG-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-4176. -- Resolution: Incomplete Fix Version/s: (was: 2.2.x) > Proxy settings are ignored > -- > > Key: MNG-4176 > URL: http://jira.codehaus.org/browse/MNG-4176 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.1.0 > Environment: Windows XP SP3, JDK 1.6.0_13 >Reporter: Matthias Hryniszak > > The following settings in settings.xml in user's home dir have no effect > while downloading artifacts from behind a proxy server: > > > true > http > proxy.host.com > 80 > my-user-name > my-password > > > > Setting java proxy settings using MAVEN_OPTS=-Dhttp.proxyHost=proxy.host.com > -Dhttp.proxyPort=80 -Dhttp.proxyUser=my-user-name > -Dhttp.proxyPassword=my-password works as expected. -- 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
