[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 mymavenrepo myuser C:/Dokumente und Einstellungen/bmaehr/.ssh/myprivatekey.id mypassword 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 > mymavenrepo > myuser > C:/Dokumente und > Einstellungen/bmaehr/.ssh/myprivatekey.id > mypassword > 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-tabpanel&focusedCommentId=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}
{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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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}
uses
{code}
This make eclipse to copy the library in "/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}
uses
{code}
and the library has been placed correctly in "/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}
uses
{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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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: > >myassembly.xml > > 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: > > my-assembly-descriptor-id > -- 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.:
tar.gz
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-tabpanel&focusedCommentId=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
>pom 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.:
>
>
> tar.gz
>
>
> 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-tabpanel&focusedCommentId=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.:
>
>
> tar.gz
>
>
> 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-tabpanel&focusedCommentId=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.:
>
>
> tar.gz
>
>
> 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-tabpanel&focusedCommentId=240976#action_240976
]
John Casey commented on MASSEMBLY-517:
--
The change was not accidental, instead the fact that the element wasn't
required was the bug.
However, using the false 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.:
>
>
> tar.gz
>
>
> 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-tabpanel&focusedCommentId=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.:
>
>
> tar.gz
>
>
> 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-tabpanel&focusedCommentId=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.:
>
>
> tar.gz
>
>
> 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-tabpanel&focusedCommentId=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
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 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.:
>
>
> tar.gz
>
>
> 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-tabpanel&focusedCommentId=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
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 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
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,
nu
[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-tabpanel&focusedCommentId=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 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 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-tabpanel&focusedCommentId=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
[jira] Commented: (WAGON-311) NPE and CommandExecutionException when creating directory over SSH
[
http://jira.codehaus.org/browse/WAGON-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=241010#action_241010
]
Nikolay Kushin commented on WAGON-311:
--
I experienced the same problem
{quote}
[ERROR] BUILD ERROR
[INFO]
[INFO] Error handling resource
Embedded error: Cannot execute remote command: mkdir -p /test/application/views/
engine/compile
java.lang.NullPointerException
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error handling resource
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:719)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:556)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:535)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:6
0)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error handling resour
ce
at org.codehaus.mojo.wagon.AbstractSingleWagonMojo.execute(AbstractSingl
eWagonMojo.java:67)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:694)
... 17 more
Caused by: org.apache.maven.wagon.TransferFailedException: Cannot execute remote
command: mkdir -p /test/application/views/engine/compile
at org.apache.maven.wagon.providers.ssh.jsch.ScpWagon.fillOutputData(Scp
Wagon.java:329)
at org.apache.maven.wagon.StreamWagon.getOutputStream(StreamWagon.java:1
88)
at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:159)
at org.codehaus.mojo.wagon.shared.DefaultWagonUpload.upload(DefaultWagon
Upload.java:71)
at org.codehaus.mojo.wagon.shared.DefaultWagonUpload.upload(DefaultWagon
Upload.java:81)
at org.codehaus.mojo.wagon.UploadMojo.execute(UploadMojo.java:114)
at org.codehaus.mojo.wagon.AbstractSingleWagonMojo.execute(AbstractSingl
eWagonMojo.java:63)
... 19 more
Caused by: org.apache.maven.wagon.CommandExecutionException: Cannot execute remo
te command: mkdir -p /test/application/views/engine/compile
at org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.executeCo
mmand(AbstractJschWagon.java:326)
at org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.executeCo
mmand(AbstractJschWagon.java:379)
at org.apache.maven.wagon.providers.ssh.ScpHelper.createRemoteDirectorie
s(ScpHelper.java:344)
at org.apache.maven.wagon.providers.ssh.jsch.ScpWagon.fillOutputData(Scp
Wagon.java:323)
... 25 more
Caused by: com.jcraft.jsch.JSchException: java.lang.NullPointerException
at com.jcraft.jsch.Channel.connect(Channel.java:205)
at com.jcraft.jsch.Channel.connect(Channel.java:144)
at org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.executeCo
mmand(AbstractJschWagon.java:305)
... 28 more
[INFO]
[INFO] Total time: 2 minutes 18 seconds
[INFO] Finished at: Tue Oct 26 10:09:06 MSD 2010
[INFO] Final Memory: 11M/29M
[INFO]
{quote}
{quote}
...
org.apache.maven.wagon
wagon-ssh
1.0-beta-6
org.codehaus.mojo
wagon-maven-plugin
1.0-beta-3
${url.base}
${serverId}
false
[jira] Commented: (MEV-611) commons-cli version 1.1 is missing from the metadata
[ http://jira.codehaus.org/browse/MEV-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=241011#action_241011 ] Juven Xu commented on MEV-611: -- please create a ticket at https://issues.sonatype.org/browse/MVNCENTRAL, this MEV project will be shut down soon. > commons-cli version 1.1 is missing from the metadata > > > Key: MEV-611 > URL: http://jira.codehaus.org/browse/MEV-611 > Project: Maven Evangelism > Issue Type: Bug > Components: Invalid Metadata >Reporter: Dennis Lundberg >Assignee: Juven Xu > > The 1.1 version is missing from the maven-metadata.xml file. > This probably has something to do with the fact that artifacts with a groupId > different from org.apache.* has to be manually synced from the ASF repo to > the Central repo. -- 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
