[jira] Created: (MNG-4712) Access final artifact properties such as uniqueVersion within Maven
Access final artifact properties such as uniqueVersion within Maven
---
Key: MNG-4712
URL: http://jira.codehaus.org/browse/MNG-4712
Project: Maven 2 & 3
Issue Type: Improvement
Components: Artifacts and Repositories
Affects Versions: 2.2.1
Environment: 64-bit Linux 2.6.18-128 (x86_64)
Reporter: thinkpipes
Access to properties about the final artifact, such as the final, constructed
uniqueVersion, filename, would be extremely useful.
During deployment, I store a build's info in a local MySQL db that includes the
URL where the artifact is deployed (to Nexus). However, I can't reliably do
this when uniqueVersion=true.
With the assembly plugin, I can construct a file name myself (and store in the
db with the sql-maven-plugin), however this requires the developer to adhere to
my final name format. Plus, with multi-module projects, I'd have to define a
different assembly plugin for each module.
I want to be able to save the final constructed artifact name (with the
uniqueVersion already defined) in a user-definable property, like so:
this.jar.final
(call the XML tag whatever fits best)
This would be perfect for multi-module projects, as I would be able to save and
reference each modules' final constructed artifact name in a property I define,
if I so choose (e.g. ${this.jar.final} using the example above).
I looked through the code, and unless I'm reading it incorrectly, referencing
/[Apache-SVN]/maven/maven-2/branches/maven-2.2.x/maven-artifact-manager/src/main/java/org/apache/maven/artifact/transform/SnapshotTransformation.java,
I'm basically suggesting having an easy way to expose the members in the
Snapshot object, as used in the transformForDeployment and constructVersion
methods.
It would be great if this could then be extended to things like file size and
extension, however for now, just getting the uniqueVersion would be terrific.
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] Issue Comment Edited: (MNG-4391) DependencyManagement should allow to manage use of re-named, woven, instrumented or compatible artifacts
[
http://jira.codehaus.org/browse/MNG-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194429#action_194429
]
Neale edited comment on MNG-4391 at 6/17/10 2:37 AM:
-
I don't get your objection. What's the 'relocation logic' problem?
Direct artifact substitution is what in many cases the developer needs, so
surely the "good idea" test is whether it makes Maven easier to use and
maintain.
If you look at the comments on MNG-1977, you'll find David Jencks and Kees de
Kooter suggesting the same as me.
was (Author: neale87):
I don't get your objection. What's the 'relocation logic' problem?
Direct artifact substitution is what in many cases the developer needs, so
surely the "good idea" test is whether it makes Maven easier to use and
maintain.
If you look at the comments on MNG-1977, you'll find David Jencks and Kees de
Kooter suggesting the same is me.
> DependencyManagement should allow to manage use of re-named,
> woven, instrumented or compatible artifacts
> --
>
> Key: MNG-4391
> URL: http://jira.codehaus.org/browse/MNG-4391
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 2.2.1
>Reporter: Neale
>
> [if only this was a later version of JIRA I'd have not lost all of what I
> just typed, as I could use Mylyn instead of the web UI. here goes again...]
> The challenge of using a different artifact instead of the one that is
> specified in a POM that you are consuming is not an easy one.
> Examples where this hits uses is:
> - the artifact name and packaging changes that Spring made at 2.5.6A (which
> was a big improvement)
> - wanting to use SLF4J instead of Apache commons logging (i.e. use something
> that provides the same API, but is an entirely different project)
> - wanting to use your own derivation of a public artifact
> - wanting to use a woven/instrumented version of a public artifact
> The current approach to replacing, say org.springframework : spring-beans
> with org.springframework : org.springframework.beans is to do ('scuse the
> shorthand):
> {code:xml}
>
>
>
> com.sun.jersey.contribs
> jersey-spring
>
>org.springframework : spring-beans
>
>
> ... repeat for every artifact that uses spring-beans, and then add more
> if adding another artifact
>
>
> {code}
> to exclude it, and then globally include the replacement using:
> {code:xml}
>
>
> org.springframework
> org.springframework.beans
> ${spring.version}
>
>
> {code}
> This is error prone, and could be made far easier by an extension to
> dependencies, which would remove the need to know what artifacts
> (jersey-spring in the above example) use the artifact that you are replacing.
> Here's how it would look:
> {code:xml}
>
>
>
>
> org.springframework
> org.springframework.beans
> ${spring.version}
>
>
>
> org.springframework
> spring-beans
>
>
> org.springframework
> org.springframework.beans
>
>
>
>
>
> {code}
> NOTE:
> - Nothing is specified in so no artifacts are globally added
> where they may not be needed. This means we can develop a project wide
> parent pom.xml.
> - Artifacts can have been split and merged
> - Derived artifacts, such as instrumented ones can easily be substituted, and
> could be selectively substituted using profiles.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-318) not correctly filtered
not correctly filtered
Key: ARCHETYPE-318
URL: http://jira.codehaus.org/browse/ARCHETYPE-318
Project: Maven Archetype
Issue Type: Bug
Components: Generator
Affects Versions: 2.0-alpha-5
Reporter: Jochen Ehret
Priority: Minor
In our archetype-metadata.xml we´ve defined a with a default
value like this:
${artifactId}.itest1
When we call "archetype:generate" and enter the parameters in interactive mode
everything works fine. But when we try to set the parameter "subArtifactId" on
the command line (mvn archetype:generate -DsubArtifactId=xyz) or from an
"archetype.properties" file, the value is ignored. In the generated pom.xml the
variable ${subArtifactId} is always replaced with "${artifactId}.itest1".
--
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: (MDEP-269) Goal to convert a legacy /lib/*.jar to maven dependencies list
Goal to convert a legacy /lib/*.jar to maven dependencies list -- Key: MDEP-269 URL: http://jira.codehaus.org/browse/MDEP-269 Project: Maven 2.x Dependency Plugin Issue Type: New Feature Reporter: nicolas de loof Assignee: Brian Fox Priority: Minor To convert a legacy ant/script-based project to Maven first step is to identify all dependencies as maven artifacts. This can be long and subject to errors. Using Nexus index [1], Nexus REST API [2], or any other tooling, the plugin could automagically search the available repositories for known artifacts to match the content of a /lib directory, and output a POM formatted list of dependencies, also warning for unresolved ones. alf-maven-osecm plugin allready provides such feature using a custom CSV format, this code can be used as a dev sample. [1] http://www.sonatype.com/people/2009/06/nexus-indexer-api-part-2/ [2] https://docs.sonatype.com/display/NX/Nexus+Rest+API [3] http://alf-maven-osecm.googlecode.com/svn/trunk/dependenciesGenerator-maven-plugin/dependenciesGenerator-maven-plugin/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MDEP-269) Goal to convert a legacy /lib/*.jar to maven dependencies list
[ http://jira.codehaus.org/browse/MDEP-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nicolas de loof updated MDEP-269: - Description: To convert a legacy ant/script-based project to Maven first step is to identify all dependencies as maven artifacts. This can be long and subject to errors. Using Nexus index [1], Nexus REST API [2], or any other tooling, the plugin could automagically search the available repositories for known artifacts to match the content of a /lib directory, and output a POM formatted list of dependencies, also warning for unresolved ones. alf-maven-osecm plugin allready provides such feature using a custom CSV format, this code can be used as a dev sample. [1] http://www.sonatype.com/people/2009/06/nexus-indexer-api-part-2/ [2] https://docs.sonatype.com/display/NX/Nexus+Rest+API [3] http://alf-maven-osecm.googlecode.com/svn/trunk/dependenciesGenerator-maven-plugin/dependenciesGenerator-maven-plugin/ http://opensourceecm.fr/maven/dependenciesGenerator/index.html was: To convert a legacy ant/script-based project to Maven first step is to identify all dependencies as maven artifacts. This can be long and subject to errors. Using Nexus index [1], Nexus REST API [2], or any other tooling, the plugin could automagically search the available repositories for known artifacts to match the content of a /lib directory, and output a POM formatted list of dependencies, also warning for unresolved ones. alf-maven-osecm plugin allready provides such feature using a custom CSV format, this code can be used as a dev sample. [1] http://www.sonatype.com/people/2009/06/nexus-indexer-api-part-2/ [2] https://docs.sonatype.com/display/NX/Nexus+Rest+API [3] http://alf-maven-osecm.googlecode.com/svn/trunk/dependenciesGenerator-maven-plugin/dependenciesGenerator-maven-plugin/ > Goal to convert a legacy /lib/*.jar to maven dependencies list > -- > > Key: MDEP-269 > URL: http://jira.codehaus.org/browse/MDEP-269 > Project: Maven 2.x Dependency Plugin > Issue Type: New Feature >Reporter: nicolas de loof >Assignee: Brian Fox >Priority: Minor > > To convert a legacy ant/script-based project to Maven first step is to > identify all dependencies as maven artifacts. This can be long and subject to > errors. > Using Nexus index [1], Nexus REST API [2], or any other tooling, the plugin > could automagically search the available repositories for known artifacts to > match the content of a /lib directory, and output a POM formatted list of > dependencies, also warning for unresolved ones. > alf-maven-osecm plugin allready provides such feature using a custom CSV > format, this code can be used as a dev sample. > [1] http://www.sonatype.com/people/2009/06/nexus-indexer-api-part-2/ > [2] https://docs.sonatype.com/display/NX/Nexus+Rest+API > [3] > http://alf-maven-osecm.googlecode.com/svn/trunk/dependenciesGenerator-maven-plugin/dependenciesGenerator-maven-plugin/ > http://opensourceecm.fr/maven/dependenciesGenerator/index.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] Created: (SUREFIRE-624) Surefire Report plugin should generate different names for invocations of a method that uses parameters/data provider
Surefire Report plugin should generate different names for invocations of a method that uses parameters/data provider - Key: SUREFIRE-624 URL: http://jira.codehaus.org/browse/SUREFIRE-624 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Report Plugin, TestNG support Affects Versions: 2.5 Reporter: Oleg Estekhin If there is a test method that uses some data provider than the generated report will contain a number of lines with the same text (the plain method name) which correspond to the different invocations of that method with different parameters. The testng-results.xml contains parameter values for each invocation therefore surefire report can display the proper text for each invocation consisting of the plain method name and a list of actual parameter values. -- 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-262) Add support for custom ProjectDependencyAnalyzer implementations
[ http://jira.codehaus.org/browse/MDEP-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=225613#action_225613 ] Pablo Gra\~na commented on MDEP-262: I am also needing this, is there something I can help to get this integrated? > Add support for custom ProjectDependencyAnalyzer implementations > > > Key: MDEP-262 > URL: http://jira.codehaus.org/browse/MDEP-262 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: analyze >Reporter: Tobias Gierke >Assignee: Brian Fox > Attachments: maven-dependency-analyzer_1.2.patch, > maven-dependency-plugin_2.2.patch > > > I've written a customized ProjectDependencyAnalyzer (includes dependencies > from Spring XMLs) that I'd like to be able to use with the > maven-dependency-plugin. > The current plugin implementation only supports a single > ProjectDependencyAnalyzer component on the classpath (otherwise plexus will > fail) and has no way of specifying which analyzer to use at runtime. > The appended patches add support for custom ProjectDependencyAnalyzer > components to the plugin. The basic idea is to assign > ProjectDependencyAnalyzer components a unique role-hint and let the plugin > dynamically look-up the implementation to use by specifying the role-hint as > configuration parameter. > 1. maven-dependency-analyzer_1.2.patch > Patch against maven-dependency-analyzer 1.2-SNAPSHOT (trunk / r942613) > To apply patch: patch -p1 CHANGES: > - DefaultProjectDependencyAnalyzer component now has an additonal role-hint > 'default' so > plexus won't complain when multiple ProjectDependencyAnalyzer components are > one the classpath > - changes the visibility of buildDependencyClasses() and > findArtifactForClassName() from private to protected to allow subclassing > - buildDependencyClasses() now takes the artifact map as additional parameter > so subclasses can call findArtifactForClassName() with it > 2. maven-dependency-plugin_2.2.patch > Patch against maven-dependency-plugin 2.2-SNAPSHOT (trunk / r942613) > To apply patch: patch -p1 CHANGES: > - AbstractDependencyMojo now has a new 'analyzer' parameter that is the role > hint to use when > looking up the ProjectDependencyAnalyzer from the container ( the default > value is set to 'default' and thus references > DefaultProjectDependencyAnalyzer) > - AbstractDependencyMojo now implements Contextualizable and dynamically > looks up the ProjectDependencyAnalyzer component to use from the plexus > container > - Integration test added that first buids and installs a custom dummy > ProjectDependencyAnalyzer component > and then runs dependency:analyze with this analyzer -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MANTRUN-143) Regression: 1.4 does not resolve $(settings.localRepository} or ${localRepository}
[
http://jira.codehaus.org/browse/MANTRUN-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=225650#action_225650
]
Antonio Petrelli commented on MANTRUN-143:
--
Confirmed in Tiles. For source see:
http://svn.eu.apache.org/repos/asf/tiles/framework/trunk/assembly/pom.xml
Error message during release:
An Ant BuildException has occured:
//tiles-2.2.2/assembly/${settings.localRepository}/org/apache/tiles/tiles-assembly/2.2.2
does not exist.
> Regression: 1.4 does not resolve $(settings.localRepository} or
> ${localRepository}
> --
>
> Key: MANTRUN-143
> URL: http://jira.codehaus.org/browse/MANTRUN-143
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.4
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 20:16:01+0100)
> Java version: 1.6.0_20
> Java home: C:\jdk1.6.0_20\jre
> Default locale: en_GB, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: SebbASF
> Attachments: pom.xml
>
>
> Antrun 1.4 fails to resolve the properties localRepository and
> settings.localRepository, whereas 1.3 works fine;
> Properties are resolved OK with 1.3:
> {code}
> > mvn -Dantrun.version=1.3
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building anttest
> [INFO]task-segment: [validate]
> [INFO]
>
> [INFO] [antrun:run {execution: default}]
> [INFO] Executing tasks
> [echo] project.version = 1.0-SNAPSHOT
> [echo] antrun.version = 1.3
> [echo] localRepository = Repository[local|file://C:\Documents and
> Settings\User\.m2\repository]
> [echo] settings.localRepository = C:\Documents and
> Settings\User\.m2\repository
> [INFO] Executed tasks
> {code}
> Properties are not resolved when running with 1.4:
> {code}
> > mvn -Dantrun.version=1.4
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building anttest
> [INFO]task-segment: [validate]
> [INFO]
>
> [INFO] [antrun:run {execution: default}]
> project.artifactId
> [INFO] Executing tasks
> [echo] project.version = 1.0-SNAPSHOT
> [echo] antrun.version = 1.4
> [echo] localRepository = ${localRepository}
> [echo] settings.localRepository = ${settings.localRepository}
> [INFO] Executed tasks
> {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] Closed: (MAVENUPLOAD-2788) Remove artifacts
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MAVENUPLOAD-2788. - Resolution: Fixed Assignee: Brett Porter looks good now > Remove artifacts > > > Key: MAVENUPLOAD-2788 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2788 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Blaine Simpson >Assignee: Brett Porter > > Simple directory removal request. > I do not want a Maven Upload, but just to wipe some artifacts that you are > already mirroring to ibiblio (so that I can fix them). I am only opening > this issue under this project because there is no other relevant "project" to > fix issues with artifacts already in place. I figure that the techs who can > work Upload tickets should know how to get to the mock-ftp staging or ibiblio > production servers and know where the maven2 artifacts reside there. > My problem is, you already picked up, by rsync, my new resources for my new > project version 2.0.0. There was a mistake in the .pom files which was > discovered after your pick-up. Not a big deal with the .pom mistake-- I > fixed that in 5 minutes. But your rsync pickup job refuses to modify > existing hosted artifacts, very likely because of the --ignore-existing > switch that you use for rsync. > If you could just get on the staging or production servers as needed and wipe > out all of the 2.0.0 subdirectories at the level > http://repo2.maven.org/maven2/org/hsqldb/*/2.0.0/ , that should be all that > is needed (there are 4 directories at the same exact level, all grandchildren > of http://repo2.maven.org/maven2/org/hsqldb/). > I have a lot of experience with rsync, and with UNIX and scripting generally, > so let me know if I can help in any way. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-496) Branch not working in batch mode
[ http://jira.codehaus.org/browse/MRELEASE-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=225720#action_225720 ] Lachlan Deck commented on MRELEASE-496: --- Still unassigned/unresolved... anyone able to pick this up, test it and commit? Cheers. > Branch not working in batch mode > > > Key: MRELEASE-496 > URL: http://jira.codehaus.org/browse/MRELEASE-496 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: branch >Affects Versions: 2.0-beta-9 > Environment: Apache Maven 2.1.0 (r755702; 2009-03-19 06:10:27+1100) > Java version: 1.6.0_10 > Java home: /usr/java/jdk1.6.0_10/jre > Default locale: en_AU, platform encoding: UTF-8 > OS name: "linux" version: "2.6.30.8-64.fc11.x86_64" arch: "amd64" Family: > "unix" >Reporter: Matt Milliss > Attachments: patch_branch_version_defaults.txt > > > Creating a branch batch mode fails. > From a trunk version 09.20.00-SNAPSHOT I try to create a branch with the > version 09.20.01-SNAPSHOT. > The following command to branch in non-batch mode works fine, > mvn release:branch -DbranchName=09.20.00_BRANCH -DupdateBranchVersions=true > -DupdateWorkingCopyVersions=false > when prompted for the branch version I enter 09.20.01-SNAPSHOT, this works as > expected and the branch is created with the version 09.20.01-SNAPSHOT. > In batch mode the following command creates a branch with the same version as > trunk > mvn release:branch -DbranchName=09.20.00_BRANCH -DupdateBranchVersions=true > -DupdateWorkingCopyVersions=false > -Dproject.rel.my.org:myProject=09.20.01-SNAPSHOT --batch-mode -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4713) ${basedir} variable makes portable builds overly difficult
${basedir} variable makes portable builds overly difficult
--
Key: MNG-4713
URL: http://jira.codehaus.org/browse/MNG-4713
Project: Maven 2 & 3
Issue Type: Bug
Components: Design, Patterns & Best Practices
Affects Versions: 2.2.1
Reporter: Gili
Please reopen MNG-3198. I believe that Brett misunderstood what Jochen wrote.
There is no simple workaround with the current Maven implementation. Jochen was
saying that Maven should use unix-style slashes under Windows for the sake of
portability and let users convert to Windows-style slashes themselves if they
wish to use an external script.
Simple use-case: try passing a ${basedir}-relative path into the
"java.library.path" property. It's impossible to do this portably under Maven's
existing implementation.
--
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
