[jira] Closed: (MDEP-208) finalName of artifacts not in the reactor is not taken into account.
[ https://jira.codehaus.org/browse/MDEP-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MDEP-208. - Resolution: Fixed with version 2.3 the dependency:copy and dependency:unpack goals resolve from the reactor and the artifactItems allows exact control over the copied or unpacked artifact names. finalName of artifacts not in the reactor is not taken into account. Key: MDEP-208 URL: https://jira.codehaus.org/browse/MDEP-208 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: copy-dependencies, unpack-dependencies Affects Versions: 2.0 Reporter: Maarten Billemont Assignee: Brian Fox Fix For: 2.2 Setting: A project where module B has a dependency on module A. Module B uses copy-dependencies to copy that dependency into a certain directory. What works: When both module A and B are in the maven reactor, module A's finalName is taken into account and the artifact that ends up copied into our directory uses the filename as given by finalName. What doesn't work: When only module B is in the maven reactor, module A is copied from the local repository where it has a different filename. Maven-dependency-plugin does not correct the filename during copy and as a result we have an artifact in our destination directory with a different name. This behavior is inconsistent and a solution should be established. I propose maven-dependency-plugin reads the dependency (A)'s POM and checks whether it has a finalName set. If so, it should modify the destination filename of the dependency copy operation accordingly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEP-270) mvn dependency:sources fails to download sources for dependencies with classifier
[
https://jira.codehaus.org/browse/MDEP-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly closed MDEP-270.
-
Resolution: Won't Fix
The artifact in question is not following maven conventions.
The maven convention is to have one GAV coordinate for each artifact, so there
really should be a artifactIdjson-lib-jdk15/artifactId not a classifier.
Part of the logic for this is that dependencies for jdk15 may be different than
for jdk14 and using classifiers does not allow for different dependencies.
The other indicator that this artifact is not following the maven conventions
is that they have deployed two different sets of sources.
This plugin goal assumes that your artifacts are following the Maven
conventions... maven is all about the conventions after all. Pester the project
to follow the maven conventions as I do not see the value in adding a hack into
the dependency plugin just to support one project that is not following the
conventions.
mvn dependency:sources fails to download sources for dependencies with
classifier
---
Key: MDEP-270
URL: https://jira.codehaus.org/browse/MDEP-270
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: sources
Affects Versions: 2.1
Environment: Mac OS 10.6
Reporter: Peter Niederwieser
Assignee: Brian Fox
Priority: Critical
Given the following dependency:
{noformat}
dependency
groupIdnet.sf.json-lib/groupId
artifactIdjson-lib/artifactId
version2.3/version
classifierjdk15/classifier
optionaltrue/optional
/dependency
{noformat}
mvn dependency:sources fails to download the sources although they are
clearly in Maven Central (see
http://repo2.maven.org/maven2/net/sf/json-lib/json-lib/2.3/). My guess is
that the jdk15 classifier is overridden with sources.
Workaround is to use mvn dependency:resolve -Dclassifier=jdk15-sources,
which seems to work. Of course, you'd have to do this for every dependency
that has a classifier. Also, most people won't even get that far. They will
simply think that the sources are not available.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEP-106) Unpacking primary artifact from sibling module uses repository rather than reactor
[
https://jira.codehaus.org/browse/MDEP-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly closed MDEP-106.
-
Resolution: Duplicate
Fix Version/s: 2.3
MDEP-316
Unpacking primary artifact from sibling module uses repository rather than
reactor
--
Key: MDEP-106
URL: https://jira.codehaus.org/browse/MDEP-106
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: unpack
Affects Versions: 2.0-alpha-4
Reporter: Matt Ryall
Assignee: Brian Fox
Fix For: 2.3
Running dependency:unpack referencing a project in the reactor has the
following output which shows it is scanning for repository artifacts rather
than the artifact in the reactor:
{quote}
[INFO] [dependency:unpack \{execution: unpack-tests}]
[INFO] Configured Artifact:
com.example.app:app-acceptance-test:2.6-SNAPSHOT:jar
[INFO] snapshot com.example.app:app-acceptance-test:2.6-SNAPSHOT: checking
for updates from snapshots
[INFO] snapshot com.example.app:app-acceptance-test:2.6-SNAPSHOT: checking
for updates from m1-repo
Downloading:
http://m2proxy:8081/artifactory/repo/com/example/app/app-acceptance-test/2.6-SNAPSHOT/app-acceptance-test-2.6-20070829.025709-409.jar
9125K downloaded
[INFO] Expanding:
/Users/mryall/.m2/repository/com/example/app/app-acceptance-test/2.6-SNAPSHOT/app-acceptance-test-2.6-SNAPSHOT.jar
into /Users/mryall/src/example/app/app-webapp/target/it-classes
{quote}
To explain the scenario: to build reusable acceptance tests, I have the
following sub-modules of my project:
- app-core (jar)
- app-acceptance-tests (jar)
- app-webapp (war)
The acceptance tests are packaged this way for further use in testing, and
also run against the webapp in the integration-test phase. This is where the
problem arises.
Running 'mvn clean integration-test' does the following relevant tasks:
- in the app-acceptance-test module, compiles and packages a JAR of tests
- in the app-webapp module, uses the dependency:unpack goal to extract the
tests into target/it-classes in the pre-integration-test phase, and test:test
to run them in the integration test phase.
I don't think this is caused by the snapshot version, because the release
plugin also fails because it is unable to find the 2.6 version when it runs
'mvn clean verify'. There, it scans all the repositories for the acceptance
test artifact before failing with the usual error:
{quote}
[INFO] Failed to resolve artifact.
GroupId: com.example.app
ArtifactId: app-acceptance-test
Version: 2.6
Reason: Unable to download the artifact from any repository
{quote}
Maven details:
{noformat}
$ mvn -version
Maven version: 2.0.7
Java version: 1.4.2_12
OS name: mac os x version: 10.4.10 arch: i386
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4142) Maven doesn't try to download a dependency when it already exists a version with classifier locally
[
https://jira.codehaus.org/browse/MNG-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=273210#comment-273210
]
nodje commented on MNG-4142:
I've the same problem but with standard SNAPSHOT dependencies, not using
classifier, and with 3.0.3.
Maven doesn't try to download a dependency when it already exists a version
with classifier locally
---
Key: MNG-4142
URL: https://jira.codehaus.org/browse/MNG-4142
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.0.9, 2.0.10, 2.1.0
Environment: Java 5, Windows XP
Reporter: Arnaud Heritier
Priority: Critical
Fix For: Issues to be reviewed for 3.x
Attachments: MNG-4142.patch, test-metadata-local-clover.zip
When maven installs in the local repository an artifact with a classifier,
and not the principal artifact, it won't try in a reactor to download the
principal artifact from the remote repository.
I created a testcase to reproduce it. It's quite simple. You unzip it and in
the root directory you launch {code}mvn site{code}
This build uses clover, thus it installs locally cloverified versions of
artifacts.
The build will fail because it doesn't find the SNAPSHOT of the module1 :
{code}
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file
-DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
-Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/pa
th/to/file
Alternatively, if you host your own repository you can deploy the file
there:
mvn deploy:deploy-file
-DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
-Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path
/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1)
org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
2)
org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
--
1 required artifact is missing.
for artifact:
org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
from the specified remote repositories:
central (http://maven-proxy.groupe.generali.fr/all),
remote-repo
(file://E:\jtb\workspaces\tests\test-metadata-local-clover/remote-repo)
{code}
It's anormal because I set a local remote repository in the build where it
should try to download it.
You can validate that it is working by launching :
{code}mvn install -f module2/pom.xml{code}
This bug is really annoying for us. It exists for a long long time now. I
thought it was due to a problem with metadata sent by archiva, but after
migrating to nexus the problem always occurs.
I don't know if the problem is in metadata or in the reactor itself. I think
it is the second one. There are many issues opened about the reactor and
classifiers.
Is there some who can try if it can reproduce the error with my testcase ?
It should be easy to create a real IT for maven with it if it is necessary.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4142) Maven doesn't try to download a dependency when it already exists a version with classifier locally
[
https://jira.codehaus.org/browse/MNG-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=273211#comment-273211
]
Martin Todorov commented on MNG-4142:
-
This bug/feature doesn't really have much to do with classifiers. I believe the
original bug report filer just thought it had something to do with the problem.
Perhaps somebody should rename the bug to Maven doesn't try to download
SNAPSHOT artifacts, if you've installed them locally; even if you pass -U.
I believe that by using -U the local metadata should get unlocked for the
locally installed SNAPSHOT artifacts.
Maven doesn't try to download a dependency when it already exists a version
with classifier locally
---
Key: MNG-4142
URL: https://jira.codehaus.org/browse/MNG-4142
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.0.9, 2.0.10, 2.1.0
Environment: Java 5, Windows XP
Reporter: Arnaud Heritier
Priority: Critical
Fix For: Issues to be reviewed for 3.x
Attachments: MNG-4142.patch, test-metadata-local-clover.zip
When maven installs in the local repository an artifact with a classifier,
and not the principal artifact, it won't try in a reactor to download the
principal artifact from the remote repository.
I created a testcase to reproduce it. It's quite simple. You unzip it and in
the root directory you launch {code}mvn site{code}
This build uses clover, thus it installs locally cloverified versions of
artifacts.
The build will fail because it doesn't find the SNAPSHOT of the module1 :
{code}
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file
-DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
-Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/pa
th/to/file
Alternatively, if you host your own repository you can deploy the file
there:
mvn deploy:deploy-file
-DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
-Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path
/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1)
org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
2)
org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
--
1 required artifact is missing.
for artifact:
org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
from the specified remote repositories:
central (http://maven-proxy.groupe.generali.fr/all),
remote-repo
(file://E:\jtb\workspaces\tests\test-metadata-local-clover/remote-repo)
{code}
It's anormal because I set a local remote repository in the build where it
should try to download it.
You can validate that it is working by launching :
{code}mvn install -f module2/pom.xml{code}
This bug is really annoying for us. It exists for a long long time now. I
thought it was due to a problem with metadata sent by archiva, but after
migrating to nexus the problem always occurs.
I don't know if the problem is in metadata or in the reactor itself. I think
it is the second one. There are many issues opened about the reactor and
classifiers.
Is there some who can try if it can reproduce the error with my testcase ?
It should be easy to create a real IT for maven with it if it is necessary.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-4142) Maven doesn't try to download a dependency when it already exists a version with classifier locally
[
https://jira.codehaus.org/browse/MNG-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=273211#comment-273211
]
Martin Todorov edited comment on MNG-4142 at 7/14/11 3:36 AM:
--
This bug/feature doesn't really have much to do with classifiers. I believe the
original bug report filer just thought it had something to do with the problem.
Perhaps somebody should rename the bug to Maven doesn't try to download
SNAPSHOT artifacts, if you've installed them locally; even if you pass -U.
I believe that by using -U the local metadata should get unlocked (which
currently doesn't do this) for the locally installed SNAPSHOT artifacts.
was (Author: carlspring):
This bug/feature doesn't really have much to do with classifiers. I believe
the original bug report filer just thought it had something to do with the
problem.
Perhaps somebody should rename the bug to Maven doesn't try to download
SNAPSHOT artifacts, if you've installed them locally; even if you pass -U.
I believe that by using -U the local metadata should get unlocked for the
locally installed SNAPSHOT artifacts.
Maven doesn't try to download a dependency when it already exists a version
with classifier locally
---
Key: MNG-4142
URL: https://jira.codehaus.org/browse/MNG-4142
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.0.9, 2.0.10, 2.1.0
Environment: Java 5, Windows XP
Reporter: Arnaud Heritier
Priority: Critical
Fix For: Issues to be reviewed for 3.x
Attachments: MNG-4142.patch, test-metadata-local-clover.zip
When maven installs in the local repository an artifact with a classifier,
and not the principal artifact, it won't try in a reactor to download the
principal artifact from the remote repository.
I created a testcase to reproduce it. It's quite simple. You unzip it and in
the root directory you launch {code}mvn site{code}
This build uses clover, thus it installs locally cloverified versions of
artifacts.
The build will fail because it doesn't find the SNAPSHOT of the module1 :
{code}
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file
-DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
-Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/pa
th/to/file
Alternatively, if you host your own repository you can deploy the file
there:
mvn deploy:deploy-file
-DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
-Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path
/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1)
org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
2)
org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
--
1 required artifact is missing.
for artifact:
org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
from the specified remote repositories:
central (http://maven-proxy.groupe.generali.fr/all),
remote-repo
(file://E:\jtb\workspaces\tests\test-metadata-local-clover/remote-repo)
{code}
It's anormal because I set a local remote repository in the build where it
should try to download it.
You can validate that it is working by launching :
{code}mvn install -f module2/pom.xml{code}
This bug is really annoying for us. It exists for a long long time now. I
thought it was due to a problem with metadata sent by archiva, but after
migrating to nexus the problem always occurs.
I don't know if the problem is in metadata or in the reactor itself. I think
it is the second one. There are many issues opened about the reactor and
classifiers.
Is there some who can try if it can reproduce the error with my testcase ?
It should be easy to create a real IT for maven with it if it is necessary.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4142) Maven doesn't try to download a dependency when it already exists a version with classifier locally
[
https://jira.codehaus.org/browse/MNG-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=273213#comment-273213
]
nodje commented on MNG-4142:
alright, good then, that's my problem!
Can't wait for the fix to come, hopefully as early as 3.0.4...
Maven doesn't try to download a dependency when it already exists a version
with classifier locally
---
Key: MNG-4142
URL: https://jira.codehaus.org/browse/MNG-4142
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.0.9, 2.0.10, 2.1.0
Environment: Java 5, Windows XP
Reporter: Arnaud Heritier
Priority: Critical
Fix For: Issues to be reviewed for 3.x
Attachments: MNG-4142.patch, test-metadata-local-clover.zip
When maven installs in the local repository an artifact with a classifier,
and not the principal artifact, it won't try in a reactor to download the
principal artifact from the remote repository.
I created a testcase to reproduce it. It's quite simple. You unzip it and in
the root directory you launch {code}mvn site{code}
This build uses clover, thus it installs locally cloverified versions of
artifacts.
The build will fail because it doesn't find the SNAPSHOT of the module1 :
{code}
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file
-DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
-Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/pa
th/to/file
Alternatively, if you host your own repository you can deploy the file
there:
mvn deploy:deploy-file
-DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
-Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path
/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1)
org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
2)
org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
--
1 required artifact is missing.
for artifact:
org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
from the specified remote repositories:
central (http://maven-proxy.groupe.generali.fr/all),
remote-repo
(file://E:\jtb\workspaces\tests\test-metadata-local-clover/remote-repo)
{code}
It's anormal because I set a local remote repository in the build where it
should try to download it.
You can validate that it is working by launching :
{code}mvn install -f module2/pom.xml{code}
This bug is really annoying for us. It exists for a long long time now. I
thought it was due to a problem with metadata sent by archiva, but after
migrating to nexus the problem always occurs.
I don't know if the problem is in metadata or in the reactor itself. I think
it is the second one. There are many issues opened about the reactor and
classifiers.
Is there some who can try if it can reproduce the error with my testcase ?
It should be easy to create a real IT for maven with it if it is necessary.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MSITE-560) make maven-site-plugin 3.x work both with Maven 2.2 and Maven 3.x
[ https://jira.codehaus.org/browse/MSITE-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl reopened MSITE-560: - Herve: The IT inheritedMenus still fails with m3 but IIUC it should work according to the docs in maven-3.apt.vm. Can you check/confirm that? (note that the IT is currently skipped due to the invoker.properties restriction). make maven-site-plugin 3.x work both with Maven 2.2 and Maven 3.x - Key: MSITE-560 URL: https://jira.codehaus.org/browse/MSITE-560 Project: Maven 2.x and 3.x Site Plugin Issue Type: Improvement Components: Maven 3 Affects Versions: 3.0-beta-3 Reporter: Herve Boutemy Assignee: Herve Boutemy Fix For: 3.0 maintaining 2 branches in parallel is not easy, and mojo and reporting code is exactly the same: there are not so much differences -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-277) HttpClient wagon (wagon-http) uploads all files twice when preemptive authentication is disabled
[
https://jira.codehaus.org/browse/WAGON-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=273227#comment-273227
]
Jari Aarniala commented on WAGON-277:
-
I patched a version of the HTTP wagon for my needs based on the current trunk:
https://github.com/codeflows/maven-wagon
You can configure it to use pre-emptive basic auth (with HttpClient 4, based on
the example at
http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html)
per server like this:
{code:xml}
server
idyour-server-id/id
...
configuration
httpConfiguration
usePreemptiveBasicAuthtrue/usePreemptiveBasicAuth
/httpConfiguration
/configuration
/server
{code}
Can't say if this approach is without its problems, but it seems to work for us
(i.e. artifacts are only transferred once.)
HttpClient wagon (wagon-http) uploads all files twice when preemptive
authentication is disabled
Key: WAGON-277
URL: https://jira.codehaus.org/browse/WAGON-277
Project: Maven Wagon
Issue Type: Bug
Components: wagon-http
Affects Versions: 1.0-beta-6
Reporter: John Casey
Priority: Critical
This causes timeouts and tends to cause invalid checksums for anything that
attaches an observer to the stream or connection (Maven does). It seems that
the Sun (lightweight-http) wagon sends the first file twice, then caches the
authentication after a challenge and uses preemptive auth from then on. This
wagon should probably take steps to approximate this strategy, or possibly
even improve on it.
For an example of this, try deploying any artifact to a normal http
repository (Nexus uses bare HTTP PUT, for instance) with Maven 2.2.0, and
watch the checksums or logs to see how the transfer takes place.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (WAGON-277) HttpClient wagon (wagon-http) uploads all files twice when preemptive authentication is disabled
[
https://jira.codehaus.org/browse/WAGON-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=273227#comment-273227
]
Jari Aarniala edited comment on WAGON-277 at 7/14/11 7:09 AM:
--
I patched a version of the HTTP wagon for my needs based on the current trunk:
https://github.com/codeflows/maven-wagon
You can configure it to use pre-emptive basic auth (with HttpClient 4, based on
the example at
http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html)
per server like this:
{code:xml}
server
idyour-server-id/id
...
configuration
httpConfiguration
usePreemptiveBasicAuthtrue/usePreemptiveBasicAuth
/httpConfiguration
/configuration
/server
{code}
Can't say if this approach is without its problems, but it seems to work for us
(i.e. artifacts are only transferred once.)
This test case sums it up:
https://github.com/codeflows/maven-wagon/blob/trunk/wagon-providers/wagon-http/src/test/java/org/apache/maven/wagon/providers/http/HttpWagonTest.java#L43-52
was (Author: jari):
I patched a version of the HTTP wagon for my needs based on the current
trunk: https://github.com/codeflows/maven-wagon
You can configure it to use pre-emptive basic auth (with HttpClient 4, based on
the example at
http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html)
per server like this:
{code:xml}
server
idyour-server-id/id
...
configuration
httpConfiguration
usePreemptiveBasicAuthtrue/usePreemptiveBasicAuth
/httpConfiguration
/configuration
/server
{code}
Can't say if this approach is without its problems, but it seems to work for us
(i.e. artifacts are only transferred once.)
HttpClient wagon (wagon-http) uploads all files twice when preemptive
authentication is disabled
Key: WAGON-277
URL: https://jira.codehaus.org/browse/WAGON-277
Project: Maven Wagon
Issue Type: Bug
Components: wagon-http
Affects Versions: 1.0-beta-6
Reporter: John Casey
Priority: Critical
This causes timeouts and tends to cause invalid checksums for anything that
attaches an observer to the stream or connection (Maven does). It seems that
the Sun (lightweight-http) wagon sends the first file twice, then caches the
authentication after a challenge and uses preemptive auth from then on. This
wagon should probably take steps to approximate this strategy, or possibly
even improve on it.
For an example of this, try deploying any artifact to a normal http
repository (Nexus uses bare HTTP PUT, for instance) with Maven 2.2.0, and
watch the checksums or logs to see how the transfer takes place.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-277) HttpClient wagon (wagon-http) uploads all files twice when preemptive authentication is disabled
[ https://jira.codehaus.org/browse/WAGON-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jari Aarniala updated WAGON-277: Attachment: 0001-Support-for-pre-emptive-basic-authentication.patch Attached patch as well. HttpClient wagon (wagon-http) uploads all files twice when preemptive authentication is disabled Key: WAGON-277 URL: https://jira.codehaus.org/browse/WAGON-277 Project: Maven Wagon Issue Type: Bug Components: wagon-http Affects Versions: 1.0-beta-6 Reporter: John Casey Priority: Critical Attachments: 0001-Support-for-pre-emptive-basic-authentication.patch This causes timeouts and tends to cause invalid checksums for anything that attaches an observer to the stream or connection (Maven does). It seems that the Sun (lightweight-http) wagon sends the first file twice, then caches the authentication after a challenge and uses preemptive auth from then on. This wagon should probably take steps to approximate this strategy, or possibly even improve on it. For an example of this, try deploying any artifact to a normal http repository (Nexus uses bare HTTP PUT, for instance) with Maven 2.2.0, and watch the checksums or logs to see how the transfer takes place. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-494) No way to set the directory mode for the base directory nor any implicitly created directory for zip assemblies
[
https://jira.codehaus.org/browse/MASSEMBLY-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=273236#comment-273236
]
John Casey commented on MASSEMBLY-494:
--
Try the following assembly plugin configuration, in your pom.xml:
{code:xml}
archiverConfig
defaultDirectoryMode0755/defaultDirectoryMode
/archiverConfig
{code}
I've verified that this provides the ability to manage the default directory
mode for automatically created / implied directories.
No way to set the directory mode for the base directory nor any implicitly
created directory for zip assemblies
---
Key: MASSEMBLY-494
URL: https://jira.codehaus.org/browse/MASSEMBLY-494
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-5
Environment: Debian GNU/Linux
Reporter: Arnaud de Bossoreille
Attachments: assembly-test.zip
A sample maven project is attached to reproduce everything. I am trying to
generate a zip file with correct permissions (i.e. directories not writable
by everyone which I would say should not be too difficult).
If you run `mvn assembly:assembly` as is, you will have:
drwxrwxrwx ... assembly-test-1.0.0/
drwxrwxrwx ... assembly-test-1.0.0/bin/
-rw-r--r-- ... assembly-test-1.0.0/bin/assembly-test-1.0.0.jar
-rw-r--r-- ... assembly-test-1.0.0/bin/commons-lang-2.4.jar
drwxr-xr-x ... assembly-test-1.0.0/copyofsubdir/
-rw-r--r-- ... assembly-test-1.0.0/copyofsubdir/file
I found no way to set the first two directories permissions. If you add the
two directoryMode tags, you will have:
drwxrwxrwx ... assembly-test-1.0.0/
drwxrwxrwx ... assembly-test-1.0.0/bin/
-rw-r--r-- ... assembly-test-1.0.0/bin/assembly-test-1.0.0.jar
-rw-r--r-- ... assembly-test-1.0.0/bin/commons-lang-2.4.jar
drwxr-xr-x ... assembly-test-1.0.0/copyofsubdir/
-rwxrwxrwx ... assembly-test-1.0.0/copyofsubdir/file*
... which is pretty much what I did NOT expect (a cut'n paste issue in the
code?). If you add both directoryMode and fileMode, you will have the same
results as the first iteration (see above).
Unfortunately I still cannot change the permissions of:
- the base directory (assembly-test-1.0.0)
- any directory that is not present on the file system (bin)
I looked a bit at the code and, as far as I can see, it may be linked to the
plexus zip archiver (although it may not be responsible for the bug) which
automatically adds parent directories but most probably with incorrect
permissions due to bad configuration.
I did not test with other assembly formats.
PS: yes I can do a simple tarball, and I will probably do that while waiting
for a patch. But I think it is important that you are aware of something
which may annoy more than one single user in the world.
Regards.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-494) No way to set the directory mode for the base directory nor any implicitly created directory for zip assemblies
[ https://jira.codehaus.org/browse/MASSEMBLY-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-494. Resolution: Not A Bug Assignee: John Casey No way to set the directory mode for the base directory nor any implicitly created directory for zip assemblies --- Key: MASSEMBLY-494 URL: https://jira.codehaus.org/browse/MASSEMBLY-494 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-5 Environment: Debian GNU/Linux Reporter: Arnaud de Bossoreille Assignee: John Casey Attachments: assembly-test.zip A sample maven project is attached to reproduce everything. I am trying to generate a zip file with correct permissions (i.e. directories not writable by everyone which I would say should not be too difficult). If you run `mvn assembly:assembly` as is, you will have: drwxrwxrwx ... assembly-test-1.0.0/ drwxrwxrwx ... assembly-test-1.0.0/bin/ -rw-r--r-- ... assembly-test-1.0.0/bin/assembly-test-1.0.0.jar -rw-r--r-- ... assembly-test-1.0.0/bin/commons-lang-2.4.jar drwxr-xr-x ... assembly-test-1.0.0/copyofsubdir/ -rw-r--r-- ... assembly-test-1.0.0/copyofsubdir/file I found no way to set the first two directories permissions. If you add the two directoryMode tags, you will have: drwxrwxrwx ... assembly-test-1.0.0/ drwxrwxrwx ... assembly-test-1.0.0/bin/ -rw-r--r-- ... assembly-test-1.0.0/bin/assembly-test-1.0.0.jar -rw-r--r-- ... assembly-test-1.0.0/bin/commons-lang-2.4.jar drwxr-xr-x ... assembly-test-1.0.0/copyofsubdir/ -rwxrwxrwx ... assembly-test-1.0.0/copyofsubdir/file* ... which is pretty much what I did NOT expect (a cut'n paste issue in the code?). If you add both directoryMode and fileMode, you will have the same results as the first iteration (see above). Unfortunately I still cannot change the permissions of: - the base directory (assembly-test-1.0.0) - any directory that is not present on the file system (bin) I looked a bit at the code and, as far as I can see, it may be linked to the plexus zip archiver (although it may not be responsible for the bug) which automatically adds parent directories but most probably with incorrect permissions due to bad configuration. I did not test with other assembly formats. PS: yes I can do a simple tarball, and I will probably do that while waiting for a patch. But I think it is important that you are aware of something which may annoy more than one single user in the world. Regards. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-564) [PATCH] Migration from obsolete plexus-maven-plugin to plexus-containers-component-metadata
[PATCH] Migration from obsolete plexus-maven-plugin to plexus-containers-component-metadata --- Key: MASSEMBLY-564 URL: https://jira.codehaus.org/browse/MASSEMBLY-564 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Affects Versions: 2.2.1 Environment: Fedora Rawhide Reporter: Jaromír Cápík Attachments: maven-assembly-plugin-migration-to-component-metadata.patch The attached patch retires the obsolete plexus-maven-plugin and generates the metadata with plexus-containers-component-metadata instead. NOTE : The result XML file has a different order of elements, but all of them are present. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-695) tagNameFormat with @{project.version} tags the SNAPSHOT version
tagNameFormat with @{project.version} tags the SNAPSHOT version
---
Key: MRELEASE-695
URL: https://jira.codehaus.org/browse/MRELEASE-695
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Fabrizio Giudici
The much awaited (by me) MRELEASE-159 seems not to work. I tried a release with
the following pom:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
configuration
localCheckouttrue/localCheckout
preparationGoalsclean install verify/preparationGoals
goalsclean install javadoc:javadoc assembly:assembly
deploy/goals
arguments-P${release.profiles}
-DaltDeploymentRepository=${altDeploymentRepository}/arguments
tagNameFormat@{project.version}/tagNameFormat
/configuration
/plugin
but I got the tag 1.0-ALPHA-2-SNAPSHOT in place of 1.0-ALPHA-2.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MJAVADOC-250) javadoc:fix mojo should fully qualify {@link} class names
[
https://jira.codehaus.org/browse/MJAVADOC-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on MJAVADOC-250 started by Robert Scholte.
javadoc:fix mojo should fully qualify {@link} class names
-
Key: MJAVADOC-250
URL: https://jira.codehaus.org/browse/MJAVADOC-250
Project: Maven 2.x Javadoc Plugin
Issue Type: New Feature
Affects Versions: 2.6
Reporter: jieryn
Assignee: Robert Scholte
Priority: Minor
When the javadoc:fix goal is executed, it rightly adds fully qualified class
names for each {@link} tag. It would be great if the mojo would fix existing
{@link} tags to be fully qualified, also. Thanks!
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5096) exclusion on dependency with typetest-jar/type doesn't work in maven 3
[
https://jira.codehaus.org/browse/MNG-5096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=273273#comment-273273
]
Martin Grotzke commented on MNG-5096:
-
I'm also running into the same issue. Is there any progress on this?
exclusion on dependency with typetest-jar/type doesn't work in maven 3
--
Key: MNG-5096
URL: https://jira.codehaus.org/browse/MNG-5096
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.0.3
Environment: Ubuntu 10.04
Reporter: Garrett Wu
Attachments: maven-testcase.tar.gz
There appears to be a regression in maven 3 that breaks test-jar dependency
exclusions. I've attached a simple example to reproduce this. There are two
projects: foo and bar. Project foo produces a test-jar artifact. Project
bar depends on foo's test-jar but excludes a dependency on junit. In maven
2, a dependency:list shows that junit has successfully been excluded. In
maven 3, a dependency:list shows that junit was not successfully excluded.
To reproduce, download the {{maven-testcase.tar.gz}} attachment and run:
{code:none}
$ tar xzvf maven-testcase.tar.gz
$ cd maven-testcase/foo
$ mvn2 install
$ cd ../bar
$ mvn2 dependency:list
...
[INFO] The following files have been resolved:
[INFO]org.apache.maven:foo:test-jar:tests:1.0:test
...
$ mvn3 dependency:list
...
[INFO] The following files have been resolved:
[INFO]junit:junit:jar:4.8.1:test
[INFO]org.apache.maven:foo:test-jar:tests:1.0:test
...
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-5096) exclusion on dependency with typetest-jar/type doesn't work in maven 3
[
https://jira.codehaus.org/browse/MNG-5096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=273273#comment-273273
]
Martin Grotzke edited comment on MNG-5096 at 7/14/11 5:48 PM:
--
I'm also running into the same issue. But to me it seems that dependency:list
and the actual test classpath are different for previous maven versions (e.g.
2.1.0): test test classpath still contains the unwanted dependencies even if
dependency:list doesn't show them.
Is there any progress on this btw?
was (Author: martin.grotzke):
I'm also running into the same issue. Is there any progress on this?
exclusion on dependency with typetest-jar/type doesn't work in maven 3
--
Key: MNG-5096
URL: https://jira.codehaus.org/browse/MNG-5096
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.0.3
Environment: Ubuntu 10.04
Reporter: Garrett Wu
Attachments: maven-testcase.tar.gz
There appears to be a regression in maven 3 that breaks test-jar dependency
exclusions. I've attached a simple example to reproduce this. There are two
projects: foo and bar. Project foo produces a test-jar artifact. Project
bar depends on foo's test-jar but excludes a dependency on junit. In maven
2, a dependency:list shows that junit has successfully been excluded. In
maven 3, a dependency:list shows that junit was not successfully excluded.
To reproduce, download the {{maven-testcase.tar.gz}} attachment and run:
{code:none}
$ tar xzvf maven-testcase.tar.gz
$ cd maven-testcase/foo
$ mvn2 install
$ cd ../bar
$ mvn2 dependency:list
...
[INFO] The following files have been resolved:
[INFO]org.apache.maven:foo:test-jar:tests:1.0:test
...
$ mvn3 dependency:list
...
[INFO] The following files have been resolved:
[INFO]junit:junit:jar:4.8.1:test
[INFO]org.apache.maven:foo:test-jar:tests:1.0:test
...
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5096) exclusion on dependency with typetest-jar/type doesn't work in maven 3
[
https://jira.codehaus.org/browse/MNG-5096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=273275#comment-273275
]
Martin Grotzke commented on MNG-5096:
-
I just found out that with maven 3 (tested with 3.0.2) changing
{{typetest-jar/type}} to {{classifiertests/classifier}} solves this
issue. With maven 2 (tested with 2.2.1) the situation is still the same.
exclusion on dependency with typetest-jar/type doesn't work in maven 3
--
Key: MNG-5096
URL: https://jira.codehaus.org/browse/MNG-5096
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.0.3
Environment: Ubuntu 10.04
Reporter: Garrett Wu
Attachments: maven-testcase.tar.gz
There appears to be a regression in maven 3 that breaks test-jar dependency
exclusions. I've attached a simple example to reproduce this. There are two
projects: foo and bar. Project foo produces a test-jar artifact. Project
bar depends on foo's test-jar but excludes a dependency on junit. In maven
2, a dependency:list shows that junit has successfully been excluded. In
maven 3, a dependency:list shows that junit was not successfully excluded.
To reproduce, download the {{maven-testcase.tar.gz}} attachment and run:
{code:none}
$ tar xzvf maven-testcase.tar.gz
$ cd maven-testcase/foo
$ mvn2 install
$ cd ../bar
$ mvn2 dependency:list
...
[INFO] The following files have been resolved:
[INFO]org.apache.maven:foo:test-jar:tests:1.0:test
...
$ mvn3 dependency:list
...
[INFO] The following files have been resolved:
[INFO]junit:junit:jar:4.8.1:test
[INFO]org.apache.maven:foo:test-jar:tests:1.0:test
...
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-318) Dependency plugin: copy-dependencies -DfailOnMissingClassifierArtifact=false does not work.
Dependency plugin: copy-dependencies -DfailOnMissingClassifierArtifact=false
does not work.
---
Key: MDEP-318
URL: https://jira.codehaus.org/browse/MDEP-318
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: copy-dependencies
Affects Versions: 2.2
Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_24
Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux version: 2.6.35-30-generic arch: amd64 Family: unix
Reporter: Ondrej Zizka
Assignee: Brian Fox
STR:
1) Have a project with some artifact which does not have sources jar.
2) Run `mvn dependency:copy-dependencies -Dclassifier=sources
-DfailOnMissingClassifierArtifact=false`
3) Task will fail on that artifact.
Reference:
http://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html
{code}
plugin
artifactIdmaven-dependency-plugin/artifactId
version2.2/version
/plugin
{code}
{code}
$ mvn dependency:copy-dependencies -Dclassifier=sources
-DfailOnMissingClassifierArtifact=false
[INFO] Scanning for projects...
Downloading:
https://repository.jboss.org/nexus/content/groups/public//org/apache/maven/plugins/maven-dependency-plugin/2.2/maven-dependency-plugin-2.2.pom
[INFO] Unable to find resource
'org.apache.maven.plugins:maven-dependency-plugin:pom:2.2' in repository
jboss-plugins (https://repository.jboss.org/nexus/content/groups/public/)
Downloading:
http://uk.maven.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/2.2/maven-dependency-plugin-2.2.pom
Downloading:
https://repository.jboss.org/nexus/content/groups/public//org/apache/maven/plugins/maven-dependency-plugin/2.2/maven-dependency-plugin-2.2.jar
[INFO] Unable to find resource
'org.apache.maven.plugins:maven-dependency-plugin:maven-plugin:2.2' in
repository jboss-plugins
(https://repository.jboss.org/nexus/content/groups/public/)
Downloading:
http://uk.maven.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/2.2/maven-dependency-plugin-2.2.jar
...
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] not found in any repository: asm:asm:java-source:sources:3.1
Embedded error: Unable to download the artifact from any repository
...
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-106) Unpacking primary artifact from sibling module uses repository rather than reactor
[
https://jira.codehaus.org/browse/MDEP-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=273301#comment-273301
]
Matt Ryall commented on MDEP-106:
-
Thanks for the update, Stephen.
Unpacking primary artifact from sibling module uses repository rather than
reactor
--
Key: MDEP-106
URL: https://jira.codehaus.org/browse/MDEP-106
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: unpack
Affects Versions: 2.0-alpha-4
Reporter: Matt Ryall
Assignee: Brian Fox
Fix For: 2.3
Running dependency:unpack referencing a project in the reactor has the
following output which shows it is scanning for repository artifacts rather
than the artifact in the reactor:
{quote}
[INFO] [dependency:unpack \{execution: unpack-tests}]
[INFO] Configured Artifact:
com.example.app:app-acceptance-test:2.6-SNAPSHOT:jar
[INFO] snapshot com.example.app:app-acceptance-test:2.6-SNAPSHOT: checking
for updates from snapshots
[INFO] snapshot com.example.app:app-acceptance-test:2.6-SNAPSHOT: checking
for updates from m1-repo
Downloading:
http://m2proxy:8081/artifactory/repo/com/example/app/app-acceptance-test/2.6-SNAPSHOT/app-acceptance-test-2.6-20070829.025709-409.jar
9125K downloaded
[INFO] Expanding:
/Users/mryall/.m2/repository/com/example/app/app-acceptance-test/2.6-SNAPSHOT/app-acceptance-test-2.6-SNAPSHOT.jar
into /Users/mryall/src/example/app/app-webapp/target/it-classes
{quote}
To explain the scenario: to build reusable acceptance tests, I have the
following sub-modules of my project:
- app-core (jar)
- app-acceptance-tests (jar)
- app-webapp (war)
The acceptance tests are packaged this way for further use in testing, and
also run against the webapp in the integration-test phase. This is where the
problem arises.
Running 'mvn clean integration-test' does the following relevant tasks:
- in the app-acceptance-test module, compiles and packages a JAR of tests
- in the app-webapp module, uses the dependency:unpack goal to extract the
tests into target/it-classes in the pre-integration-test phase, and test:test
to run them in the integration test phase.
I don't think this is caused by the snapshot version, because the release
plugin also fails because it is unable to find the 2.6 version when it runs
'mvn clean verify'. There, it scans all the repositories for the acceptance
test artifact before failing with the usual error:
{quote}
[INFO] Failed to resolve artifact.
GroupId: com.example.app
ArtifactId: app-acceptance-test
Version: 2.6
Reason: Unable to download the artifact from any repository
{quote}
Maven details:
{noformat}
$ mvn -version
Maven version: 2.0.7
Java version: 1.4.2_12
OS name: mac os x version: 10.4.10 arch: i386
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4112) Set property containing the currently executing maven version.
[ https://jira.codehaus.org/browse/MNG-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=273304#comment-273304 ] Paul Gier commented on MNG-4112: I'm not sure whether to use just the version number or the full version string for this. For example, 3.0.3 vs Apache Maven 3.0.3 (r1075438; 2011-02-28 11:31:09-0600). I'm leaning toward the full version info since this is similar to the version string available in the Ant property ant.version. Set property containing the currently executing maven version. -- Key: MNG-4112 URL: https://jira.codehaus.org/browse/MNG-4112 Project: Maven 2 3 Issue Type: Improvement Reporter: Paul Gier Assignee: Paul Gier Fix For: 3.1 Attachments: MNG-4112-maven-embedder.patch It would be helpful to have an easy way to access the current version of maven. This might be accomplished by setting a property like maven.version during startup that would be available to the pom and/or to plugins. This could be used to record what version of maven was used during the build to facilitate build reproducibility. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
