[jira] Created: (MNG-4877) Regression: Deploy to SCP with privateKey fails - privateKey and passphrase gets lost
Regression: Deploy to SCP with privateKey fails - privateKey and passphrase gets lost - Key: MNG-4877 URL: http://jira.codehaus.org/browse/MNG-4877 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.0 Reporter: Bernhard Mähr Hello! Using the maven-deploy-plugin version 2.5 to deploy to a server with scp and private key fails after the upgrade to maven 3. The configuration is stored in setting.xml idmymavenrepo/id usernamemyuser/username privateKeyC:/Dokumente und Einstellungen/bmaehr/.ssh/myprivatekey.id/privateKey passphrasemypassword/passphrase The configuration is correctly loaded by maven and available at org.apache.maven.repository.legacy.LegacyRepositorySystem.getAuthentication(RepositorySystemSession, ArtifactRepository). But at this place the conversation to org.apache.maven.artifact.repository.Authentication happens and only username and password is forwarded and privateKey and passphrase gets lost. At org.apache.maven.RepositoryUtils.toRepo(ArtifactRepository) the information is converted back to org.sonatype.aether.repository.Authentication but the privateKey and passphrase are not recovered. -- 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: (MGPG-32) Deploying snapshot sources with gpg:sign-and-deploy-file - Is it possible ? It increments build number
[ http://jira.codehaus.org/browse/MGPG-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] vychtrle closed MGPG-32. Resolution: Not A Bug It was more of a feature request Deploying snapshot sources with gpg:sign-and-deploy-file - Is it possible ? It increments build number -- Key: MGPG-32 URL: http://jira.codehaus.org/browse/MGPG-32 Project: Maven 2.x GPG Plugin Issue Type: Improvement Affects Versions: 1.1 Environment: Apache Maven 3.0 (r1004208) and maven 2.2.1, linux, nexus repository Reporter: vychtrle I'm deploying snapshot ant its sources with gpg:sign-and-deploy-file, but the sources name does always have the value of the following buildnumber. Like artifact-timestamp-1.jar and artifact-timestamp-2-sources.jar so that if I then have a snapshot dependency, it is looking for artifact-timestamp-2.jar instead of artifact-timestamp-1.jar I'm not using any build number plugin etc., the pom definitions for this artifact is having only credentials. I also don't use SCM... here is what I do http://pastebin.com/b2F5Ju1s -- 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-4850) [regression] server configuration in settings.xml are not honoured
[ http://jira.codehaus.org/browse/MNG-4850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-4850: -- Summary: [regression] server configuration in settings.xml are not honoured (was: [regression] filePermissions and directoryPermissions in settings.xml are not honoured) [regression] server configuration in settings.xml are not honoured -- Key: MNG-4850 URL: http://jira.codehaus.org/browse/MNG-4850 Project: Maven 2 3 Issue Type: Bug Components: Settings Affects Versions: 3.0-beta-3 Reporter: Brett Porter Priority: Minor Fix For: 3.0.1 The IT MavenITmng3600DeploymentModeDefaultsTest.testitMNG3600ModesSet is currently failing for all versions of Maven 3. Correspondingly, when using Maven 3 with an SSH wagon listed as an extension, it deploys successfully but ignores the above settings, using default file and directory modes. -- 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-4877) Regression: Deploy to SCP with privateKey fails - privateKey and passphrase gets lost
[ http://jira.codehaus.org/browse/MNG-4877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-4877. - Resolution: Duplicate Regression: Deploy to SCP with privateKey fails - privateKey and passphrase gets lost - Key: MNG-4877 URL: http://jira.codehaus.org/browse/MNG-4877 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.0 Reporter: Bernhard Mähr Hello! Using the maven-deploy-plugin version 2.5 to deploy to a server with scp and private key fails after the upgrade to maven 3. The configuration is stored in setting.xml idmymavenrepo/id usernamemyuser/username privateKeyC:/Dokumente und Einstellungen/bmaehr/.ssh/myprivatekey.id/privateKey passphrasemypassword/passphrase The configuration is correctly loaded by maven and available at org.apache.maven.repository.legacy.LegacyRepositorySystem.getAuthentication(RepositorySystemSession, ArtifactRepository). But at this place the conversation to org.apache.maven.artifact.repository.Authentication happens and only username and password is forwarded and privateKey and passphrase gets lost. At org.apache.maven.RepositoryUtils.toRepo(ArtifactRepository) the information is converted back to org.sonatype.aether.repository.Authentication but the privateKey and passphrase are not recovered. -- 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-4850) [regression] several elements of server configuration in settings.xml are not honoured
[ http://jira.codehaus.org/browse/MNG-4850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-4850: -- Summary: [regression] several elements of server configuration in settings.xml are not honoured (was: [regression] server configuration in settings.xml are not honoured) [regression] several elements of server configuration in settings.xml are not honoured -- Key: MNG-4850 URL: http://jira.codehaus.org/browse/MNG-4850 Project: Maven 2 3 Issue Type: Bug Components: Settings Affects Versions: 3.0-beta-3 Reporter: Brett Porter Priority: Minor Fix For: 3.0.1 The IT MavenITmng3600DeploymentModeDefaultsTest.testitMNG3600ModesSet is currently failing for all versions of Maven 3. Correspondingly, when using Maven 3 with an SSH wagon listed as an extension, it deploys successfully but ignores the above settings, using default file and directory modes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2576) lzma-java 1.0 upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=240880#action_240880 ] Lauri Hahne commented on MAVENUPLOAD-2576: -- The upstream source tree does have a valid groupid now though the bundle hasn't been updated yet. lzma-java 1.0 upload request Key: MAVENUPLOAD-2576 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2576 Project: Maven Upload Requests Issue Type: Wish Reporter: Julien Ponge Assignee: Carlos Sanchez http://cloud.github.com/downloads/jponge/lzma-java/lzma-java-1.0-bundle.jar http://github.com/jponge/lzma-java/tree I guys, I developed this small LZMA compression library around the Java LZMA SDK. Thanks for considering uploading 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] Created: (MECLIPSE-672) Add Support for Adding classpathentrys to .classpath
Add Support for Adding classpathentrys to .classpath
Key: MECLIPSE-672
URL: http://jira.codehaus.org/browse/MECLIPSE-672
Project: Maven 2.x Eclipse Plugin
Issue Type: Improvement
Components: Core : Dependencies resolution and build path (.classpath)
Affects Versions: 2.8
Reporter: Bob Tiernay
One of the main issues with trying to configure a groovy / maven project within
eclipse is that one must manually configure the classpath each time a project
is materialized from SCM or created anew.
It would be extremely helpful if one could specify {{classpathentry}}s to be
generated in {{.classpath}} so that when {{eclipse:eclipse}} or
{{eclipse:m2eclipse}} is performed the following is produced:
{code:xml}
classpathentry kind=src output=target/classes path=src/main/java
including=**/*.java/
classpathentry kind=src output=target/classes path=src/main/groovy
including=**/*.groovy/
classpathentry kind=src output=target/test-classes path=src/test/java
including=**/*.java/
classpathentry kind=src output=target/test-classes path=src/test/groovy
including=**/*.groovy/
{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] Commented: (MCOMPILER-139) test-compile doesn't honor @SuppressWarnings(deprecation) as compile does
[
http://jira.codehaus.org/browse/MCOMPILER-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=240882#action_240882
]
Dominique Jean-Prost commented on MCOMPILER-139:
Well Benjamin, I think there may be indeed a problem in maven compiler, as the
behaviour is different between mvn compile and mvn test-compile.
I saw there are some opened bugs at oracle concerning
@suppresswarnings(deprecation), but as the behaviour is not the same between
mvn compile and mvn test-compile, I think a problem might exists in the plugin.
Can you check please ?
test-compile doesn't honor @SuppressWarnings(deprecation) as compile does
---
Key: MCOMPILER-139
URL: http://jira.codehaus.org/browse/MCOMPILER-139
Project: Maven 2.x Compiler Plugin
Issue Type: Bug
Affects Versions: 2.1, 2.3.2
Reporter: Dominique Jean-Prost
Assignee: Benjamin Bentmann
Attachments: execution.log, test.zip
/test/src/main/java/test/DeprecatedObject.java :
[co...@deprecated
public class DeprecatedObject {
public DeprecatedObject() {
}
}[/code]
/test/src/main/java/test/DeprecatedMain.java :
[co...@suppresswarnings(deprecation)
public class DeprecatedMain {
@SuppressWarnings(unused)
private final Date d = new Date(20/10/2006);
public DeprecatedObject test() {
return null;
}
}[/code]
/test/src/test/java/test/DeprecatedTest.java :
[co...@suppresswarnings(deprecation)
public class DeprecatedTest {
@SuppressWarnings(unused)
private final Date d = new Date(2010/2010);
public void test(final DeprecatedObject obj) {
}
}[/code]
mvn clean test-compile :
[INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ test ---
[INFO] Deleting C:\workspace\test\target
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ test
---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ test ---
[WARNING] File encoding has not been set, using platform encoding Cp1252,
i.e. build is platform dependent!
[INFO] Compiling 2 source files to C:\workspace\test\target\classes
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources)
@ test ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @
test ---
[WARNING] File encoding has not been set, using platform encoding Cp1252,
i.e. build is platform dependent!
[INFO] Compiling 1 source file to C:\workspace\test\target\test-classes
[WARNING] \workspace\test\src\test\java\test\DeprecatedTest.java:[13,27]
[deprecation] test.DeprecatedObject in test has been deprecated
[INFO]
[INFO] BUILD SUCCESS
[INFO]
-- Although both DeprecatedMain and DeprecatedTest use DeprecatedObject and
both have @SuppressWarnings(deprecation) at class level, the compile output
shows a warning. The warning occurs only in test-compile.
Please note that if both stops using DeprecatedObject (remove te two test
method from objects), then copiler output doesn't mention deprecated.
--
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: (MCOMPILER-139) test-compile doesn't honor @SuppressWarnings(deprecation) as compile does
[
http://jira.codehaus.org/browse/MCOMPILER-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=240883#action_240883
]
Benjamin Bentmann commented on MCOMPILER-139:
-
The difference between {{compile}} and {{test-compile}} is that those goals
process different sources, different input - different output. Just enable
debug logging, grab the cmd line used to invoke {{javac}} and invoke it
directly, it produces your warning, without any help from Maven.
test-compile doesn't honor @SuppressWarnings(deprecation) as compile does
---
Key: MCOMPILER-139
URL: http://jira.codehaus.org/browse/MCOMPILER-139
Project: Maven 2.x Compiler Plugin
Issue Type: Bug
Affects Versions: 2.1, 2.3.2
Reporter: Dominique Jean-Prost
Assignee: Benjamin Bentmann
Attachments: execution.log, test.zip
/test/src/main/java/test/DeprecatedObject.java :
[co...@deprecated
public class DeprecatedObject {
public DeprecatedObject() {
}
}[/code]
/test/src/main/java/test/DeprecatedMain.java :
[co...@suppresswarnings(deprecation)
public class DeprecatedMain {
@SuppressWarnings(unused)
private final Date d = new Date(20/10/2006);
public DeprecatedObject test() {
return null;
}
}[/code]
/test/src/test/java/test/DeprecatedTest.java :
[co...@suppresswarnings(deprecation)
public class DeprecatedTest {
@SuppressWarnings(unused)
private final Date d = new Date(2010/2010);
public void test(final DeprecatedObject obj) {
}
}[/code]
mvn clean test-compile :
[INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ test ---
[INFO] Deleting C:\workspace\test\target
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ test
---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ test ---
[WARNING] File encoding has not been set, using platform encoding Cp1252,
i.e. build is platform dependent!
[INFO] Compiling 2 source files to C:\workspace\test\target\classes
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources)
@ test ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @
test ---
[WARNING] File encoding has not been set, using platform encoding Cp1252,
i.e. build is platform dependent!
[INFO] Compiling 1 source file to C:\workspace\test\target\test-classes
[WARNING] \workspace\test\src\test\java\test\DeprecatedTest.java:[13,27]
[deprecation] test.DeprecatedObject in test has been deprecated
[INFO]
[INFO] BUILD SUCCESS
[INFO]
-- Although both DeprecatedMain and DeprecatedTest use DeprecatedObject and
both have @SuppressWarnings(deprecation) at class level, the compile output
shows a warning. The warning occurs only in test-compile.
Please note that if both stops using DeprecatedObject (remove te two test
method from objects), then copiler output doesn't mention deprecated.
--
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: (MCOMPILER-139) test-compile doesn't honor @SuppressWarnings(deprecation) as compile does
[
http://jira.codehaus.org/browse/MCOMPILER-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=240884#action_240884
]
Dominique Jean-Prost commented on MCOMPILER-139:
Well, you're right indeed.
Thank you for helping
test-compile doesn't honor @SuppressWarnings(deprecation) as compile does
---
Key: MCOMPILER-139
URL: http://jira.codehaus.org/browse/MCOMPILER-139
Project: Maven 2.x Compiler Plugin
Issue Type: Bug
Affects Versions: 2.1, 2.3.2
Reporter: Dominique Jean-Prost
Assignee: Benjamin Bentmann
Attachments: execution.log, test.zip
/test/src/main/java/test/DeprecatedObject.java :
[co...@deprecated
public class DeprecatedObject {
public DeprecatedObject() {
}
}[/code]
/test/src/main/java/test/DeprecatedMain.java :
[co...@suppresswarnings(deprecation)
public class DeprecatedMain {
@SuppressWarnings(unused)
private final Date d = new Date(20/10/2006);
public DeprecatedObject test() {
return null;
}
}[/code]
/test/src/test/java/test/DeprecatedTest.java :
[co...@suppresswarnings(deprecation)
public class DeprecatedTest {
@SuppressWarnings(unused)
private final Date d = new Date(2010/2010);
public void test(final DeprecatedObject obj) {
}
}[/code]
mvn clean test-compile :
[INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ test ---
[INFO] Deleting C:\workspace\test\target
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ test
---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ test ---
[WARNING] File encoding has not been set, using platform encoding Cp1252,
i.e. build is platform dependent!
[INFO] Compiling 2 source files to C:\workspace\test\target\classes
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources)
@ test ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @
test ---
[WARNING] File encoding has not been set, using platform encoding Cp1252,
i.e. build is platform dependent!
[INFO] Compiling 1 source file to C:\workspace\test\target\test-classes
[WARNING] \workspace\test\src\test\java\test\DeprecatedTest.java:[13,27]
[deprecation] test.DeprecatedObject in test has been deprecated
[INFO]
[INFO] BUILD SUCCESS
[INFO]
-- Although both DeprecatedMain and DeprecatedTest use DeprecatedObject and
both have @SuppressWarnings(deprecation) at class level, the compile output
shows a warning. The warning occurs only in test-compile.
Please note that if both stops using DeprecatedObject (remove te two test
method from objects), then copiler output doesn't mention deprecated.
--
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: (MECLIPSE-673) EAR projects with defaultLibBundleDir set to APP-INF/lib generate wrong .components descriptor for eclipse
EAR projects with defaultLibBundleDir set to APP-INF/lib generate wrong
.components descriptor for eclipse
Key: MECLIPSE-673
URL: http://jira.codehaus.org/browse/MECLIPSE-673
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: WTP support
Affects Versions: 2.8
Environment: Eclipse 3.5 SR2
WTP 3.1.1 (bundled with Elipse 3.5 SR2)
Reporter: Luca De Petrillo
The eclipse plugin doesn't handle correctly the property defaultLibBundleDir
for ear projects when it's set to a multiple sub-directory path (it work well
if it's set to lib, but not if it's set to APP-INF/lib).
Looking at the generated .components file for the ear project, dependencies are
declared in this manner:
{code:xml}
dependent-module archiveName=../antlr-2.7.6.jar deploy-path=APP-INF/lib
handle=module:/classpath/var/M2_REPO/antlr/antlr/2.7.6/antlr-2.7.6.jar
dependency-typeuses/dependency-type
/dependent-module
{code}
This make eclipse to copy the library in ear-root/APP-INF/lib/APP-INF due
the well know bug in WTP.
I've tried to edit the .components adding another ../ in the archiveName like
this:
{code:xml}
dependent-module archiveName=../../antlr-2.7.6.jar deploy-path=APP-INF/lib
handle=module:/classpath/var/M2_REPO/antlr/antlr/2.7.6/antlr-2.7.6.jar
dependency-typeuses/dependency-type
/dependent-module
{code}
and the library has been placed correctly in ear-root/APP-INF/lib.
I've also tried to fully remove the archiveName property as i read somewhere (i
don't remember where i read it) like this:
{code:xml}
dependent-module deploy-path=APP-INF/lib
handle=module:/classpath/var/M2_REPO/antlr/antlr/2.7.6/antlr-2.7.6.jar
dependency-typeuses/dependency-type
/dependent-module
{code}
and also with this declaration, the library has been placed correctly.
So, i think that a fix for this could be to add a ../ for each directory
specified in defaultLibBundleDir, or simply remove the archiveName property
from the descriptor (i don't know if removing the archiveName property works on
all WTP version... but for me it works well with WTP 3.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-4694) extractor for language: ant fails to detect Ant mojos
[ http://jira.codehaus.org/browse/MNG-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=240909#action_240909 ] Chris Wash commented on MNG-4694: - The above workaround worked for me as well. extractor for language: ant fails to detect Ant mojos - Key: MNG-4694 URL: http://jira.codehaus.org/browse/MNG-4694 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.0-beta-1 Environment: Any Reporter: Kaizer Sogiawala Fix For: 3.0-beta-1 Using simple project to develop Ant plugins described at- http://maven.apache.org/guides/plugin/guide-ant-plugin-development.html I noticed the maven-plugin-plugin/Extractor is not able to detect any Ant mojos. This same example works fine in mvn-2.2.1 --- SNIP --- [INFO] --- maven-plugin-plugin:2.3:descriptor (default-descriptor) @ maven-javac-plugin --- [WARNING] Goal prefix is: javac; Maven currently expects it to be javac [INFO] Using 3 extractors. [INFO] Applying extractor for language: java [INFO] Extractor for language: java found 0 mojo descriptors. [INFO] Applying extractor for language: ant [INFO] Extractor for language: ant found 0 mojo descriptors. [INFO] Applying extractor for language: bsh [INFO] Extractor for language: bsh found 0 mojo descriptors. --- SNIP --- $ mvn -v Apache Maven 3.0-beta-1 (r935667; 2010-04-19 10:00:39-0700) Java version: 1.6.0_20 Java home: /opt/jdk1.6.0_20/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.32-21-generic-pae 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] Created: (MNG-4878) Inheritance of URLs behaves differently for aggregated and non-aggregated child projects
Inheritance of URLs behaves differently for aggregated and non-aggregated child
projects
Key: MNG-4878
URL: http://jira.codehaus.org/browse/MNG-4878
Project: Maven 2 3
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 3.0
Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
Java version: 1.6.0_20
Reporter: Andreas Sewe
Attachments: testcase-project.tar.gz
AFAIK, inheritance and aggregation are orthogonal in Maven. Whether a child
project is a module of its parent, however, affects how URLs are inherited.
(This bug affects {{/project/url}},
{{/project/distributionManagement/site/url}}, {{/project/scm/connection}},
{{/project/scm/developerConnection}}, and {{/project/scm/url}}.)
This is exemplified by the attached projects, which serve as a testcase. The
aggregated child project does respect the trailing slash of its parent's URLs
and thus does not append its own {{artifactId}} to the URLs. The non-aggregated
child, however, does _not_ respect the trailing slash; consequently, its
{{artifactId}} is added erroneously: A {{/project/url}} of
http://www.example.org/projects/${project.artifactId}/ is turned into
http://www.example.org/projects/non-aggregated-child/non-aggregated-child/ in
the *non-aggregated* child project, whereas it becomes
http://www.example.org/projects/aggregated-child/ in the *aggregated* child
project. (Note that both projects are children of the same parent project.)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-516) Error in Example for sharing-descriptors?
[ http://jira.codehaus.org/browse/MASSEMBLY-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=240915#action_240915 ] Eric Haszlakiewicz commented on MASSEMBLY-516: -- It's a bit crazy that a change like this went in between a beta release and a final release, and it looks like this isn't the only major change that happened (see the messages on the mailing list about classifier being required). Doing things like this makes any distinction between major/minor/beta/whatever releases kind of pointless. :( Error in Example for sharing-descriptors? - Key: MASSEMBLY-516 URL: http://jira.codehaus.org/browse/MASSEMBLY-516 Project: Maven 2.x Assembly Plugin Issue Type: Bug Environment: - Reporter: Knut Pape On Page http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html It says that the assembly file from a jar on the class-path shoulld be included the following way: descriptors descriptormyassembly.xml/descriptor /descriptors This didn't work for me. After some fidling (I'm pritty sure that the problem was not a spelling mistake) I came to the following solution: Instead of referencing the assembly by filename I referenced it by it's ID and voila - it worked: descriptorRefs descriptorRefmy-assembly-descriptor-id/descriptorRef /descriptorRefs -- 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-517) Assembly fails with empty id element now
Assembly fails with empty id element now
Key: MASSEMBLY-517
URL: http://jira.codehaus.org/browse/MASSEMBLY-517
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Eric Haszlakiewicz
Priority: Critical
There is a serious regression in behaviour between version 2.2-beta-5 and 2.2.
With version 2.2, assembly descriptors that have an empty id element no longer
work. i.e.:
assembly
id/id
formatsformattar.gz/format/formats
/assembly
The error message is:
[INFO] [assembly:single {execution: assemble-tar-gzip}]
[INFO] Reading assembly descriptor: src/main/assembly/assembly.xml
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] : org.apache.maven.plugin.assembly.model.assem...@15fddb33
Assembly is incorrectly configured:
Assembly: is not configured correctly: Assembly ID must be present and
non-empty.
--
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-517) Assembly fails with empty id element now
[
http://jira.codehaus.org/browse/MASSEMBLY-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=240972#action_240972
]
Brian Fox commented on MASSEMBLY-517:
-
From my POV this was a good change. Each pom can produce one artifact with a
null classifier and that type should be described by the packaging type.
Having an artifact like a zip deployed with a null classifier from a
packagingpom/packaging pom causes tons of problems with other tools trying
to understand the artifact. The fact is packaging pom means it is a pom and
that's it.
Assembly fails with empty id element now
Key: MASSEMBLY-517
URL: http://jira.codehaus.org/browse/MASSEMBLY-517
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Eric Haszlakiewicz
Priority: Critical
There is a serious regression in behaviour between version 2.2-beta-5 and
2.2. With version 2.2, assembly descriptors that have an empty id element no
longer work. i.e.:
assembly
id/id
formatsformattar.gz/format/formats
/assembly
The error message is:
[INFO] [assembly:single {execution: assemble-tar-gzip}]
[INFO] Reading assembly descriptor: src/main/assembly/assembly.xml
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] : org.apache.maven.plugin.assembly.model.assem...@15fddb33
Assembly is incorrectly configured:
Assembly: is not configured correctly: Assembly ID must be present and
non-empty.
--
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-517) Assembly fails with empty id element now
[
http://jira.codehaus.org/browse/MASSEMBLY-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=240973#action_240973
]
Brian Fox commented on MASSEMBLY-517:
-
This was intentionally introduced by MASSEMBLY-464
Assembly fails with empty id element now
Key: MASSEMBLY-517
URL: http://jira.codehaus.org/browse/MASSEMBLY-517
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Eric Haszlakiewicz
Priority: Critical
There is a serious regression in behaviour between version 2.2-beta-5 and
2.2. With version 2.2, assembly descriptors that have an empty id element no
longer work. i.e.:
assembly
id/id
formatsformattar.gz/format/formats
/assembly
The error message is:
[INFO] [assembly:single {execution: assemble-tar-gzip}]
[INFO] Reading assembly descriptor: src/main/assembly/assembly.xml
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] : org.apache.maven.plugin.assembly.model.assem...@15fddb33
Assembly is incorrectly configured:
Assembly: is not configured correctly: Assembly ID must be present and
non-empty.
--
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-517) Assembly fails with empty id element now
[
http://jira.codehaus.org/browse/MASSEMBLY-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=240975#action_240975
]
Eric Haszlakiewicz commented on MASSEMBLY-517:
--
Well from my POV this is a horrible change because:
1) If your main artifact IS the one that you are describing with the assembly
descriptor this is the only way to create it. The fact that a pom packaging
artifact gets deployed is actually not desired, but can't be avoided.
2) Having to specify a classifier AND an alternate packaging seems redundant.
3) There are projects that already use this, many of mine included. This
change breaks the builds for all of those.
4) This is a huge behaviour change to include at the last minute in the
transition from a beta to non-beta release.
Assembly fails with empty id element now
Key: MASSEMBLY-517
URL: http://jira.codehaus.org/browse/MASSEMBLY-517
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Eric Haszlakiewicz
Priority: Critical
There is a serious regression in behaviour between version 2.2-beta-5 and
2.2. With version 2.2, assembly descriptors that have an empty id element no
longer work. i.e.:
assembly
id/id
formatsformattar.gz/format/formats
/assembly
The error message is:
[INFO] [assembly:single {execution: assemble-tar-gzip}]
[INFO] Reading assembly descriptor: src/main/assembly/assembly.xml
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] : org.apache.maven.plugin.assembly.model.assem...@15fddb33
Assembly is incorrectly configured:
Assembly: is not configured correctly: Assembly ID must be present and
non-empty.
--
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-517) Assembly fails with empty id element now
[
http://jira.codehaus.org/browse/MASSEMBLY-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=240976#action_240976
]
John Casey commented on MASSEMBLY-517:
--
The change was not accidental, instead the fact that the id/ element wasn't
required was the bug.
However, using the appendAssemblyIdfalse/appendAssemblyId plugin
configuration should leave off the assembly-id classifier, even once the
binaries are deployed. If this isn't happening, then that's a separate bug,
which should be fixed.
Assembly fails with empty id element now
Key: MASSEMBLY-517
URL: http://jira.codehaus.org/browse/MASSEMBLY-517
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Eric Haszlakiewicz
Priority: Critical
There is a serious regression in behaviour between version 2.2-beta-5 and
2.2. With version 2.2, assembly descriptors that have an empty id element no
longer work. i.e.:
assembly
id/id
formatsformattar.gz/format/formats
/assembly
The error message is:
[INFO] [assembly:single {execution: assemble-tar-gzip}]
[INFO] Reading assembly descriptor: src/main/assembly/assembly.xml
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] : org.apache.maven.plugin.assembly.model.assem...@15fddb33
Assembly is incorrectly configured:
Assembly: is not configured correctly: Assembly ID must be present and
non-empty.
--
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-517) Assembly fails with empty id element now
[
http://jira.codehaus.org/browse/MASSEMBLY-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=240977#action_240977
]
Eric Haszlakiewicz commented on MASSEMBLY-517:
--
Just because it wasn't accidental doesn't mean it was a good idea.
The problem here is that now every single one of the applications that does
this needs to be changed, and it's not just my apps that depend on this
behaviour.
Why is it a problem to omit it in the assembly descriptor if, by specifying
appendAssemblyId false, it gets left off anyway? And what am I supposed to put
in the id in that case, just some random string? That seems like you took a
relatively natural way to cause the classifier to be omitted, and made it
needlessly verbose.
Assembly fails with empty id element now
Key: MASSEMBLY-517
URL: http://jira.codehaus.org/browse/MASSEMBLY-517
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Eric Haszlakiewicz
Priority: Critical
There is a serious regression in behaviour between version 2.2-beta-5 and
2.2. With version 2.2, assembly descriptors that have an empty id element no
longer work. i.e.:
assembly
id/id
formatsformattar.gz/format/formats
/assembly
The error message is:
[INFO] [assembly:single {execution: assemble-tar-gzip}]
[INFO] Reading assembly descriptor: src/main/assembly/assembly.xml
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] : org.apache.maven.plugin.assembly.model.assem...@15fddb33
Assembly is incorrectly configured:
Assembly: is not configured correctly: Assembly ID must be present and
non-empty.
--
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-517) Assembly fails with empty id element now
[
http://jira.codehaus.org/browse/MASSEMBLY-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=240979#action_240979
]
Eric Haszlakiewicz commented on MASSEMBLY-517:
--
IMO, if a change like this must be made, at the very least it should result in
a big warning for at least the length of a minor release (i.e. 2.2 through
2.3) to give people a chance to adjust their builds.
Assembly fails with empty id element now
Key: MASSEMBLY-517
URL: http://jira.codehaus.org/browse/MASSEMBLY-517
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Eric Haszlakiewicz
Priority: Critical
There is a serious regression in behaviour between version 2.2-beta-5 and
2.2. With version 2.2, assembly descriptors that have an empty id element no
longer work. i.e.:
assembly
id/id
formatsformattar.gz/format/formats
/assembly
The error message is:
[INFO] [assembly:single {execution: assemble-tar-gzip}]
[INFO] Reading assembly descriptor: src/main/assembly/assembly.xml
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] : org.apache.maven.plugin.assembly.model.assem...@15fddb33
Assembly is incorrectly configured:
Assembly: is not configured correctly: Assembly ID must be present and
non-empty.
--
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-517) Assembly fails with empty id element now
[
http://jira.codehaus.org/browse/MASSEMBLY-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=240982#action_240982
]
John Casey commented on MASSEMBLY-517:
--
The assembly id is used to report problems to the user, and for duplication
detection. Not to mention that, if left off, it could override the main project
jar (in cases, unlike yours, where people have distinct main project jars)
without much warning.
The following snippet from AbstractAssemblyMojo should ensure that the
appendAssemblyId/ flag works properly:
{code}
if ( isAssemblyIdAppended() )
{
projectHelper.attachArtifact( project, format,
assembly.getId(), destFile );
}
else if ( classifier != null )
{
projectHelper.attachArtifact( project, format,
classifier, destFile );
}
else if ( !pom.equals( type ) format.equals( type
) )
{
if ( !warnedAboutMainProjectArtifact )
{
final StringBuffer message = new StringBuffer();
message.append( Configuration options:
'appendAssemblyId' is set to false, and 'classifier' is missing. );
message.append( \nInstead of attaching the
assembly file: )
.append( destFile )
.append( , it will become the file for
main project artifact. );
message.append( \nNOTE: If multiple
descriptors or descriptor-formats are provided for this project, the value of
this file will be non-deterministic! );
getLog().warn( message );
warnedAboutMainProjectArtifact = true;
}
final File existingFile = project.getArtifact()
.getFile();
if ( ( existingFile != null )
existingFile.exists() )
{
getLog().warn( Replacing pre-existing project
main-artifact file: + existingFile
+ \nwith
assembly file: + destFile );
}
project.getArtifact()
.setFile( destFile );
}
else
{
projectHelper.attachArtifact( project, format,
null, destFile );
}
{code}
If this isn't working, then that's the bug here. IMO it's not appropriate to
make the id/ optional and create a hardship for new users (who may not
understand the implications), just to allow other users to avoid using the
proper plugin configuration.
Assembly fails with empty id element now
Key: MASSEMBLY-517
URL: http://jira.codehaus.org/browse/MASSEMBLY-517
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Eric Haszlakiewicz
Priority: Critical
There is a serious regression in behaviour between version 2.2-beta-5 and
2.2. With version 2.2, assembly descriptors that have an empty id element no
longer work. i.e.:
assembly
id/id
formatsformattar.gz/format/formats
/assembly
The error message is:
[INFO] [assembly:single {execution: assemble-tar-gzip}]
[INFO] Reading assembly descriptor: src/main/assembly/assembly.xml
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] : org.apache.maven.plugin.assembly.model.assem...@15fddb33
Assembly is incorrectly configured:
Assembly: is not configured correctly: Assembly ID must be present and
non-empty.
--
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: (MASSEMBLY-517) Assembly fails with empty id element now
[
http://jira.codehaus.org/browse/MASSEMBLY-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=240982#action_240982
]
John Casey edited comment on MASSEMBLY-517 at 10/25/10 4:49 PM:
The assembly id is used to report problems to the user, and for duplication
detection. Not to mention that, if left off, it could override the main project
jar (in cases, unlike yours, where people have distinct main project jars)
without much warning.
The following snippet from AbstractAssemblyMojo should ensure that the
appendAssemblyId/ flag works properly:
{code}
if ( isAssemblyIdAppended() )
{
projectHelper.attachArtifact( project, format, assembly.getId(), destFile );
}
else if ( classifier != null )
{
projectHelper.attachArtifact( project, format, classifier, destFile );
}
else if ( !pom.equals( type ) format.equals( type ) )
{
if ( !warnedAboutMainProjectArtifact )
{
final StringBuffer message = new StringBuffer();
message.append( Configuration options: 'appendAssemblyId' is set to
false, and 'classifier' is missing. );
message.append( \nInstead of attaching the assembly file: )
.append( destFile )
.append( , it will become the file for main project artifact.
);
message.append( \nNOTE: If multiple descriptors or descriptor-formats
are provided for this project, the value of this file will be
non-deterministic! );
getLog().warn( message );
warnedAboutMainProjectArtifact = true;
}
final File existingFile = project.getArtifact()
.getFile();
if ( ( existingFile != null ) existingFile.exists() )
{
getLog().warn( Replacing pre-existing project main-artifact file: +
existingFile
+ \nwith assembly file: + destFile );
}
project.getArtifact()
.setFile( destFile );
}
else
{
projectHelper.attachArtifact( project, format, null, destFile );
}
{code}
If this isn't working, then that's the bug here. IMO it's not appropriate to
make the id/ optional and create a hardship for new users (who may not
understand the implications), just to allow other users to avoid using the
proper plugin configuration.
was (Author: jdcasey):
The assembly id is used to report problems to the user, and for duplication
detection. Not to mention that, if left off, it could override the main project
jar (in cases, unlike yours, where people have distinct main project jars)
without much warning.
The following snippet from AbstractAssemblyMojo should ensure that the
appendAssemblyId/ flag works properly:
{code}
if ( isAssemblyIdAppended() )
{
projectHelper.attachArtifact( project, format,
assembly.getId(), destFile );
}
else if ( classifier != null )
{
projectHelper.attachArtifact( project, format,
classifier, destFile );
}
else if ( !pom.equals( type ) format.equals( type
) )
{
if ( !warnedAboutMainProjectArtifact )
{
final StringBuffer message = new StringBuffer();
message.append( Configuration options:
'appendAssemblyId' is set to false, and 'classifier' is missing. );
message.append( \nInstead of attaching the
assembly file: )
.append( destFile )
.append( , it will become the file for
main project artifact. );
message.append( \nNOTE: If multiple
descriptors or descriptor-formats are provided for this project, the value of
this file will be non-deterministic! );
getLog().warn( message );
warnedAboutMainProjectArtifact = true;
}
final File existingFile = project.getArtifact()
.getFile();
if ( ( existingFile != null )
existingFile.exists() )
{
getLog().warn( Replacing pre-existing project
main-artifact file: + existingFile
+ \nwith
assembly file: + destFile );
}
project.getArtifact()
.setFile( destFile );
}
else
{
projectHelper.attachArtifact( project, format,
[jira] Commented: (MJAVADOC-284) detectOfflineLinks sets off extra spurious executions of javadoc
[
http://jira.codehaus.org/browse/MJAVADOC-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=240987#action_240987
]
Benson Margulies commented on MJAVADOC-284:
---
{code}
svn co https://svn.apache.org/repos/asf/mahout/trunk
maven 3.0 ...
mvn -Prelease
{code}
detectOfflineLinks sets off extra spurious executions of javadoc
Key: MJAVADOC-284
URL: http://jira.codehaus.org/browse/MJAVADOC-284
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.6.1
Reporter: Benson Margulies
I have an aggregate project. In pluginManagement, I spec out javadoc:jar. In
the leaf projects, I turn it on with an ordinary plugin/ for the plugin.
If I leave detectOfflineLinks with its default value of true, the javadoc
plugin uses the invoker plugin to relaunch itself, recursively, complaining
that it hasn't been run on one or another of the projects. Note that, when
this happens, it is 'swimming upstream' -- it is processing project A, it
invokes itself on project B, where B depends on A, not the other way around.
If I run maven just in the leaf directories all is well. The trouble only
happens when running maven from the aggregating parent.
Just to clarify, in case I don't get a test case together too soon ...
external/corporate parent:
javadoc only mentioned in the reporting section.
aggregating parent:
javadoc only mentioned in pluginManagement, setting up execution of
javadoc:jar.
leaf:
A very plain 'plugin' element just to turn on the configuration from plugin
management.
mvn run from leaf: all is well.
mvn run from aggregating parent: lots of extra 'invoker' invocations of
javadoc on projects that have dependencies on the current project.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPIR-181) Dependency reporting plugin overwrites other project's artifact file
[
http://jira.codehaus.org/browse/MPIR-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=240994#action_240994
]
Karl M. Davis commented on MPIR-181:
For what it's worth, that code has changed some now and has some other
problems. Here's the new code (taken from the [Source
Xref|http://maven.apache.org/plugins/maven-project-info-reports-plugin/xref/org/apache/maven/report/projectinfo/dependencies/Dependencies.html#302]):
{noformat}
302 private void mapArtifactFiles( DependencyNode node, Map projectMap )
303 {
304 List childs = node.getChildren();
305 if ( ( childs == null ) || childs.isEmpty() )
306 {
307 return;
308 }
309
310 Iterator it = childs.iterator();
311 while ( it.hasNext() )
312 {
313 DependencyNode anode = (DependencyNode) it.next();
314 String key = ArtifactUtils.versionlessKey( anode.getArtifact()
);
315 Artifact projartifact = (Artifact) projectMap.get( key );
316 if ( projartifact != null )
317 {
318 anode = new DependencyNode( ArtifactUtils.copyArtifact(
projartifact ) );
319 anode.getArtifact().setFile( projartifact.getFile() );
320 }
321
322 mapArtifactFiles( anode, projectMap );
323 }
324 }
{noformat}
Line 318 appears to have been added to address this bug. However, this is just
a local reassignment and leaves the real {{anode}} in the dependency tree
as-is. Because of this, the real node in the tree never gets its file set.
This floods the log with errors as follows:
{noformat}
[ERROR] Artifact: foo:bar:1.0 has no file.
{noformat}
Furthermore, the local reassignment doesn't bring along the real node's
children, which prevents this code from properly recursing through the tree.
(I noticed these problems while trying to track down the cause of those log
errors on one of my builds. If you ever run {{site:site}} with {{-X}}, the
amount of these that get generated is crazy.)
Dependency reporting plugin overwrites other project's artifact file
Key: MPIR-181
URL: http://jira.codehaus.org/browse/MPIR-181
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Bug
Environment: Linux
Reporter: blaabloo
Projectmap is map of artifacts with groupid:artifactid being the key. When
project has multiple artifacts only one of them is put to the map. Dependency
node contains information about artifact and file information is the same
reference as used DefaultLifecycleExecutor. Every dependency's file is set
from this map and when building multimodule projects the latter projects may
fail because project's default artifact file is set to one of its attached
artifacts.
In org.apache.maven.report.projectinfo.dependencies.Dependencies
private void mapArtifactFiles( DependencyNode node, Map projectMap )
{
List childs = node.getChildren();
if ( ( childs == null ) || childs.isEmpty() )
{
return;
}
Iterator it = childs.iterator();
while ( it.hasNext() )
{
DependencyNode anode = (DependencyNode) it.next();
String key = ArtifactUtils.versionlessKey( anode.getArtifact() );
Artifact projartifact = (Artifact) projectMap.get( key );
if ( projartifact != null )
{
anode.getArtifact().setFile( projartifact.getFile() );
}
mapArtifactFiles( anode, projectMap );
}
}
--
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
