[jira] Updated: (MSHARED-203) DefaultSiteTool.getRelativePath returns nonsense if both paths are absolute with different scheme
[ https://jira.codehaus.org/browse/MSHARED-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated MSHARED-203: -- Summary: DefaultSiteTool.getRelativePath returns nonsense if both paths are absolute with different scheme (was: DefaultSiteTool.getRelativePath returns nonsense if both paths are absolute) > DefaultSiteTool.getRelativePath returns nonsense if both paths are absolute > with different scheme > - > > Key: MSHARED-203 > URL: https://jira.codehaus.org/browse/MSHARED-203 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-doxia-tools >Affects Versions: maven-doxia-tools-1.2.1 >Reporter: Lukas Theussl > > See MSITE-600: for the two method parameters from = > "scp://localhost:/tmp/blop" and to = "file:///tmp/bloop" the result is a > relative path that is plain nonsense. It should return just the 'to' > argument, since both paths are absolute. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-318) not correctly filtered
[
https://jira.codehaus.org/browse/ARCHETYPE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276627#comment-276627
]
Tuomas Kiviaho commented on ARCHETYPE-318:
--
>This patch unifies interactive and batch mode behavior.
filtering is done only in part of the code that get's executed when interactive
mode is used. Batch mode has completely separate handling. I merged these two
execution paths together so that the only real difference is that required user
input in interactive mode is replaced with default values in batch mode
>Replacement of required properties now fails if transitive properties are not
>resolved.
code seems to call as property values containing references to other properties
(like ${artifactId}.itest1) as 'transitive properties'. If property references
can't be resolved the build fails.
>There (is) also an oddity...
Codebase seems to treat groupId, artifactId, version (and package) a bit
differently than other properties. Properties with same name can't be
configured for instance as optional because what you'd only be generating
duplicate properties with same name. This is just something that caught my eye.
There wasn't existing test cases to begin with so I only could test with my own
code and while trying to keep the number of changed lines in minimum.
> not correctly filtered
>
>
> Key: ARCHETYPE-318
> URL: https://jira.codehaus.org/browse/ARCHETYPE-318
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
>Affects Versions: 2.0-alpha-5
>Reporter: Jochen Ehret
>Priority: Minor
> Fix For: 2.x
>
> Attachments: DefaultArchetypeGenerationConfigurator.patch
>
>
> In our archetype-metadata.xml we´ve defined a with a
> default value like this:
> {code:xml}
> ${artifactId}.itest1
> {code}
> When we call "archetype:generate" and enter the parameters in interactive
> mode everything works fine. But when we try to set the parameter
> "subArtifactId" on the command line (mvn archetype:generate
> -DsubArtifactId=xyz) or from an "archetype.properties" file, the value is
> ignored. In the generated pom.xml the variable ${subArtifactId} is always
> replaced with "${artifactId}.itest1".
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-140) Performance degredation
[
https://jira.codehaus.org/browse/MJAR-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276628#comment-276628
]
Eran Harel commented on MJAR-140:
-
When will the 2.3.2 / 2.4 artifacts be available in the maven repository?
> Performance degredation
>
>
> Key: MJAR-140
> URL: https://jira.codehaus.org/browse/MJAR-140
> Project: Maven 2.x JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.3, 2.3.1
>Reporter: Eran Harel
>Assignee: Kristian Rosenvold
> Fix For: 2.3.2
>
>
> I migrated maven to version 3.0.1 in order to utilize the parallel build
> experimental feature.
> As a result I get the following warning:
> {code}
> [WARNING] *
> [WARNING] * Your build is requesting parallel execution, but project *
> [WARNING] * contains the following plugin(s) that are not marked as *
> [WARNING] * @threadSafe to support parallel building. *
> [WARNING] * While this /may/ work fine, please look for plugin updates*
> [WARNING] * and/or request plugins be made thread-safe. *
> [WARNING] * If reporting an issue, report it against the plugin in*
> [WARNING] * question, not against maven-core *
> [WARNING] *
> [WARNING] The following plugins are not marked @threadSafe in DataBuilder:
> [WARNING] org.apache.maven.plugins:maven-eclipse-plugin:2.8
> [WARNING] org.apache.maven.plugins:maven-jar-plugin:2.2
> [WARNING] *
> {code}
> I upgraded the maven-jar-plugin to the latest version (2.3.1), and the
> message is gone, but now the builds take much longer: minutes added!!!
> The build takes about x 1.5 longer now.
> I also compared the maven 3 parallel build time with the new jar-plugin VS a
> serial build with the old 2.2 plugin version I had. The results are that
> same, while when using the parallel build with the 2.2 plugin I see a
> significant ~30% performance boost.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-318) not correctly filtered
[
https://jira.codehaus.org/browse/ARCHETYPE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276630#comment-276630
]
Tuomas Kiviaho commented on ARCHETYPE-318:
--
I see that there is a property-setting-cli that could be converted to batch
mode test quite easily. The required property in the declaration is a good
permutation to begin with and both cli and batch mode should contain also more
deeply nested property referencing scenarios. (a=${b},b=${c},c=foobar).
> not correctly filtered
>
>
> Key: ARCHETYPE-318
> URL: https://jira.codehaus.org/browse/ARCHETYPE-318
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
>Affects Versions: 2.0-alpha-5
>Reporter: Jochen Ehret
>Priority: Minor
> Fix For: 2.x
>
> Attachments: DefaultArchetypeGenerationConfigurator.patch
>
>
> In our archetype-metadata.xml we´ve defined a with a
> default value like this:
> {code:xml}
> ${artifactId}.itest1
> {code}
> When we call "archetype:generate" and enter the parameters in interactive
> mode everything works fine. But when we try to set the parameter
> "subArtifactId" on the command line (mvn archetype:generate
> -DsubArtifactId=xyz) or from an "archetype.properties" file, the value is
> ignored. In the generated pom.xml the variable ${subArtifactId} is always
> replaced with "${artifactId}.itest1".
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MGPG-34) Allow to define an alternative pomFile when sign (gpg:sign) the project artifact
[ https://jira.codehaus.org/browse/MGPG-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MGPG-34: - Labels: scrub-review-started (was: ) > Allow to define an alternative pomFile when sign (gpg:sign) the project > artifact > > > Key: MGPG-34 > URL: https://jira.codehaus.org/browse/MGPG-34 > Project: Maven 2.x GPG Plugin > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Laszlo Hordos > Labels: scrub-review-started > Attachments: maven-gpg-plugin.patch > > > This small modification allow to specify an alternative pomFile to sign > instead of the default project file. It's very useful when a custom pom file > has been generated during the build process. I'm using a complex build > configuration for a framework where I need to create custom pom files. I'm > able create a release from my CI and publish it to the central repository the > gpg:sign signs the wrong pom file. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MGPG-34) Allow to define an alternative pomFile when sign (gpg:sign) the project artifact
[ https://jira.codehaus.org/browse/MGPG-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276633#comment-276633 ] Stephen Connolly commented on MGPG-34: -- Would need to see integration tests that verify that this patch does not affect builds of projects with both packaging pom and packaging jar. And would also need to see integration tests that verify correct behaviour when using the maven-shade-plugin on a jar project and having shade replace the pom file with the dependency reduced pom file. I suspect that the real cause is that whatever custom actions you are doing to create these custom pom files is failing to register the pom file change with the model the way that m-shade-p does, i.e. http://maven.apache.org/plugins/maven-shade-plugin/xref/org/apache/maven/plugins/shade/mojo/ShadeMojo.html#851 Note however that shade is doing a lot more crazy stuff so it is really only the line 851 that is what is required (much like creating custom artifacts requires they be attached to the reactor) > Allow to define an alternative pomFile when sign (gpg:sign) the project > artifact > > > Key: MGPG-34 > URL: https://jira.codehaus.org/browse/MGPG-34 > Project: Maven 2.x GPG Plugin > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Laszlo Hordos > Labels: scrub-review-started > Attachments: maven-gpg-plugin.patch > > > This small modification allow to specify an alternative pomFile to sign > instead of the default project file. It's very useful when a custom pom file > has been generated during the build process. I'm using a complex build > configuration for a framework where I need to create custom pom files. I'm > able create a release from my CI and publish it to the central repository the > gpg:sign signs the wrong pom file. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MGPG-31) Integrate w/ Maven password encryption to avoid need to type passphrase
[
https://jira.codehaus.org/browse/MGPG-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MGPG-31:
-
Labels: contributers-welcome (was: )
> Integrate w/ Maven password encryption to avoid need to type passphrase
> ---
>
> Key: MGPG-31
> URL: https://jira.codehaus.org/browse/MGPG-31
> Project: Maven 2.x GPG Plugin
> Issue Type: Improvement
>Affects Versions: 1.1
> Environment: JDK 6u21, Ubuntu, Maven 3.0 RC1
>Reporter: Jesse Glick
>Priority: Minor
> Labels: contributers-welcome
> Fix For: 1.4
>
>
> It is cumbersome to be prompted for a passphrase during both release:prepare
> and release:perform:
> {noformat}
> [INFO] --- maven-gpg-plugin:1.1:sign (sign-artifacts) @ nbm-maven-plugin
> ---
> GPG Passphrase: *
> {noformat}
> I already use http://maven.apache.org/guides/mini/guide-encryption.html (with
> a master password on an Ubuntu encrypted filesystem) so why do I need to type
> this pass phrase each time too?
> Not clear to me whether MGPG-30 already permits this. In any event, the
> plugin documentation does not seem to mention this as a use case.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MGPG-31) Integrate w/ Maven password encryption to avoid need to type passphrase
[
https://jira.codehaus.org/browse/MGPG-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276634#comment-276634
]
Stephen Connolly commented on MGPG-31:
--
The correct way to handle this is to use an agent ideally integrated with the
OS.
However, I have seen enough people who don't take the security of their GPG
keys religiously. So just because there are people who think that the right
thing is never to leave your passphrase on any disk in a reversible encryption,
does not mean that we cannot support those who feel comfortable with the
(hopefully educated) risk.
If somebody has a patch with test cases...
> Integrate w/ Maven password encryption to avoid need to type passphrase
> ---
>
> Key: MGPG-31
> URL: https://jira.codehaus.org/browse/MGPG-31
> Project: Maven 2.x GPG Plugin
> Issue Type: Improvement
>Affects Versions: 1.1
> Environment: JDK 6u21, Ubuntu, Maven 3.0 RC1
>Reporter: Jesse Glick
>Priority: Minor
> Labels: contributers-welcome
> Fix For: 1.4
>
>
> It is cumbersome to be prompted for a passphrase during both release:prepare
> and release:perform:
> {noformat}
> [INFO] --- maven-gpg-plugin:1.1:sign (sign-artifacts) @ nbm-maven-plugin
> ---
> GPG Passphrase: *
> {noformat}
> I already use http://maven.apache.org/guides/mini/guide-encryption.html (with
> a master password on an Ubuntu encrypted filesystem) so why do I need to type
> this pass phrase each time too?
> Not clear to me whether MGPG-30 already permits this. In any event, the
> plugin documentation does not seem to mention this as a use case.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MGPG-31) Integrate w/ Maven password encryption to avoid need to type passphrase
[
https://jira.codehaus.org/browse/MGPG-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MGPG-31:
-
Fix Version/s: (was: 1.4)
> Integrate w/ Maven password encryption to avoid need to type passphrase
> ---
>
> Key: MGPG-31
> URL: https://jira.codehaus.org/browse/MGPG-31
> Project: Maven 2.x GPG Plugin
> Issue Type: Improvement
>Affects Versions: 1.1
> Environment: JDK 6u21, Ubuntu, Maven 3.0 RC1
>Reporter: Jesse Glick
>Priority: Minor
> Labels: contributers-welcome
>
> It is cumbersome to be prompted for a passphrase during both release:prepare
> and release:perform:
> {noformat}
> [INFO] --- maven-gpg-plugin:1.1:sign (sign-artifacts) @ nbm-maven-plugin
> ---
> GPG Passphrase: *
> {noformat}
> I already use http://maven.apache.org/guides/mini/guide-encryption.html (with
> a master password on an Ubuntu encrypted filesystem) so why do I need to type
> this pass phrase each time too?
> Not clear to me whether MGPG-30 already permits this. In any event, the
> plugin documentation does not seem to mention this as a use case.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MGPG-33) Signing fails if passphrase contains non-English letters
[ https://jira.codehaus.org/browse/MGPG-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MGPG-33: - Labels: contributers-welcome (was: ) > Signing fails if passphrase contains non-English letters > > > Key: MGPG-33 > URL: https://jira.codehaus.org/browse/MGPG-33 > Project: Maven 2.x GPG Plugin > Issue Type: Bug >Affects Versions: 1.1 > Environment: - Mac OSX 10.6.4 > - Maven 2.2.1 > - Java 1.6.0_22 >Reporter: Harri Halttunen > Labels: contributers-welcome > > If passphrase contains non-English letters, like ä, ö (Scandinavian > alphabets) then signing fails. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MGPG-33) Signing fails if passphrase contains non-English letters
[ https://jira.codehaus.org/browse/MGPG-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276635#comment-276635 ] Stephen Connolly commented on MGPG-33: -- Could somebody create a throwaway gpg key based test case? (i.e. create a GPG key that is not yours and you created just for the throw away test case, attach the key, the passphrase for the key, and hopefully a test project that shows the buggy behaviour) > Signing fails if passphrase contains non-English letters > > > Key: MGPG-33 > URL: https://jira.codehaus.org/browse/MGPG-33 > Project: Maven 2.x GPG Plugin > Issue Type: Bug >Affects Versions: 1.1 > Environment: - Mac OSX 10.6.4 > - Maven 2.2.1 > - Java 1.6.0_22 >Reporter: Harri Halttunen > Labels: contributers-welcome > > If passphrase contains non-English letters, like ä, ö (Scandinavian > alphabets) then signing fails. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MGPG-27) Allow option to create none ascii output
[ https://jira.codehaus.org/browse/MGPG-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MGPG-27: - Labels: scrub-review-started (was: ) > Allow option to create none ascii output > > > Key: MGPG-27 > URL: https://jira.codehaus.org/browse/MGPG-27 > Project: Maven 2.x GPG Plugin > Issue Type: New Feature >Affects Versions: 1.1 > Environment: all >Reporter: Dan Tran > Labels: scrub-review-started > > Please add new option "armor" with default value "true" to keep the default > behavior. > The motivation is i am currently have a sh script using gpg and expect the > produce a binary gpg file. It would be nice for me to use maven-gpg-plugin > intead -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MGPG-27) Allow option to create none ascii output
[ https://jira.codehaus.org/browse/MGPG-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276637#comment-276637 ] Stephen Connolly commented on MGPG-27: -- I would rather see a separate parameter for creating the .sig files. The .asc files are required for deployment to central. Something that the default is null/false, in which case no .sig files are generated, but if you specify the parameter as true, then the .sig files are generated _in_addition_to_ the .asc files. > Allow option to create none ascii output > > > Key: MGPG-27 > URL: https://jira.codehaus.org/browse/MGPG-27 > Project: Maven 2.x GPG Plugin > Issue Type: New Feature >Affects Versions: 1.1 > Environment: all >Reporter: Dan Tran > Labels: scrub-review-started > > Please add new option "armor" with default value "true" to keep the default > behavior. > The motivation is i am currently have a sh script using gpg and expect the > produce a binary gpg file. It would be nice for me to use maven-gpg-plugin > intead -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-28) Deployment should delete remote files and create new ones instead of modifying them
[ https://jira.codehaus.org/browse/MDEPLOY-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276638#comment-276638 ] Stephen Connolly commented on MDEPLOY-28: - Is this still an issue? > Deployment should delete remote files and create new ones instead of > modifying them > --- > > Key: MDEPLOY-28 > URL: https://jira.codehaus.org/browse/MDEPLOY-28 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.2.1 >Reporter: Carlos Sanchez >Priority: Critical > Labels: scrub-review-started > > Remote files usually are non group writable while the directory is to prevent > changes in the files without knowing who changed it (eg. apache repository > policy) > So deployment should delete metadata files and create new ones instead of > editing them -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MDEPLOY-28) Deployment should delete remote files and create new ones instead of modifying them
[ https://jira.codehaus.org/browse/MDEPLOY-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MDEPLOY-28: Labels: scrub-review-started (was: ) > Deployment should delete remote files and create new ones instead of > modifying them > --- > > Key: MDEPLOY-28 > URL: https://jira.codehaus.org/browse/MDEPLOY-28 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.2.1 >Reporter: Carlos Sanchez >Priority: Critical > Labels: scrub-review-started > > Remote files usually are non group writable while the directory is to prevent > changes in the files without knowing who changed it (eg. apache repository > policy) > So deployment should delete metadata files and create new ones instead of > editing them -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-140) Performance degredation
[
https://jira.codehaus.org/browse/MJAR-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276639#comment-276639
]
Kristian Rosenvold commented on MJAR-140:
-
2.3.2 is available now
> Performance degredation
>
>
> Key: MJAR-140
> URL: https://jira.codehaus.org/browse/MJAR-140
> Project: Maven 2.x JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.3, 2.3.1
>Reporter: Eran Harel
>Assignee: Kristian Rosenvold
> Fix For: 2.3.2
>
>
> I migrated maven to version 3.0.1 in order to utilize the parallel build
> experimental feature.
> As a result I get the following warning:
> {code}
> [WARNING] *
> [WARNING] * Your build is requesting parallel execution, but project *
> [WARNING] * contains the following plugin(s) that are not marked as *
> [WARNING] * @threadSafe to support parallel building. *
> [WARNING] * While this /may/ work fine, please look for plugin updates*
> [WARNING] * and/or request plugins be made thread-safe. *
> [WARNING] * If reporting an issue, report it against the plugin in*
> [WARNING] * question, not against maven-core *
> [WARNING] *
> [WARNING] The following plugins are not marked @threadSafe in DataBuilder:
> [WARNING] org.apache.maven.plugins:maven-eclipse-plugin:2.8
> [WARNING] org.apache.maven.plugins:maven-jar-plugin:2.2
> [WARNING] *
> {code}
> I upgraded the maven-jar-plugin to the latest version (2.3.1), and the
> message is gone, but now the builds take much longer: minutes added!!!
> The build takes about x 1.5 longer now.
> I also compared the maven 3 parallel build time with the new jar-plugin VS a
> serial build with the old 2.2 plugin version I had. The results are that
> same, while when using the parallel build with the 2.2 plugin I see a
> significant ~30% performance boost.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-99) deploy:deploy-file over rights maven-metadata.xml
[ https://jira.codehaus.org/browse/MDEPLOY-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276640#comment-276640 ] Stephen Connolly commented on MDEPLOY-99: - MDEPLOY-137 should handle the case where you want to deploy multiple artifacts. Otherwise I think this should be resolved as not a bug. > deploy:deploy-file over rights maven-metadata.xml > - > > Key: MDEPLOY-99 > URL: https://jira.codehaus.org/browse/MDEPLOY-99 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 2.4 > Environment: Windows XP >Reporter: Jim McCaskey > Labels: scrub-review-started > > Using deploy:deploy-file to add multiple version of an artifact causes the > artifactId maven-metadata.xml file to be recreated new and the old contents > to be removed. Once done I am left with contents like this: > > com.pervasive.component > artifact-distribution > 4.0.2.11 > > > 4.0.2.11 > > 20090401013925 > > > This is using Maven 2.1.0 and maven-deploy-plugin 2.4. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MDEPLOY-99) deploy:deploy-file over rights maven-metadata.xml
[ https://jira.codehaus.org/browse/MDEPLOY-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MDEPLOY-99: Labels: scrub-review-started (was: ) > deploy:deploy-file over rights maven-metadata.xml > - > > Key: MDEPLOY-99 > URL: https://jira.codehaus.org/browse/MDEPLOY-99 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 2.4 > Environment: Windows XP >Reporter: Jim McCaskey > Labels: scrub-review-started > > Using deploy:deploy-file to add multiple version of an artifact causes the > artifactId maven-metadata.xml file to be recreated new and the old contents > to be removed. Once done I am left with contents like this: > > com.pervasive.component > artifact-distribution > 4.0.2.11 > > > 4.0.2.11 > > 20090401013925 > > > This is using Maven 2.1.0 and maven-deploy-plugin 2.4. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-121) Allow uniqueVersion as deploy:deploy parameter or altDeploymentRepository field
[ https://jira.codehaus.org/browse/MDEPLOY-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276641#comment-276641 ] Stephen Connolly commented on MDEPLOY-121: -- Given that Maven 3 does not support uniqueVersion=false I do not see the value in adding this support. Campaign for Maven 3 to support uniqueVersion=false and this issue becomes relevant again. > Allow uniqueVersion as deploy:deploy parameter or altDeploymentRepository > field > --- > > Key: MDEPLOY-121 > URL: https://jira.codehaus.org/browse/MDEPLOY-121 > Project: Maven 2.x Deploy Plugin > Issue Type: New Feature > Components: deploy:deploy >Affects Versions: 2.5 >Reporter: SebbASF >Assignee: Mark Struberg > Labels: scrub-review-started > Attachments: deploy.patch, deploy.patch > > > The altDeploymentRepository property allows the id, layout and URL of a > repository to be overriden. > However it does not allow the uniqueVersion setting to be overriden. > This reduces its usefulness as an override mechanism. > Patch implements the feature by using one of the spare fields in the property: > id::layout:uniqueVersion:url > e.g. > id::layout:true:url > id::layout:false:url > id::layout::url > If the value is empty, it defaults to true, as per the previous behaviour. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MDEPLOY-121) Allow uniqueVersion as deploy:deploy parameter or altDeploymentRepository field
[ https://jira.codehaus.org/browse/MDEPLOY-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MDEPLOY-121: - Labels: scrub-review-started (was: ) > Allow uniqueVersion as deploy:deploy parameter or altDeploymentRepository > field > --- > > Key: MDEPLOY-121 > URL: https://jira.codehaus.org/browse/MDEPLOY-121 > Project: Maven 2.x Deploy Plugin > Issue Type: New Feature > Components: deploy:deploy >Affects Versions: 2.5 >Reporter: SebbASF >Assignee: Mark Struberg > Labels: scrub-review-started > Attachments: deploy.patch, deploy.patch > > > The altDeploymentRepository property allows the id, layout and URL of a > repository to be overriden. > However it does not allow the uniqueVersion setting to be overriden. > This reduces its usefulness as an override mechanism. > Patch implements the feature by using one of the spare fields in the property: > id::layout:uniqueVersion:url > e.g. > id::layout:true:url > id::layout:false:url > id::layout::url > If the value is empty, it defaults to true, as per the previous behaviour. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-67) altDeploymentRepository causes build numbers in snapshots to not be incremented
[ https://jira.codehaus.org/browse/MDEPLOY-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276642#comment-276642 ] Stephen Connolly commented on MDEPLOY-67: - First step would be if somebody can create a test case. > altDeploymentRepository causes build numbers in snapshots to not be > incremented > --- > > Key: MDEPLOY-67 > URL: https://jira.codehaus.org/browse/MDEPLOY-67 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Brian Fox > Labels: contributers-welcome > > I haven't looked in detail to this, but I think the deploy plugin is pulling > the metadata from the original distMgt repo and not the altDeployone. The > symptom is that all my snapshots end in -1 (i don't know if metadata > corruption could occur on releases). As soon as I threw out this feature and > used distMgt over rides in a profile, the build numbers started working. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-47) Timeout during SCP upload
[ https://jira.codehaus.org/browse/MDEPLOY-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276643#comment-276643 ] Stephen Connolly commented on MDEPLOY-47: - Is this still a bug? > Timeout during SCP upload > - > > Key: MDEPLOY-47 > URL: https://jira.codehaus.org/browse/MDEPLOY-47 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Windows XP, Java 1.5, Maven 2.0.4 >Reporter: Dennis Kieselhorst > Labels: scrub-review-started > > It seems that there is a timeout during the upload. Unfortunately the > deploy-plugin doesn't detect it. I have to close the console and kill the > java process in the task manager. > Uploading: > scp://mydevserver/opt/www/htdocs/maven2/de/dekies/test/test-client/2.8.27rc2/test-client-2.8.27rc2.jar > 4/20K > 8/20K > 12/20K > 16/20K > 20/20K > 20/20K > 20K uploaded > [INFO] Retrieving previous metadata from dekies > [INFO] Uploading repository metadata for: 'artifact > de.dekies.test:test-client' > [INFO] Retrieving previous metadata from dekies > [INFO] Uploading project information for test-client 2.8.27rc2 > --> nothing happens after this (for hours)! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEPLOY-60) Make the build number available at compile time
[ https://jira.codehaus.org/browse/MDEPLOY-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MDEPLOY-60. --- Resolution: Won't Fix The uniqueVersion that is used by the deploy plugin when deploying -SNAPSHOTs is only determined at the time of deployment. There is currently no way to obtain that information ahead of deployment. The only way I could see of achieving this would be to have a separate goal that allocates this value and can be attached to the validate phase of the lifecycle... if that goal were run then it would override deploy's default behaviour... but it would run the risk of breaking too many things. The correct solution is to just use the release plugin to make a release of the project. Putting a lot of effort in to making -SNAPSHOTs durable is not what -SNAPSHOTs are about > Make the build number available at compile time > --- > > Key: MDEPLOY-60 > URL: https://jira.codehaus.org/browse/MDEPLOY-60 > Project: Maven 2.x Deploy Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Antony Stubbs > > Make the build number which goes into the final filename of a deployed > snapshot, available at compile time, so that it can be filtered into a > properties file and used in the application. There are a lot of requests for > this on the forum, including people trying to implement their own > work-arounds [1] > There could also be an option to specify a custom build number - e.g. the > subversion revision number which is retrieved via the build number plug-in > [2]. > [1] > http://www.nabble.com/Auto-incrementing-a-build-identifier-tf2319084s177.html#a12026347 > [2] > http://commons.ucalgary.ca/projects/maven-buildnumber-plugin/introduction.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-62) deploy on remote repository with linux
[ https://jira.codehaus.org/browse/MDEPLOY-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276646#comment-276646 ] Stephen Connolly commented on MDEPLOY-62: - Seems like a fruitful area for somebody wanting to contribute... I would start by taking the attached info and trying to create a test case from it. Could probably use Apache Mina's SSH server to see if a test case can be constructed that is OS independent. > deploy on remote repository with linux > -- > > Key: MDEPLOY-62 > URL: https://jira.codehaus.org/browse/MDEPLOY-62 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.2.1 > Environment: first machine > Maven version: 2.0.7 > Java version: 1.5.0_12 > OS name: "linux" version: "2.6.18.8-0.5-default" arch: "i386" > OS Distribution: opensuse10.2 > ssh server/client: OpenSSH_4.4p1, OpenSSL 0.9.8d 28 Sep 2006 > or second machine > Maven version: 2.0.6 > Java version: 1.5.0_08 > OS name: Linux 2.6.19-gentoo-r5 #5 PREEMPT Mon Jul 2 13:23:01 IST 2007 i686 > Mobile AMD Athlon(tm) XP 2600+ AuthenticAMD GNU/Linux > OS Distribution: gentoo > ssh server/client: OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007 >Reporter: kristian meier > Labels: contributers-welcome > Attachments: pom.scpexe.xml, pom.scp.xml, settings-login.xml, > settings-publickey.xml > > > after I had again and again problems deploying on remote repositories on > linux and after I colleague of mine also struggled with this, I did some > testing. the tests I made on two machines and both produces the same results. > I used both scp and scpexe as well login and public key authentication. this > gives already quite a matrix. than I discovered that the behaviour is > different if the private key has a passphrase or not. so I also include these > two cases. > the whole test just deploys a pom artifact on localhost in the tmp directory. > so here are the results and some conclusions. the pom.xml and settings.xml I > used are attached. > === > openssh server default config > public-key: no passphrase, removed public-key and authorized_keys for login > tests > === > mvn deploy -f pom.scp.xml -s settings-login.xml > . . . > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error deploying artifact: Authentication failed: Cannot connect. > Reason: Auth fail > mvn deploy -f pom.scpexe.xml -s settings-login.xml > . . . > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error deploying artifact: Error executing command for transfer > Exit code 255 - Permission denied (publickey,keyboard-interactive). > mvn deploy -f pom.scp.xml -s settings-publickey.xml > . . . > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > mvn deploy -f pom.scpexe.xml -s settings-publickey.xml > . . . > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > === > openssh server with "PasswordAuthentication yes" > public-key: no passphrase, removed public-key and authorized_keys for login > tests > === > mvn deploy -f pom.scp.xml -s settings-login.xml > . . . > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > mvn deploy -f pom.scpexe.xml -s settings-login.xml > . . . > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error deploying artifact: Error executing command for transfer > Exit code 255 - Permission denied (publickey,password,keyboard-interactive). > mvn deploy -f pom.scp.xml -s settings-publickey.xml > . . . > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > mvn deploy -f pom.scpexe.xml -s settings-pub
[jira] Commented: (MDEPLOY-62) deploy on remote repository with linux
[ https://jira.codehaus.org/browse/MDEPLOY-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276647#comment-276647 ] Stephen Connolly commented on MDEPLOY-62: - Could well be a WAGON issue and nothing to do with deploy plugin > deploy on remote repository with linux > -- > > Key: MDEPLOY-62 > URL: https://jira.codehaus.org/browse/MDEPLOY-62 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.2.1 > Environment: first machine > Maven version: 2.0.7 > Java version: 1.5.0_12 > OS name: "linux" version: "2.6.18.8-0.5-default" arch: "i386" > OS Distribution: opensuse10.2 > ssh server/client: OpenSSH_4.4p1, OpenSSL 0.9.8d 28 Sep 2006 > or second machine > Maven version: 2.0.6 > Java version: 1.5.0_08 > OS name: Linux 2.6.19-gentoo-r5 #5 PREEMPT Mon Jul 2 13:23:01 IST 2007 i686 > Mobile AMD Athlon(tm) XP 2600+ AuthenticAMD GNU/Linux > OS Distribution: gentoo > ssh server/client: OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007 >Reporter: kristian meier > Labels: contributers-welcome > Attachments: pom.scpexe.xml, pom.scp.xml, settings-login.xml, > settings-publickey.xml > > > after I had again and again problems deploying on remote repositories on > linux and after I colleague of mine also struggled with this, I did some > testing. the tests I made on two machines and both produces the same results. > I used both scp and scpexe as well login and public key authentication. this > gives already quite a matrix. than I discovered that the behaviour is > different if the private key has a passphrase or not. so I also include these > two cases. > the whole test just deploys a pom artifact on localhost in the tmp directory. > so here are the results and some conclusions. the pom.xml and settings.xml I > used are attached. > === > openssh server default config > public-key: no passphrase, removed public-key and authorized_keys for login > tests > === > mvn deploy -f pom.scp.xml -s settings-login.xml > . . . > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error deploying artifact: Authentication failed: Cannot connect. > Reason: Auth fail > mvn deploy -f pom.scpexe.xml -s settings-login.xml > . . . > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error deploying artifact: Error executing command for transfer > Exit code 255 - Permission denied (publickey,keyboard-interactive). > mvn deploy -f pom.scp.xml -s settings-publickey.xml > . . . > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > mvn deploy -f pom.scpexe.xml -s settings-publickey.xml > . . . > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > === > openssh server with "PasswordAuthentication yes" > public-key: no passphrase, removed public-key and authorized_keys for login > tests > === > mvn deploy -f pom.scp.xml -s settings-login.xml > . . . > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > mvn deploy -f pom.scpexe.xml -s settings-login.xml > . . . > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error deploying artifact: Error executing command for transfer > Exit code 255 - Permission denied (publickey,password,keyboard-interactive). > mvn deploy -f pom.scp.xml -s settings-publickey.xml > . . . > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > mvn deploy -f pom.scpexe.xml -s settings-publickey.xml > . . . > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > --
[jira] Commented: (MDEPLOY-126) Deploy only artifacts which have been explicitly attached
[ https://jira.codehaus.org/browse/MDEPLOY-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276648#comment-276648 ] Stephen Connolly commented on MDEPLOY-126: -- MDEPLOY-114 or MDEPLOY-117 would seem to be a more correct and less hacky solution. Tempted to close in favour of one of those > Deploy only artifacts which have been explicitly attached > - > > Key: MDEPLOY-126 > URL: https://jira.codehaus.org/browse/MDEPLOY-126 > Project: Maven 2.x Deploy Plugin > Issue Type: Improvement >Affects Versions: 2.5 > Environment: Maven 3 >Reporter: Matthias Vach > Labels: scrub-review-started > Attachments: 001.diff > > > Hi all, > General Information: > > while releasing maven projects we do generate release metadata for any > project. The generated metadate need to be uploaded to nexus and are located > right beside the build results. > Since we don't want to affect the release build iselfe, the whole metadata > generation runs as a second build after the release build finished. > Now the problem: > > We want to use the deploy plugin to deploy the generated release metadata to > nexus. But the deploy plugin is currently attaching project artifacts and > pom-files automatically to the deployment. But this causes a HTTP-400 Error > at Nexus, since all pom-files and project artifacts have been deployed to > Nexus already. And redeployment is not allowed. > Currently missing: > > It would be cool if the deploy plugin would offer a switch to reduce the > deployment only to those artifacts/files which have been explicitly attached > for deployment in the reactor before. > Attached you do find a small patch. > Regards Matthias -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-97) the always be 1 on maven-metadata.xml
[ https://jira.codehaus.org/browse/MDEPLOY-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276649#comment-276649 ] Stephen Connolly commented on MDEPLOY-97: - Be interesting to know if the user changed maven version between sc-69-SNAPSHOT and sc-70-SNAPSHOT. OTOH this issue has not been updated in over 2 years, so is this still a bug? > the always be 1 on maven-metadata.xml > --- > > Key: MDEPLOY-97 > URL: https://jira.codehaus.org/browse/MDEPLOY-97 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug > Components: deploy:deploy >Affects Versions: 2.4 > Environment: unix, jdk 1.5 >Reporter: Michael Meng > Labels: scrub-review-started > Attachments: buildnumber.JPG, clear.doc, goodone.JPG > > > We have setup a project build on cruise control, whose version is SNAPSHOT > (in my case is 70-SNAPSHOT), however, the build result files look fine, but > the build number always be 1, what is the problem ? > You may compare the 2 pic, you will see the difference. the right pic is what > we expect. it has the build number 54,55, 56, 57 > while the left pic's build number always be 1 > in the maven-metadata.xml the buildNumber always 1, no matter how many times > you build it. > 1 > > ubhsc > sc > 70-SNAPSHOT > - > - > 20090320.170754 > 1 > > 20090320170754 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-92) When a snapshot is deployed with uniqueVersion=false, it's SNAPSHOT dependencies must be forced to timestamp
[ https://jira.codehaus.org/browse/MDEPLOY-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276650#comment-276650 ] Stephen Connolly commented on MDEPLOY-92: - See http://mojo.codehaus.org/versions-maven-plugin/lock-snapshots-mojo.html for a goal to use to pin the -SNAPSHOTs for you. The reality is that you may have some artifacts being deployed to a different repo with a different uniqueVersion setting. Also Nicolas is this title incorrect, I assume you mean uniqueVersion=true as when uniqueVersion=false you don't get the timestamp deployment. > When a snapshot is deployed with uniqueVersion=false, it's SNAPSHOT > dependencies must be forced to timestamp > > > Key: MDEPLOY-92 > URL: https://jira.codehaus.org/browse/MDEPLOY-92 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Reporter: nicolas de loof > Labels: scrub-review-started > > use case : > using the release plugin as a SNAPSHOT timestamped version to ensure > reproductibility. > When an incompatible SNAPSHOT of the release-manager is deployed, the plugin > doesn't work anymore : it updated it's SNAPSHOT dependencies. > -> uniqueVersion=false was useless to ensure reproductibility. > The isse is that the plugin POM has a SNAPSHOT dependency. As part of the > deploy process, the SNAPSHOT version SHOULD be forced to current timestamped > version to follow the uniqueVersion expectation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MDEPLOY-126) Deploy only artifacts which have been explicitly attached
[ https://jira.codehaus.org/browse/MDEPLOY-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276648#comment-276648 ] Stephen Connolly edited comment on MDEPLOY-126 at 8/22/11 4:04 AM: --- MDEPLOY-114 or MDEPLOY-118 would seem to be a more correct and less hacky solution. Tempted to close in favour of one of those was (Author: stephenconnolly): MDEPLOY-114 or MDEPLOY-117 would seem to be a more correct and less hacky solution. Tempted to close in favour of one of those > Deploy only artifacts which have been explicitly attached > - > > Key: MDEPLOY-126 > URL: https://jira.codehaus.org/browse/MDEPLOY-126 > Project: Maven 2.x Deploy Plugin > Issue Type: Improvement >Affects Versions: 2.5 > Environment: Maven 3 >Reporter: Matthias Vach > Labels: scrub-review-started > Attachments: 001.diff > > > Hi all, > General Information: > > while releasing maven projects we do generate release metadata for any > project. The generated metadate need to be uploaded to nexus and are located > right beside the build results. > Since we don't want to affect the release build iselfe, the whole metadata > generation runs as a second build after the release build finished. > Now the problem: > > We want to use the deploy plugin to deploy the generated release metadata to > nexus. But the deploy plugin is currently attaching project artifacts and > pom-files automatically to the deployment. But this causes a HTTP-400 Error > at Nexus, since all pom-files and project artifacts have been deployed to > Nexus already. And redeployment is not allowed. > Currently missing: > > It would be cool if the deploy plugin would offer a switch to reduce the > deployment only to those artifacts/files which have been explicitly attached > for deployment in the reactor before. > Attached you do find a small patch. > Regards Matthias -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEPLOY-138) can't upload existing jar+pom as one snapshot artifact
[ https://jira.codehaus.org/browse/MDEPLOY-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MDEPLOY-138. Resolution: Cannot Reproduce > can't upload existing jar+pom as one snapshot artifact > -- > > Key: MDEPLOY-138 > URL: https://jira.codehaus.org/browse/MDEPLOY-138 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.2.1 >Reporter: Olaf Klischat > > There seems to be no way to reliably deploy an existing JAR file plus an > accompanying, existing POM file (created w/ ivy) that contains the JAR file's > metadata and dependencies, to a maven repository. > If I run > mvn deploy:deploy-file -Dfile=mylib.jar DpomFile=mypom.pom > -DgeneratePom=false -Durl= > , Maven 3 apparently just uploads the jar and names it > -.pom (!) > (people on maven-users say that this is probably a bug -- > http://maven.40175.n5.nabble.com/uploading-existing-jar-pom-as-one-artifact-td4577118.html) > Maven 2.2 only uploads the POM -- not what was requested either. > So the problem remains -- how can I reliably deploy and existing jar and pom > as one artifact, with the same timestamp/build number. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-138) can't upload existing jar+pom as one snapshot artifact
[
https://jira.codehaus.org/browse/MDEPLOY-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276653#comment-276653
]
Stephen Connolly commented on MDEPLOY-138:
--
[stephenc@stephenc ~]$ rm -rf tmp
[stephenc@stephenc ~]$ usemvn 2.2.1
[stephenc@stephenc ~]$ mvn
org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy-file
-Dfile=mdeploy-134-poc.jar -DpomFile=pom.xml -DgeneratePom=false
-Durl=file:./tmp/
[INFO] Scanning for projects...
[INFO]
[INFO] Building Unnamed - localdomain.localhost:mdeploy-138-poc:jar:0.1-SNAPSHOT
[INFO]task-segment:
[org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy-file]
(aggregator-style)
[INFO]
[INFO] [deploy:deploy-file {execution: default-cli}]
[INFO] Retrieving previous build number from remote-repository
[INFO] repository metadata for: 'snapshot
localdomain.localhost:mdeploy-138-poc:0.1-SNAPSHOT' could not be found on
repository: remote-repository, so will be created
Uploading:
file:./tmp//localdomain/localhost/mdeploy-138-poc/0.1-SNAPSHOT/mdeploy-138-poc-0.1-20110822.091442-1.jar
141K uploaded (mdeploy-138-poc-0.1-20110822.091442-1.jar)
[INFO] Retrieving previous metadata from remote-repository
[INFO] repository metadata for: 'snapshot
localdomain.localhost:mdeploy-138-poc:0.1-SNAPSHOT' could not be found on
repository: remote-repository, so will be created
[INFO] Uploading repository metadata for: 'snapshot
localdomain.localhost:mdeploy-138-poc:0.1-SNAPSHOT'
[INFO] Retrieving previous metadata from remote-repository
[INFO] repository metadata for: 'artifact
localdomain.localhost:mdeploy-138-poc' could not be found on repository:
remote-repository, so will be created
[INFO] Uploading repository metadata for: 'artifact
localdomain.localhost:mdeploy-138-poc'
[INFO] Uploading project information for mdeploy-138-poc 0.1-20110822.091442-1
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: < 1 second
[INFO] Finished at: Mon Aug 22 10:14:42 IST 2011
[INFO] Final Memory: 4M/81M
[INFO]
[stephenc@stephenc ~]$ find tmp
tmp
tmp/localdomain
tmp/localdomain/localhost
tmp/localdomain/localhost/mdeploy-138-poc
tmp/localdomain/localhost/mdeploy-138-poc/0.1-SNAPSHOT
tmp/localdomain/localhost/mdeploy-138-poc/0.1-SNAPSHOT/maven-metadata.xml
tmp/localdomain/localhost/mdeploy-138-poc/0.1-SNAPSHOT/maven-metadata.xml.md5
tmp/localdomain/localhost/mdeploy-138-poc/0.1-SNAPSHOT/maven-metadata.xml.sha1
tmp/localdomain/localhost/mdeploy-138-poc/0.1-SNAPSHOT/mdeploy-138-poc-0.1-20110822.091442-1.jar
tmp/localdomain/localhost/mdeploy-138-poc/0.1-SNAPSHOT/mdeploy-138-poc-0.1-20110822.091442-1.jar.md5
tmp/localdomain/localhost/mdeploy-138-poc/0.1-SNAPSHOT/mdeploy-138-poc-0.1-20110822.091442-1.jar.sha1
tmp/localdomain/localhost/mdeploy-138-poc/0.1-SNAPSHOT/mdeploy-138-poc-0.1-20110822.091442-1.pom
tmp/localdomain/localhost/mdeploy-138-poc/0.1-SNAPSHOT/mdeploy-138-poc-0.1-20110822.091442-1.pom.md5
tmp/localdomain/localhost/mdeploy-138-poc/0.1-SNAPSHOT/mdeploy-138-poc-0.1-20110822.091442-1.pom.sha1
tmp/localdomain/localhost/mdeploy-138-poc/maven-metadata.xml
tmp/localdomain/localhost/mdeploy-138-poc/maven-metadata.xml.md5
tmp/localdomain/localhost/mdeploy-138-poc/maven-metadata.xml.sha1
[stephenc@stephenc ~]$ rm -rf tmp
[stephenc@stephenc ~]$ usemvn 3.0.3
[stephenc@stephenc ~]$ mvn
org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy-file
-Dfile=mdeploy-134-poc.jar -DpomFile=pom.xml -DgeneratePom=false
-Durl=file:./tmp/
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building mdeploy-138-poc 0.1-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-deploy-plugin:2.6:deploy-file (default-cli) @ mdeploy-138-poc
---
Downloading:
file:./tmp/localdomain/localhost/mdeploy-138-poc/0.1-SNAPSHOT/maven-metadata.xml
Uploading:
file:./tmp/localdomain/localhost/mdeploy-138-poc/0.1-SNAPSHOT/mdeploy-138-poc-0.1-20110822.091520-1.jar
Uploaded:
file:./tmp/localdomain/localhost/mdeploy-138-poc/0.1-SNAPSHOT/mdeploy-138-poc-0.1-20110822.091520-1.jar
(142 KB at 5656.9 KB/sec)
Uploading:
file:./tmp/localdomain/localhost/mdeploy-138-poc/0.1-SNAPSHOT/mdeploy-138-poc-0.1-20110822.091520-1.pom
Uploaded:
file:./tmp/localdomain/localhost/mdeploy-138-poc/0.1-SNAPSHOT/mdeploy-138-poc-0.1-20110822.091520-1.pom
(512 B at 250.0 KB/sec)
Downloading: file:./tmp/localdomain/localhost/mdeploy-138-poc/maven-metadata.xml
Uploading:
file:./tmp/localdo
[jira] Commented: (MSITE-609) site:deploy is broken
[
https://jira.codehaus.org/browse/MSITE-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276654#comment-276654
]
Olivier Lamy commented on MSITE-609:
cause in maven 2.x :
* container.getContainerRealm() -> org.codehaus.classworlds.ClassRealm
* componentConfiguration 3rd param is org.codehaus.classworlds.ClassRealm
in maven3 (new plexus signature non binary compatible) it's
org.codehaus.plexus.classworlds.ClassRealm
So I will add a hack with reflection mechanism.
> site:deploy is broken
> -
>
> Key: MSITE-609
> URL: https://jira.codehaus.org/browse/MSITE-609
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: mvn -version
> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.6.0_22
> Java home: c:\Programme\Java\jdk1.6.0_22\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Christian M.
>Assignee: Olivier Lamy
> Attachments: pom.xml, settings.xml, site_deploy_broken_output.txt
>
>
> With Maven 2.2.1 and the maven-site-plugin 3.0, site:deploy is not working
> anymore. This can be reproduced with the simplest empty project, see attached
> pom.xml
> The error that occurs is:
> java.lang.NoSuchMethodError:
> org.codehaus.plexus.PlexusContainer.getContainerRealm()Lorg/codehaus/plexus/classworlds/realm/ClassRealm;
> (complete stacktrace attached)
> This is in reference to this mail thread:
> http://markmail.org/message/ilfbqb2vhiyo5os4
> Attached are:
> - pom.xml (simple empty project)
> - settings.xml (minimal config necessary for deploy)
> - output from "mvn -X site:deploy" ("mvn site" was run before)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-124) Deploy without build
[ https://jira.codehaus.org/browse/MDEPLOY-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276655#comment-276655 ] Stephen Connolly commented on MDEPLOY-124: -- I'd rather separate goals than a property. That way it is explicit what the user is requesting (two phase versus one phase) a mojo property could be set for one module in a multi-module build and then the user who is use to one phase deploy gets caught off-guard and never does the second phase because they were not watching the build log like a hawk and the build did not fail > Deploy without build > > > Key: MDEPLOY-124 > URL: https://jira.codehaus.org/browse/MDEPLOY-124 > Project: Maven 2.x Deploy Plugin > Issue Type: New Feature >Reporter: Paul Gier > Labels: contributers-welcome > > We have a use case where we would like to run a build (up to the install > phase) and then deploy at a later time. Currently, the deploy plugin > requires that a full build be re-run in order to deploy. Since the build > does not record the list of attached artifacts, the deploy plugin would need > some way to record the list of attached artifacts, and then read them later > for deployment. > Possibly a new goal could be introduced which would create a list of attached > artfiacts. Then the deploy goal could optionally read from this list. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-131) use default repository when no url specified
[ https://jira.codehaus.org/browse/MDEPLOY-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276658#comment-276658 ] Stephen Connolly commented on MDEPLOY-131: -- I am -1 on the currently attached patch for the following reason It mandates that the deploy:deploy-file be run in a directory that has a pom.xml There are a lot of people who use deploy:deploy-file to get their non-maven projects deployed to maven repositories. These people may not have a pom.xml (and while I agree that they _should_ they are currently not required to do so), or they may not call the pom file pom.xml rather someartifact.pom For that reason I am against the currently attached patch. A patch which has test cases and does not require the user to do mvn deploy:deploy-file -Dfile=someartifact.jar -DpomFile=someartifact.pom -f someartifact.pom but instead lets them do mvn deploy:deploy-file -Dfile=someartifact.jar -DpomFile=someartifact.pom rather than the current mvn deploy:deploy-file -Dfile=someartifact.jar -DpomFile=someartifact.pom -Durl=... if someartifact.pom contains the deployment url would seem like a good improvement > use default repository when no url specified > > > Key: MDEPLOY-131 > URL: https://jira.codehaus.org/browse/MDEPLOY-131 > Project: Maven 2.x Deploy Plugin > Issue Type: Improvement > Components: deploy:deploy-file >Reporter: raymond domingo > Labels: contributers-welcome > Attachments: DeployFileMojo.java, patch_deploy_file_mojo.diff > > > When using the deploy goal there is no need to specify the url of the > repository. > When using deploy-file you DO need to specify the url. This is a problem, > because during development I like to deploy to snapshot repository and when > releasing i deploy to release repository and I can't add this logic to the > pom. > Thas is why I like the url paramter to become optional (backwards compatible) > and add default behaviour when it is null. It should just like the deploy > plugin use the default repository. Snapshot for snapshots and release for > none snapshot versions. > I added a patch file fixing this. > I also added complete source of patched Mojo -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-129) Need a way to specify repository credentials securely for deploy operations
[ https://jira.codehaus.org/browse/MDEPLOY-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276659#comment-276659 ] Stephen Connolly commented on MDEPLOY-129: -- Which documentation (incorrecty) states that "Maven doesn't currently support hashed or encrypted passwords in the settings.xml". I'd like to get this closed as it seems purely a documentation issue > Need a way to specify repository credentials securely for deploy operations > --- > > Key: MDEPLOY-129 > URL: https://jira.codehaus.org/browse/MDEPLOY-129 > Project: Maven 2.x Deploy Plugin > Issue Type: New Feature > Components: deploy:deploy-file >Affects Versions: 2.4, 2.5 > Environment: All >Reporter: Rick Herrick > Labels: contributers-welcome, documentation > > Currently, credentials for performing a deployment must be specified in the > settings.xml. However, if a Maven repository is set to use LDAP for its > authentication mechanism, this means exposing domain security credentials in > plaintext in a static file on the hard drive and is _extremely_ insecure (as > specified in the documentation: "Unfortunately, Maven doesn't currently > support hashed or encrypted passwords in the settings.xml"). This is simply > not workable in a secure environment, e.g. government, defense, financial, > etc. > Instead there should be an option to provide these credentials on the command > line or using hash or encryption algorithms. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MDEPLOY-129) Need a way to specify repository credentials securely for deploy operations
[ https://jira.codehaus.org/browse/MDEPLOY-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MDEPLOY-129: - Priority: Minor (was: Major) Labels: contributers-welcome documentation (was: ) Issue Type: Improvement (was: New Feature) > Need a way to specify repository credentials securely for deploy operations > --- > > Key: MDEPLOY-129 > URL: https://jira.codehaus.org/browse/MDEPLOY-129 > Project: Maven 2.x Deploy Plugin > Issue Type: Improvement > Components: deploy:deploy-file >Affects Versions: 2.4, 2.5 > Environment: All >Reporter: Rick Herrick >Priority: Minor > Labels: contributers-welcome, documentation > > Currently, credentials for performing a deployment must be specified in the > settings.xml. However, if a Maven repository is set to use LDAP for its > authentication mechanism, this means exposing domain security credentials in > plaintext in a static file on the hard drive and is _extremely_ insecure (as > specified in the documentation: "Unfortunately, Maven doesn't currently > support hashed or encrypted passwords in the settings.xml"). This is simply > not workable in a secure environment, e.g. government, defense, financial, > etc. > Instead there should be an option to provide these credentials on the command > line or using hash or encryption algorithms. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEPLOY-43) Deploy plugin does not consider artifact type when deploying snapshots
[ https://jira.codehaus.org/browse/MDEPLOY-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MDEPLOY-43. --- Resolution: Duplicate MDEPLOY-137 solves this issue > Deploy plugin does not consider artifact type when deploying snapshots > -- > > Key: MDEPLOY-43 > URL: https://jira.codehaus.org/browse/MDEPLOY-43 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.2.1 > Environment: all environments >Reporter: Brill Pappin >Priority: Critical > > A single artifact with multiple components is not handled properly. > Deploying a single snapshot artifact that has multiple components such as a > native component with an so/dll file and a matching lib file results in two > different id's while only the last id is recorded in the meta data. > Of course, this means that the first file can not be resolve. > The deploy plugin should take the file type into account when deploying the > artifact so that multiple components of an artifact have the same snapshot > id. > To test the issue, use the native-maven-plugin > (http://mojo.codehaus.org/maven-native/native-maven-plugin/index.html) to > deploy an artifact as a snapshot version. > Once deployed inspect the repository; You should find an so/dll and a lib > with two different snapshot ids and the maven-metadata.xml will contain the > id of the last file that was actually copied (in this case the lib file). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-609) site:deploy is broken
[
https://jira.codehaus.org/browse/MSITE-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MSITE-609.
--
Resolution: Fixed
fixed [rev 1160159|http://svn.apache.org/viewvc?rev=1160159&view=rev]
> site:deploy is broken
> -
>
> Key: MSITE-609
> URL: https://jira.codehaus.org/browse/MSITE-609
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: mvn -version
> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.6.0_22
> Java home: c:\Programme\Java\jdk1.6.0_22\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Christian M.
>Assignee: Olivier Lamy
> Attachments: pom.xml, settings.xml, site_deploy_broken_output.txt
>
>
> With Maven 2.2.1 and the maven-site-plugin 3.0, site:deploy is not working
> anymore. This can be reproduced with the simplest empty project, see attached
> pom.xml
> The error that occurs is:
> java.lang.NoSuchMethodError:
> org.codehaus.plexus.PlexusContainer.getContainerRealm()Lorg/codehaus/plexus/classworlds/realm/ClassRealm;
> (complete stacktrace attached)
> This is in reference to this mail thread:
> http://markmail.org/message/ilfbqb2vhiyo5os4
> Attached are:
> - pom.xml (simple empty project)
> - settings.xml (minimal config necessary for deploy)
> - output from "mvn -X site:deploy" ("mvn site" was run before)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEPLOY-127) Mark deploy plugin as @threadSafe for maven3
[ https://jira.codehaus.org/browse/MDEPLOY-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MDEPLOY-127. Resolution: Fixed Fix Version/s: 2.7 Assignee: Stephen Connolly r1160164 > Mark deploy plugin as @threadSafe for maven3 > > > Key: MDEPLOY-127 > URL: https://jira.codehaus.org/browse/MDEPLOY-127 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug > Components: deploy:deploy >Affects Versions: 2.5 > Environment: maven3 on windows os >Reporter: Zeng.haojie >Assignee: Stephen Connolly > Fix For: 2.7 > > > The deploy plugin is threadSafe and needs to be marked. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-118) Enable deployment of attached release artifacts if POM is identical
[ https://jira.codehaus.org/browse/MDEPLOY-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276663#comment-276663 ] Stephen Connolly commented on MDEPLOY-118: -- Could use the .MD5 and .SHA1 side artifacts to check if the artifact is the same > Enable deployment of attached release artifacts if POM is identical > --- > > Key: MDEPLOY-118 > URL: https://jira.codehaus.org/browse/MDEPLOY-118 > Project: Maven 2.x Deploy Plugin > Issue Type: Improvement >Affects Versions: 2.4 > Environment: Windows XP SP3 >Reporter: Bruno F > Labels: contributers-welcome > > In the context of the build of a native application, one might have > zip-artifacts containing several DLL or so files like: > boost:boost_regex:1.34.1:zip > In order to distinguish between platforms, it seems to be recommended to use > the classifier: > boost:boost_regex:1.34.1:zip:bin-x86-windows-vc8 > or: > boost:boost_regex:1.34.1:zip:bin-x86-linux2.6-gcc3.3 > If a Maven repository manager is configured to prevent from re-deploying > release artifacts (and I believe it should be), it is not possible to deploy > attached artifacts when the POM is the same because the POM is deployed > twice. The deploy plugin could check that the POM is already deployed and is > the same than the local one (modulo platform-dependent line-break concerns, > and that's important!), then choose not to deploy it but only the attached > artifact. > In the example above, it could enable to deploy the > boost:boost_regex:1.34.1:zip:bin-x86-windows-vc8 artifact from a Windows > machine(coming along with a boost:boost_regex:1.34.1:pom artifact), then to > deploy the boost:boost_regex:1.34.1:zip:bin-x86-linux2.6-gcc3.3 artifact from > a Linux machine (coming along with the same boost:boost_regex:1.34.1:pom > artifact, that will not be deployed since it is identical to the first one > deployed). > Maybe this could be generalized to any kind of artifact? If the artifact to > deploy is the same, the plugin should not fail and simply skip the deployment > of that artifact? > I post that bug here on a suggestion of Brett Porter (see the MRM-1357 bug) > since it is quite unclear to me whether it is a MRM or deploy plugin concern. > That bug might also be related to: > - MDEPLOY-117 > - MDEPLOY-114 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEPLOY-46) "mvn -DaltDeploymentRepository=... deploy" of a SNAPSHOT doesn't replace date.buildnumber
[ https://jira.codehaus.org/browse/MDEPLOY-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MDEPLOY-46. --- Resolution: Fixed Fix Version/s: 2.5 Marking as closed as the code contains the fix and this is also not an issue if using Maven 3 (as a side effect of Maven 3 dropping support for uniqueVersion=false) > "mvn -DaltDeploymentRepository=... deploy" of a SNAPSHOT doesn't replace > date.buildnumber > -- > > Key: MDEPLOY-46 > URL: https://jira.codehaus.org/browse/MDEPLOY-46 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Geoffrey De Smet > Fix For: 2.5 > > Attachments: MDEPLOY-46.patch > > > I 've checkouted a m2 project (spring-richclient) and deployed it to my local > repo using the altDeploymentRepository parameter (from MDEPLOY-41). > But the checkout is a SNAPSHOT version and the deployer should replace it > with something like spring-richclient-core-0.3.0-20070101.160450-2.jar > like the mvn deploy without altDeploymentRepository does, > but it doesn't: > [INFO] [deploy:deploy] > altDeploymentRepository = ggg-dev::default::scp://mvn.ggg.be/maven/maven2/dev > [INFO] Using alternate deployment repository > ggg-dev::default::scp://mvn.ggg.be/maven/maven2/dev > [INFO] Retrieving previous build number from ggg-dev > Uploading: > scp://mvn.ggg.be/maven/maven2/dev/org/springframework/richclient/spring-richclient-core/0.3.0-SNAPSHOT/spring-richclient-core-0.3.0-SNAPSHOT.jar > 50K uploaded -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHECKSTYLE-144) If 'src/main/java' does not exist in a project then checkstyle skips the other source folders of the project
[ https://jira.codehaus.org/browse/MCHECKSTYLE-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=27#comment-27 ] Sei Syvalta commented on MCHECKSTYLE-144: - > "Failed during checkstyle configuration: missing key 'cacheFile' in TreeWalker See http://jira.codehaus.org/browse/MCHECKSTYLE-159 > If 'src/main/java' does not exist in a project then checkstyle skips the > other source folders of the project > > > Key: MCHECKSTYLE-144 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-144 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Ulli Hafner > > I'm not sure whether this is related to MCHECKSTYLE-141. > If I check a test-project that contains only a folder src/test/java but not a > folder src/main/java (even thoud the includeTestDir option is set) then > checkstyle ignores the whole project: > [INFO] --- maven-checkstyle-plugin:2.5:checkstyle (default-cli) @ > de.faktorlogik.core.tests --- > [INFO] Source directory does not exist - skipping report. > [INFO] > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEPLOY-61) Artifact's getRepository() value used when deploying attached artifacts
[ https://jira.codehaus.org/browse/MDEPLOY-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MDEPLOY-61. --- Resolution: Won't Fix MNG-3151 is won't fix so no point in fixing an issue when there is no support for the use case that it depends on > Artifact's getRepository() value used when deploying attached artifacts > --- > > Key: MDEPLOY-61 > URL: https://jira.codehaus.org/browse/MDEPLOY-61 > Project: Maven 2.x Deploy Plugin > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: James William Dumay > Attachments: maven-deploy-plugin.patch, maven-deploy-plugin.patch, > maven-javadoc-plugin.patch > > > On the execute of the Deploy mojo, attached artifacts that specify an > ArtifactRepository via Artifact::getRepository() will be used for the > deployment of that artifact. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-609) site:deploy is broken
[
https://jira.codehaus.org/browse/MSITE-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl updated MSITE-609:
Fix Version/s: 3.1
> site:deploy is broken
> -
>
> Key: MSITE-609
> URL: https://jira.codehaus.org/browse/MSITE-609
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: mvn -version
> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.6.0_22
> Java home: c:\Programme\Java\jdk1.6.0_22\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Christian M.
>Assignee: Olivier Lamy
> Fix For: 3.1
>
> Attachments: pom.xml, settings.xml, site_deploy_broken_output.txt
>
>
> With Maven 2.2.1 and the maven-site-plugin 3.0, site:deploy is not working
> anymore. This can be reproduced with the simplest empty project, see attached
> pom.xml
> The error that occurs is:
> java.lang.NoSuchMethodError:
> org.codehaus.plexus.PlexusContainer.getContainerRealm()Lorg/codehaus/plexus/classworlds/realm/ClassRealm;
> (complete stacktrace attached)
> This is in reference to this mail thread:
> http://markmail.org/message/ilfbqb2vhiyo5os4
> Attached are:
> - pom.xml (simple empty project)
> - settings.xml (minimal config necessary for deploy)
> - output from "mvn -X site:deploy" ("mvn site" was run before)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-116) uniqueVersion=false does not update SNAPSHOT child module maven-metadata.xml correctly
[ https://jira.codehaus.org/browse/MDEPLOY-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276668#comment-276668 ] Stephen Connolly commented on MDEPLOY-116: -- Given that Maven 3 no longer supports uniqueVersion=false I am not sure that this issue is relevant any more > uniqueVersion=false does not update SNAPSHOT child module maven-metadata.xml > correctly > -- > > Key: MDEPLOY-116 > URL: https://jira.codehaus.org/browse/MDEPLOY-116 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug > Components: deploy:deploy > Environment: Maven 2.2.1. maven deploy plugin version not specified > in pom.xml. >Reporter: Bob Fields > Labels: scrub-review-started > > Parent pom.xml has > > > andromda-repository > AndroMDA Repository > file:/var/www/maven2 > > Child pom.xml files do not specify distribution repository. Parent and child > artifacts were deployed with maven-metadata.xml containing > information. Later, false was added. The > parent maven-metadata.xml was updated correctly (no ) but the > child maven-metadata.xml had changed in the > section, rather than simply deleting the section entirely, resulting in an > old timestamped version of the .pom file returned to the repository user. The > only workaround was to delete all of the project child artifacts in the > repository and deploy again. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5162) Maven stuck on downloading dependencies when using java 7.
Maven stuck on downloading dependencies when using java 7. -- Key: MNG-5162 URL: https://jira.codehaus.org/browse/MNG-5162 Project: Maven 2 & 3 Issue Type: Bug Components: Dependencies Affects Versions: 3.0.3, 3.0.1 Environment: Windows 7 Professional x64 Reporter: Lukas Stampf Attachments: edb.zip, java6.jpg, java7.jpg When JAVA_HOME is set to the Java 7 JDK and I run "mvn clean install" on my project the following happens: Maven downloads the dependencies to my local repository, as usual, but on some dependencies he stops while downloading and never continues. He is just stuck. I then must use CTRL+C and start from the beginning with my build, but it doesnt help because he gets stuck at the same dependencies again. In my local repository, where the failed dependency belongs is just a tmp file like: org.apache.servicemix.bundles.serp-1.13.1_4.jar.tmp90088a9d7e9e4642 When I set JAVA_HOME to java 6 Update 27 everything works fine. The problem does not seem to be related to JAR size because, I saw it fail on 19kb dependencies as well. I have the impression it happens mostly to JARs with "long" names. Attached you will find a subproject of the project I am working on. it contains the org.apache.servicemix.bundles.serp-1.13.1_4 dependency, which is one of almost all servicemix bundles that is failing for me, when i use java7. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MDEP-173) Support 'includes' in purge-local-repository
[ https://jira.codehaus.org/browse/MDEP-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Cazottes updated MDEP-173: -- Attachment: delta-MDEP-173.zip Addition of sources changes in order to correct this issue. The zip contains the files modified after getting the sources from the 2.3 version of the plugin. The zip contains the java code of the PurgeLocalRepositoryMojo and an example on how to use it. > Support 'includes' in purge-local-repository > > > Key: MDEP-173 > URL: https://jira.codehaus.org/browse/MDEP-173 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: purge-local-repository >Affects Versions: 2.0 >Reporter: Dan Tran >Assignee: Brian Fox > Attachments: delta-MDEP-173.zip > > > The current configuration only supports excludes, which can be very > cumbersome since I only need to purge on single artifact among a long list of > dependencies. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-173) Support 'includes' in purge-local-repository
[ https://jira.codehaus.org/browse/MDEP-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276673#comment-276673 ] Nicolas Cazottes commented on MDEP-173: --- Hi, I resolved this issue by updating the PurgeLocalRepositoryMojo. The implementation is quite simple and in the same way of usage as the excludes configuration. Could you integrate it in a future version of the plugin please. Thanks. > Support 'includes' in purge-local-repository > > > Key: MDEP-173 > URL: https://jira.codehaus.org/browse/MDEP-173 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: purge-local-repository >Affects Versions: 2.0 >Reporter: Dan Tran >Assignee: Brian Fox > Attachments: delta-MDEP-173.zip > > > The current configuration only supports excludes, which can be very > cumbersome since I only need to purge on single artifact among a long list of > dependencies. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5162) Maven stuck on downloading dependencies when using java 7.
[ https://jira.codehaus.org/browse/MNG-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276674#comment-276674 ] Benjamin Bentmann commented on MNG-5162: A thread dump, e.g. taking via jvisualvm, when the process gets stuck, would be helpful. > Maven stuck on downloading dependencies when using java 7. > -- > > Key: MNG-5162 > URL: https://jira.codehaus.org/browse/MNG-5162 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.1, 3.0.3 > Environment: Windows 7 Professional x64 >Reporter: Lukas Stampf > Attachments: edb.zip, java6.jpg, java7.jpg > > > When JAVA_HOME is set to the Java 7 JDK and I run "mvn clean install" on my > project the following happens: > Maven downloads the dependencies to my local repository, as usual, but on > some dependencies he stops while downloading and never continues. He is just > stuck. I then must use CTRL+C and start from the beginning with my build, but > it doesnt help because he gets stuck at the same dependencies again. In my > local repository, where the failed dependency belongs is just a tmp file > like: org.apache.servicemix.bundles.serp-1.13.1_4.jar.tmp90088a9d7e9e4642 > When I set JAVA_HOME to java 6 Update 27 everything works fine. > The problem does not seem to be related to JAR size because, I saw it fail on > 19kb dependencies as well. > I have the impression it happens mostly to JARs with "long" names. > Attached you will find a subproject of the project I am working on. it > contains the org.apache.servicemix.bundles.serp-1.13.1_4 dependency, which is > one of almost all servicemix bundles that is failing for me, when i use java7. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-556) mvn assembly:assembly NPEs with install:install-file'd artifacts
[
https://jira.codehaus.org/browse/MASSEMBLY-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Ellis updated MASSEMBLY-556:
---
Attachment: massembly-556.tar.gz
I've been able to reproduce this bug. It seems to be caused by having a mirror
defined in the settings.
See the attached project for an example.
Running with no mirror defined works correctly:
mvn package -s empty-settings.xml
... however, running with a mirror defined will fail:
mvn package -s mirror-settings.xml
My example settings use repo1.maven.org as the mirror, but I get the same
behaviour with uk.maven.org, and with the url of our repository manager.
> mvn assembly:assembly NPEs with install:install-file'd artifacts
>
>
> Key: MASSEMBLY-556
> URL: https://jira.codehaus.org/browse/MASSEMBLY-556
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-5
> Environment: Maven 3.0.3 (r1075438; 2011-02-28 17:31:09+) on Win
> 7 x64, Sun Java 6u24 x64.
>Reporter: Chris West (Faux)
>Assignee: John Casey
> Fix For: 2.3
>
> Attachments: build.log, massembly-556.tar.gz, pom.xml, repository.xml
>
>
> I have 3rd-party jars installed via. {{mvn install:install-file}}. This
> causes {{mvn assembly:assembly}} to NPE around:
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.getLocalFilename(AbstractRepositoryMetadata.java:61)
> at
> org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOfLocalRepositoryMetadata(DefaultRepositoryLayout.java:72)
> ...
> {code}
> To reproduce, first, install:install-file a random file:
> {code}
> mvn install:install-file -Dfile=pom.xml -DgroupId=com.goeswhere.test
> -DartifactId=a -Dversion=0 -Dpackaging=jar
> {code}
> Then, create pom.xml (attached):
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> com.goeswhere.test
> b
> 1.0-SNAPSHOT
> jar
>
>
> com.goeswhere.test
> a
> 0
>
>
>
>
>
> maven-assembly-plugin
>
>
>
> ./repository.xml
>
>
>
>
>
>
> {code}
> and repository.xml (attached):
> {code:xml}
>
> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
> http://maven.apache.org/xsd/assembly-1.1.2.xsd";>
> repository
>
> jar
>
>
>
> true
> maven2
>
>
>
> {code}
> And run {{mvn assembly:assembly}}. See attached build.log.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-556) mvn assembly:assembly NPEs with install:install-file'd artifacts
[
https://jira.codehaus.org/browse/MASSEMBLY-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276677#comment-276677
]
Martin Ellis commented on MASSEMBLY-556:
My user settings are based on the settings described here:
http://www.sonatype.com/books/nexus-book/reference/maven-sect-single-group.html
As a workaround, I've managed to build our project with the following settings
file (note that 'nexus' resolves to our local Nexus instance):
{code:xml}
no-mirrors
true
nexus
default
http://nexus/content/groups/public
true
nexus
http://nexus/content/groups/public
default
true
{code}
> mvn assembly:assembly NPEs with install:install-file'd artifacts
>
>
> Key: MASSEMBLY-556
> URL: https://jira.codehaus.org/browse/MASSEMBLY-556
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-5
> Environment: Maven 3.0.3 (r1075438; 2011-02-28 17:31:09+) on Win
> 7 x64, Sun Java 6u24 x64.
>Reporter: Chris West (Faux)
>Assignee: John Casey
> Fix For: 2.3
>
> Attachments: build.log, massembly-556.tar.gz, pom.xml, repository.xml
>
>
> I have 3rd-party jars installed via. {{mvn install:install-file}}. This
> causes {{mvn assembly:assembly}} to NPE around:
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.getLocalFilename(AbstractRepositoryMetadata.java:61)
> at
> org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOfLocalRepositoryMetadata(DefaultRepositoryLayout.java:72)
> ...
> {code}
> To reproduce, first, install:install-file a random file:
> {code}
> mvn install:install-file -Dfile=pom.xml -DgroupId=com.goeswhere.test
> -DartifactId=a -Dversion=0 -Dpackaging=jar
> {code}
> Then, create pom.xml (attached):
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> com.goeswhere.test
> b
> 1.0-SNAPSHOT
> jar
>
>
> com.goeswhere.test
> a
> 0
>
>
>
>
>
> maven-assembly-plugin
>
>
>
> ./repository.xml
>
>
>
>
>
>
> {code}
> and repository.xml (attached):
> {code:xml}
>
> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
> http://maven.apache.org/xsd/assembly-1.1.2.xsd";>
> repository
>
> jar
>
>
>
> true
> maven2
>
>
>
> {code}
> And run {{mvn assembly:assembly}}. See attached build.log.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-556) mvn assembly:assembly NPEs with install:install-file'd artifacts
[
https://jira.codehaus.org/browse/MASSEMBLY-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Ellis updated MASSEMBLY-556:
---
Attachment: massembly-556-2.tar.gz
Attaching massembly-556-2.tar.gz because I managed to compress the first
archive twice.
Also: this issue doesn't seem to be specific to artifacts installed with
install:install-file. (The project I've attached uses junit).
The issue title should probably be updated accordingly.
> mvn assembly:assembly NPEs with install:install-file'd artifacts
>
>
> Key: MASSEMBLY-556
> URL: https://jira.codehaus.org/browse/MASSEMBLY-556
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-5
> Environment: Maven 3.0.3 (r1075438; 2011-02-28 17:31:09+) on Win
> 7 x64, Sun Java 6u24 x64.
>Reporter: Chris West (Faux)
>Assignee: John Casey
> Fix For: 2.3
>
> Attachments: build.log, massembly-556-2.tar.gz, massembly-556.tar.gz,
> pom.xml, repository.xml
>
>
> I have 3rd-party jars installed via. {{mvn install:install-file}}. This
> causes {{mvn assembly:assembly}} to NPE around:
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.getLocalFilename(AbstractRepositoryMetadata.java:61)
> at
> org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOfLocalRepositoryMetadata(DefaultRepositoryLayout.java:72)
> ...
> {code}
> To reproduce, first, install:install-file a random file:
> {code}
> mvn install:install-file -Dfile=pom.xml -DgroupId=com.goeswhere.test
> -DartifactId=a -Dversion=0 -Dpackaging=jar
> {code}
> Then, create pom.xml (attached):
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> com.goeswhere.test
> b
> 1.0-SNAPSHOT
> jar
>
>
> com.goeswhere.test
> a
> 0
>
>
>
>
>
> maven-assembly-plugin
>
>
>
> ./repository.xml
>
>
>
>
>
>
> {code}
> and repository.xml (attached):
> {code:xml}
>
> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
> http://maven.apache.org/xsd/assembly-1.1.2.xsd";>
> repository
>
> jar
>
>
>
> true
> maven2
>
>
>
> {code}
> And run {{mvn assembly:assembly}}. See attached build.log.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINDEXER-36) Add some OSGI metadata in the index to be able to search on
[ https://jira.codehaus.org/browse/MINDEXER-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276680#comment-276680 ] Olivier Lamy commented on MINDEXER-36: -- I will move OSGIArtifactIndexCreator to OsgiArtifactIndexCreator > Add some OSGI metadata in the index to be able to search on > --- > > Key: MINDEXER-36 > URL: https://jira.codehaus.org/browse/MINDEXER-36 > Project: Maven Indexer > Issue Type: New Feature >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 4.1.2 > > > Index at least : > * Bundle-SymbolicName > * Bundle-Version > * Export-Package > * Export-Service > Others OSGI metadata ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MINDEXER-36) Add some OSGI metadata in the index to be able to search on
[ https://jira.codehaus.org/browse/MINDEXER-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MINDEXER-36. Resolution: Fixed fixed > Add some OSGI metadata in the index to be able to search on > --- > > Key: MINDEXER-36 > URL: https://jira.codehaus.org/browse/MINDEXER-36 > Project: Maven Indexer > Issue Type: New Feature >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 4.1.2 > > > Index at least : > * Bundle-SymbolicName > * Bundle-Version > * Export-Package > * Export-Service > Others OSGI metadata ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-43) Deploy plugin does not consider artifact type when deploying snapshots
[ https://jira.codehaus.org/browse/MDEPLOY-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276683#comment-276683 ] Brill Pappin commented on MDEPLOY-43: - Closed as a duplicate, but a duplicate of which issue? Please include the link to the primary issue being worked on, or I'll simply reopen this issue. > Deploy plugin does not consider artifact type when deploying snapshots > -- > > Key: MDEPLOY-43 > URL: https://jira.codehaus.org/browse/MDEPLOY-43 > Project: Maven 2.x and 3.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.2.1 > Environment: all environments >Reporter: Brill Pappin >Priority: Critical > > A single artifact with multiple components is not handled properly. > Deploying a single snapshot artifact that has multiple components such as a > native component with an so/dll file and a matching lib file results in two > different id's while only the last id is recorded in the meta data. > Of course, this means that the first file can not be resolve. > The deploy plugin should take the file type into account when deploying the > artifact so that multiple components of an artifact have the same snapshot > id. > To test the issue, use the native-maven-plugin > (http://mojo.codehaus.org/maven-native/native-maven-plugin/index.html) to > deploy an artifact as a snapshot version. > Once deployed inspect the repository; You should find an so/dll and a lib > with two different snapshot ids and the maven-metadata.xml will contain the > id of the last file that was actually copied (in this case the lib file). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-124) Deploy without build
[ https://jira.codehaus.org/browse/MDEPLOY-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276687#comment-276687 ] Paul Gier commented on MDEPLOY-124: --- I agree it should be a separate goal, however it also needs some way to determine which files to deploy. My previous suggestion was to add property to the existing deploy go which only creates a list of files to deploy instead of actually deploying them. Then the second goal reads the list and deploys the files. Another option is to just manually configure the list of files to deploy in the plugin. > Deploy without build > > > Key: MDEPLOY-124 > URL: https://jira.codehaus.org/browse/MDEPLOY-124 > Project: Maven 2.x and 3.x Deploy Plugin > Issue Type: New Feature >Reporter: Paul Gier > Labels: contributers-welcome > > We have a use case where we would like to run a build (up to the install > phase) and then deploy at a later time. Currently, the deploy plugin > requires that a full build be re-run in order to deploy. Since the build > does not record the list of attached artifacts, the deploy plugin would need > some way to record the list of attached artifacts, and then read them later > for deployment. > Possibly a new goal could be introduced which would create a list of attached > artfiacts. Then the deploy goal could optionally read from this list. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MDEPLOY-124) Deploy without build
[ https://jira.codehaus.org/browse/MDEPLOY-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276687#comment-276687 ] Paul Gier edited comment on MDEPLOY-124 at 8/22/11 9:26 AM: I agree it should be a separate goal, however it also needs some way to determine which files to deploy. My previous suggestion was to add property to the existing deploy go which only creates a list of files to deploy instead of actually deploying them. Then the second goal reads the list and deploys the files. Another option is to just manually configure the list of files to deploy in the plugin. Maybe this could be done as an enhancement to the existing deploy-file goal. was (Author: pgier): I agree it should be a separate goal, however it also needs some way to determine which files to deploy. My previous suggestion was to add property to the existing deploy go which only creates a list of files to deploy instead of actually deploying them. Then the second goal reads the list and deploys the files. Another option is to just manually configure the list of files to deploy in the plugin. > Deploy without build > > > Key: MDEPLOY-124 > URL: https://jira.codehaus.org/browse/MDEPLOY-124 > Project: Maven 2.x and 3.x Deploy Plugin > Issue Type: New Feature >Reporter: Paul Gier > Labels: contributers-welcome > > We have a use case where we would like to run a build (up to the install > phase) and then deploy at a later time. Currently, the deploy plugin > requires that a full build be re-run in order to deploy. Since the build > does not record the list of attached artifacts, the deploy plugin would need > some way to record the list of attached artifacts, and then read them later > for deployment. > Possibly a new goal could be introduced which would create a list of attached > artfiacts. Then the deploy goal could optionally read from this list. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-5162) Maven stuck on downloading dependencies when using java 7.
[ https://jira.codehaus.org/browse/MNG-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276690#comment-276690 ] Lukas Stampf edited comment on MNG-5162 at 8/22/11 10:05 AM: - dump taken when stuck added was (Author: l.stampf): dump taken when stuck > Maven stuck on downloading dependencies when using java 7. > -- > > Key: MNG-5162 > URL: https://jira.codehaus.org/browse/MNG-5162 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.1, 3.0.3 > Environment: Windows 7 Professional x64 >Reporter: Lukas Stampf > Attachments: dump.tdump, edb.zip, java6.jpg, java7.jpg > > > When JAVA_HOME is set to the Java 7 JDK and I run "mvn clean install" on my > project the following happens: > Maven downloads the dependencies to my local repository, as usual, but on > some dependencies he stops while downloading and never continues. He is just > stuck. I then must use CTRL+C and start from the beginning with my build, but > it doesnt help because he gets stuck at the same dependencies again. In my > local repository, where the failed dependency belongs is just a tmp file > like: org.apache.servicemix.bundles.serp-1.13.1_4.jar.tmp90088a9d7e9e4642 > When I set JAVA_HOME to java 6 Update 27 everything works fine. > The problem does not seem to be related to JAR size because, I saw it fail on > 19kb dependencies as well. > I have the impression it happens mostly to JARs with "long" names. > Attached you will find a subproject of the project I am working on. it > contains the org.apache.servicemix.bundles.serp-1.13.1_4 dependency, which is > one of almost all servicemix bundles that is failing for me, when i use java7. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-5162) Maven stuck on downloading dependencies when using java 7.
[ https://jira.codehaus.org/browse/MNG-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Stampf updated MNG-5162: -- Attachment: dump.tdump dump taken when stuck > Maven stuck on downloading dependencies when using java 7. > -- > > Key: MNG-5162 > URL: https://jira.codehaus.org/browse/MNG-5162 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.1, 3.0.3 > Environment: Windows 7 Professional x64 >Reporter: Lukas Stampf > Attachments: dump.tdump, edb.zip, java6.jpg, java7.jpg > > > When JAVA_HOME is set to the Java 7 JDK and I run "mvn clean install" on my > project the following happens: > Maven downloads the dependencies to my local repository, as usual, but on > some dependencies he stops while downloading and never continues. He is just > stuck. I then must use CTRL+C and start from the beginning with my build, but > it doesnt help because he gets stuck at the same dependencies again. In my > local repository, where the failed dependency belongs is just a tmp file > like: org.apache.servicemix.bundles.serp-1.13.1_4.jar.tmp90088a9d7e9e4642 > When I set JAVA_HOME to java 6 Update 27 everything works fine. > The problem does not seem to be related to JAR size because, I saw it fail on > 19kb dependencies as well. > I have the impression it happens mostly to JARs with "long" names. > Attached you will find a subproject of the project I am working on. it > contains the org.apache.servicemix.bundles.serp-1.13.1_4 dependency, which is > one of almost all servicemix bundles that is failing for me, when i use java7. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5162) Maven stuck on downloading dependencies when using java 7.
[
https://jira.codehaus.org/browse/MNG-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276693#comment-276693
]
Benjamin Bentmann commented on MNG-5162:
According to that thread dump, the main thread just is waiting for the download
to finish (pool-1-thread-1). How long exactly did you wait for it to finish
before you aborted it? The default request timeout is 60s, so I'm curious
whether the transfer eventually fails with a timeout error after that period.
If indeed the download itself gets stuck, you might need to bug Oracle about
that issue in their HTTP client code. On the Maven side, the only option
appears to be using a different wagon impl, e.g. by declaring
{{org.apache.maven.wagon:wagon-http:1.0}} as a build extension.
> Maven stuck on downloading dependencies when using java 7.
> --
>
> Key: MNG-5162
> URL: https://jira.codehaus.org/browse/MNG-5162
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.1, 3.0.3
> Environment: Windows 7 Professional x64
>Reporter: Lukas Stampf
> Attachments: dump.tdump, edb.zip, java6.jpg, java7.jpg
>
>
> When JAVA_HOME is set to the Java 7 JDK and I run "mvn clean install" on my
> project the following happens:
> Maven downloads the dependencies to my local repository, as usual, but on
> some dependencies he stops while downloading and never continues. He is just
> stuck. I then must use CTRL+C and start from the beginning with my build, but
> it doesnt help because he gets stuck at the same dependencies again. In my
> local repository, where the failed dependency belongs is just a tmp file
> like: org.apache.servicemix.bundles.serp-1.13.1_4.jar.tmp90088a9d7e9e4642
> When I set JAVA_HOME to java 6 Update 27 everything works fine.
> The problem does not seem to be related to JAR size because, I saw it fail on
> 19kb dependencies as well.
> I have the impression it happens mostly to JARs with "long" names.
> Attached you will find a subproject of the project I am working on. it
> contains the org.apache.servicemix.bundles.serp-1.13.1_4 dependency, which is
> one of almost all servicemix bundles that is failing for me, when i use java7.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5162) Maven stuck on downloading dependencies when using java 7.
[ https://jira.codehaus.org/browse/MNG-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276694#comment-276694 ] Lukas Stampf commented on MNG-5162: --- just tested again for exactly 10 minutes. No changes still stuck. > Maven stuck on downloading dependencies when using java 7. > -- > > Key: MNG-5162 > URL: https://jira.codehaus.org/browse/MNG-5162 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.1, 3.0.3 > Environment: Windows 7 Professional x64 >Reporter: Lukas Stampf > Attachments: dump.tdump, edb.zip, java6.jpg, java7.jpg > > > When JAVA_HOME is set to the Java 7 JDK and I run "mvn clean install" on my > project the following happens: > Maven downloads the dependencies to my local repository, as usual, but on > some dependencies he stops while downloading and never continues. He is just > stuck. I then must use CTRL+C and start from the beginning with my build, but > it doesnt help because he gets stuck at the same dependencies again. In my > local repository, where the failed dependency belongs is just a tmp file > like: org.apache.servicemix.bundles.serp-1.13.1_4.jar.tmp90088a9d7e9e4642 > When I set JAVA_HOME to java 6 Update 27 everything works fine. > The problem does not seem to be related to JAR size because, I saw it fail on > 19kb dependencies as well. > I have the impression it happens mostly to JARs with "long" names. > Attached you will find a subproject of the project I am working on. it > contains the org.apache.servicemix.bundles.serp-1.13.1_4 dependency, which is > one of almost all servicemix bundles that is failing for me, when i use java7. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEPLOY-139) deploy:deploy-file does not work with encrypted passwords when deploying to a Nexus repository
deploy:deploy-file does not work with encrypted passwords when deploying to a Nexus repository -- Key: MDEPLOY-139 URL: https://jira.codehaus.org/browse/MDEPLOY-139 Project: Maven 2.x and 3.x Deploy Plugin Issue Type: Bug Components: deploy:deploy-file Affects Versions: 2.6 Environment: Windows XP Reporter: Julian Payne When I use an encrypted password in my settings.xml that deploy-file fails with error code 401 when I deploy to a Nexus repository (Nexus 1.8.0). If I put the plain text password in my settings.xml file then it works fine. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (WAGON-346) LightWeight http wagon not thread-safe
LightWeight http wagon not thread-safe -- Key: WAGON-346 URL: https://jira.codehaus.org/browse/WAGON-346 Project: Maven Wagon Issue Type: Bug Components: wagon-http-lightweight Affects Versions: 1.0 Environment: maven 3 with Aether Reporter: nicolas de loof Aether (maven3) by default parallelized metadata resolution on 4 threads (aether.metadataResolver.threads) and artifacts downloading on 5 (maven.artifact.threads). In such context, Wagon is not used sequentially. LightWeightHttpWagon is designed for mono-thread, sequential usage. It rely on system properties and on setting/resetting java.net.Authenticator singleton. The result is that, in some cases (typically : when settings defines many repositories with various credentials), credentials may not apply and download will fail A potential fix is - to use Java5 URL.openConnection(Proxy) instead of using system properties - to use a shared, singleton java.net.Authenticator that lookup repositories to match the requested URL -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (WAGON-347) Support preemtive authentication
Support preemtive authentication Key: WAGON-347 URL: https://jira.codehaus.org/browse/WAGON-347 Project: Maven Wagon Issue Type: Improvement Components: wagon-http-lightweight Reporter: nicolas de loof Priority: Minor Set Authorization header on HttpUrlConnection to get preemptive authentication and avoid unnecessary network traffic -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-47) Timeout during SCP upload
[ https://jira.codehaus.org/browse/MDEPLOY-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276697#comment-276697 ] Dennis Kieselhorst commented on MDEPLOY-47: --- I'm unable to verify it at the moment, maybe one of the other watchers can? > Timeout during SCP upload > - > > Key: MDEPLOY-47 > URL: https://jira.codehaus.org/browse/MDEPLOY-47 > Project: Maven 2.x and 3.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Windows XP, Java 1.5, Maven 2.0.4 >Reporter: Dennis Kieselhorst > Labels: scrub-review-started > > It seems that there is a timeout during the upload. Unfortunately the > deploy-plugin doesn't detect it. I have to close the console and kill the > java process in the task manager. > Uploading: > scp://mydevserver/opt/www/htdocs/maven2/de/dekies/test/test-client/2.8.27rc2/test-client-2.8.27rc2.jar > 4/20K > 8/20K > 12/20K > 16/20K > 20/20K > 20/20K > 20K uploaded > [INFO] Retrieving previous metadata from dekies > [INFO] Uploading repository metadata for: 'artifact > de.dekies.test:test-client' > [INFO] Retrieving previous metadata from dekies > [INFO] Uploading project information for test-client 2.8.27rc2 > --> nothing happens after this (for hours)! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-366) Maven mirror consulted after, rather than instead of, archetypeRepository URL
[
https://jira.codehaus.org/browse/ARCHETYPE-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276700#comment-276700
]
Jesse Glick commented on ARCHETYPE-366:
---
I would really like to see a fix for this before 2.1 is released, if you think
there is enough time to test it before that. Would you consider a patch with a
new {{archetypeRepositoryId}} parameter or something like this?
> Maven mirror consulted after, rather than instead of, archetypeRepository URL
> -
>
> Key: ARCHETYPE-366
> URL: https://jira.codehaus.org/browse/ARCHETYPE-366
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
>Affects Versions: 2.0
> Environment: Ubuntu 10.04, JDK 6.
>Reporter: Jesse Glick
>Priority: Minor
> Attachments: ARCHETYPE-366.diff
>
>
> I have a local Nexus instance running, with a mirror of Central, and in
> {{settings.xml}}:
> {noformat}
>
> central
> central
> .../content/repositories/central/
>
> {noformat}
> This works fine for normal Maven operations. However, {{archetype:generate}}
> tries to download from the public repo _first_. So when I am online, after
> typing this:
> {noformat}
> rm -rf ~/.m2/repository/org/codehaus/mojo/archetypes test
> mvn -DarchetypeVersion=1.2 -Darchetype.interactive=false -DgroupId=test
> -DarchetypeArtifactId=osgi-archetype
> -DarchetypeRepository=http://repo1.maven.org/maven2/ -Dversion=1.0-SNAPSHOT
> -DarchetypeGroupId=org.codehaus.mojo.archetypes -Dbasedir=/tmp -Dpackage=test
> -DartifactId=test --batch-mode archetype:generate
> {noformat}
> I see:
> {noformat}
> [INFO] Archetype defined by properties
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> Downloaded:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> (4 KB at 8.7 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> (947 B at 8.3 KB/sec)
> {noformat}
> with no mention of Nexus; when I am offline:
> {noformat}
> [INFO] Archetype defined by properties
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> Downloading:
> http://localhost:6969/nexus/content/repositories/central/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> Downloaded:
> http://localhost:6969/nexus/content/repositories/central/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> (4 KB at 128.8 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> Downloading:
> http://localhost:6969/nexus/content/repositories/central/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> Downloaded:
> http://localhost:6969/nexus/content/repositories/central/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> (947 B at 57.8 KB/sec)
> {noformat}
> once this resource is cached in the Nexus mirror repo. (Since the online
> command does not ask Nexus, it normally is _not_ cached there and offline
> project creation simply fails; to force Nexus to cache it, I need to ask
> Maven to download it as a dep of something.)
> If I do not specify an explicit {{archetypeRepository}} then I get
> {noformat}
> [INFO] Archetype repository missing. Using the one from
> [org.codehaus.mojo.archetypes:osgi-archetype:1.2] found in catalog remote
> {noformat}
> and Nexus is consulted first, but this parameter is needed as a workaround
> for ARCHETYPE-344.
> One complicating factor with this example is that the 1.2 release of the
> archetype does not seem to be present in the Central index; I have no clue
> why. (It was released on February 15, i.e. more than three weeks ago, and my
> understanding is that the index is rebuilt weekly.) May not have anything to
> do with this bug, though.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-630) Request to include MKS Integrity SCM Provider along with the rest of the Maven SCM Providers
Request to include MKS Integrity SCM Provider along with the rest of the Maven SCM Providers Key: SCM-630 URL: https://jira.codehaus.org/browse/SCM-630 Project: Maven SCM Issue Type: New Feature Components: maven-scm-api Affects Versions: 1.5 Environment: Unix and Windows Reporter: Cletus D'Souza Priority: Minor Attachments: javadocs.zip, maven-scm-provider-integrity-1.0-SNAPSHOT.jar, source.zip I've developed an SCM Provider for MKS Integrity. I would like to contribute this code to the Apache community for inclusion on the Maven SCM Provider list -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-366) Maven mirror consulted after, rather than instead of, archetypeRepository URL
[
https://jira.codehaus.org/browse/ARCHETYPE-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276707#comment-276707
]
Herve Boutemy commented on ARCHETYPE-366:
-
Yes, I suppose something can be done that won't wreak havoc, even if it doesn't
cover every case (when the archetype is chosen from a catalog, for example)
> Maven mirror consulted after, rather than instead of, archetypeRepository URL
> -
>
> Key: ARCHETYPE-366
> URL: https://jira.codehaus.org/browse/ARCHETYPE-366
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
>Affects Versions: 2.0
> Environment: Ubuntu 10.04, JDK 6.
>Reporter: Jesse Glick
>Priority: Minor
> Attachments: ARCHETYPE-366.diff
>
>
> I have a local Nexus instance running, with a mirror of Central, and in
> {{settings.xml}}:
> {noformat}
>
> central
> central
> .../content/repositories/central/
>
> {noformat}
> This works fine for normal Maven operations. However, {{archetype:generate}}
> tries to download from the public repo _first_. So when I am online, after
> typing this:
> {noformat}
> rm -rf ~/.m2/repository/org/codehaus/mojo/archetypes test
> mvn -DarchetypeVersion=1.2 -Darchetype.interactive=false -DgroupId=test
> -DarchetypeArtifactId=osgi-archetype
> -DarchetypeRepository=http://repo1.maven.org/maven2/ -Dversion=1.0-SNAPSHOT
> -DarchetypeGroupId=org.codehaus.mojo.archetypes -Dbasedir=/tmp -Dpackage=test
> -DartifactId=test --batch-mode archetype:generate
> {noformat}
> I see:
> {noformat}
> [INFO] Archetype defined by properties
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> Downloaded:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> (4 KB at 8.7 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> (947 B at 8.3 KB/sec)
> {noformat}
> with no mention of Nexus; when I am offline:
> {noformat}
> [INFO] Archetype defined by properties
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> Downloading:
> http://localhost:6969/nexus/content/repositories/central/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> Downloaded:
> http://localhost:6969/nexus/content/repositories/central/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.jar
> (4 KB at 128.8 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> Downloading:
> http://localhost:6969/nexus/content/repositories/central/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> Downloaded:
> http://localhost:6969/nexus/content/repositories/central/org/codehaus/mojo/archetypes/osgi-archetype/1.2/osgi-archetype-1.2.pom
> (947 B at 57.8 KB/sec)
> {noformat}
> once this resource is cached in the Nexus mirror repo. (Since the online
> command does not ask Nexus, it normally is _not_ cached there and offline
> project creation simply fails; to force Nexus to cache it, I need to ask
> Maven to download it as a dep of something.)
> If I do not specify an explicit {{archetypeRepository}} then I get
> {noformat}
> [INFO] Archetype repository missing. Using the one from
> [org.codehaus.mojo.archetypes:osgi-archetype:1.2] found in catalog remote
> {noformat}
> and Nexus is consulted first, but this parameter is needed as a workaround
> for ARCHETYPE-344.
> One complicating factor with this example is that the 1.2 release of the
> archetype does not seem to be present in the Central index; I have no clue
> why. (It was released on February 15, i.e. more than three weeks ago, and my
> understanding is that the index is rebuilt weekly.) May not have anything to
> do with this bug, though.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-269) generate goal to execute additional goals from archetype pom
[ https://jira.codehaus.org/browse/ARCHETYPE-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276708#comment-276708 ] Herve Boutemy commented on ARCHETYPE-269: - for the moment, I still need to ship 2.1 in a week or two if there is sufficient people wanting to help on it, we should be able to continue working after the 2.1 release: knowing how you immediately gave feedback when I changed the issue is a good sign of interest, then ability to help testing it's motivating :) > generate goal to execute additional goals from archetype pom > > > Key: ARCHETYPE-269 > URL: https://jira.codehaus.org/browse/ARCHETYPE-269 > Project: Maven Archetype > Issue Type: Improvement > Components: Generator >Affects Versions: 2.0-alpha-4, 2.0, 2.1 >Reporter: Dominik Bartholdi > Fix For: 2.x > > > The following works: > $> mvn archetype:generate -DarchetypeCatalog=local -Dgoals=antrun:run > But this has some major disadvantages: > - The configuration of the goal has to be defined in the final POM of the new > project > - The user using the archetype has to know about the additional parameter > It would be a big imovement if the a creator of an archetype could define > some additional goals to be executed after the creation of the new project. > THe documentation for 'generate' tells this about the 'goals' parameter: > 'Additional goals that can be specified by the user during the creation of > the archetype'. But it does not tell how the creator could define additonal > goals. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-318) not correctly filtered
[
https://jira.codehaus.org/browse/ARCHETYPE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276709#comment-276709
]
Herve Boutemy commented on ARCHETYPE-318:
-
yeah, I worked on IT additions since it was absolutely necessary before
thinking at changing any feature
please see how you can improve the actual ones: I'm going to do a release in a
few days
if you can provide something before, it can be in the release
> not correctly filtered
>
>
> Key: ARCHETYPE-318
> URL: https://jira.codehaus.org/browse/ARCHETYPE-318
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
>Affects Versions: 2.0-alpha-5
>Reporter: Jochen Ehret
>Priority: Minor
> Fix For: 2.x
>
> Attachments: DefaultArchetypeGenerationConfigurator.patch
>
>
> In our archetype-metadata.xml we´ve defined a with a
> default value like this:
> {code:xml}
> ${artifactId}.itest1
> {code}
> When we call "archetype:generate" and enter the parameters in interactive
> mode everything works fine. But when we try to set the parameter
> "subArtifactId" on the command line (mvn archetype:generate
> -DsubArtifactId=xyz) or from an "archetype.properties" file, the value is
> ignored. In the generated pom.xml the variable ${subArtifactId} is always
> replaced with "${artifactId}.itest1".
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MJAVADOC-171) Modules in multi-module projects are "built" too often
[ https://jira.codehaus.org/browse/MJAVADOC-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy reopened MJAVADOC-171: ok, I can reproduce the issue now now I'll try to understand why it is doing such executions... > Modules in multi-module projects are "built" too often > -- > > Key: MJAVADOC-171 > URL: https://jira.codehaus.org/browse/MJAVADOC-171 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Maven 2.0.8, Linux >Reporter: Stefan Seidel >Assignee: Herve Boutemy >Priority: Critical > Fix For: 2.8 > > Attachments: 2.2.log, 2.3.log, mjavadoc171.patch, mjavadoc-171.zip, > mvnexec.zip > > > In a multi-module project, all modules are "built" twice for each module. > This leads to huge performance problems when many modules are in a project. > In the attached sample project, the xmlbeans plugin is executed 27 times for > a project with one parent module and two submodules. 18 of these executions > can be attributed to the javadoc plugin. With version 2.2, only 3 invocations > (once for each project) are caused by the javadoc plugin. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-761) java.lang.NoSuchMethodException when trying to run Junit 3 suite class
[ https://jira.codehaus.org/browse/SUREFIRE-761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-761. --- Resolution: Fixed Fix Version/s: 2.10 Assignee: Kristian Rosenvold Thanks for the patch with a good testcase ! Applied in r1160400 > java.lang.NoSuchMethodException when trying to run Junit 3 suite class > -- > > Key: SUREFIRE-761 > URL: https://jira.codehaus.org/browse/SUREFIRE-761 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 3.x support >Affects Versions: 2.8, 2.9 > Environment: maven 3.0.3 >Reporter: Jan Sievers >Assignee: Kristian Rosenvold >Priority: Critical > Fix For: 2.10 > > Attachments: demo.zip, SUREFIRE-761.patch > > > attached small demo project demonstrates that JUnit 3 suite classes can't be > executed due to NoSuchMethodException. > surefire 1.8 and 2.9 are affected. BTW I also tested with older surefire > versions, here the suite class is completely ignored which is also a bug. > We found this bug while porting the tycho surefire plugin to surefire 2.9, > see > https://bugs.eclipse.org/bugs/show_bug.cgi?id=353222 > I will create a patch for this issue. > --- build log snippet --- > [INFO] --- maven-surefire-plugin:2.9:test (default-test) @ demo --- > [INFO] Surefire report directory: C:\ws\tycho\demo\target\surefire-reports > --- > T E S T S > --- > org.apache.maven.surefire.util.SurefireReflectionException: > java.lang.reflect.InvocationTargetException; nested exception is > java.lang.reflect.InvocationTargetException: null > java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) > at > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) > at > org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:172) > at > org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:104) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70) > Caused by: org.apache.maven.surefire.util.NestedRuntimeException: When > finding method run; nested exception is java.lang.NoSuchMethodException: > test.demo.Suite.run(junit.framework.TestResult) > at > org.apache.maven.surefire.common.junit3.JUnit3Reflector.getMethod(JUnit3Reflector.java:113) > at > org.apache.maven.surefire.common.junit3.JUnit3Reflector.getRunMethod(JUnit3Reflector.java:208) > at > org.apache.maven.surefire.junit.JUnitTestSet.(JUnitTestSet.java:71) > at > org.apache.maven.surefire.junit.JUnit3Provider.createTestSet(JUnit3Provider.java:103) > at > org.apache.maven.surefire.junit.JUnit3Provider.invoke(JUnit3Provider.java:93) > ... 9 more > Caused by: java.lang.NoSuchMethodException: > test.demo.Suite.run(junit.framework.TestResult) > at java.lang.Class.getMethod(Class.java:1605) > at > org.apache.maven.surefire.common.junit3.JUnit3Reflector.getMethod(JUnit3Reflector.java:109) > ... 13 more > Results : > Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHECKSTYLE-142) add access to maven properties
[
https://jira.codehaus.org/browse/MCHECKSTYLE-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276716#comment-276716
]
Joachim Van der Auwera commented on MCHECKSTYLE-142:
Just for some addition info why I need this.
I have written a checkstyle rule which assures that the published API for a
module does not change (based on annotations which indicate what the published
API is).
To be able to do this check, a "api.txt" file is read as input (from
${basedir}/src/main/resources) and also written (to ${basedir}/target). This
allows both manual comparison and allows replace the src file by the target
file when a release is made.
> add access to maven properties
> --
>
> Key: MCHECKSTYLE-142
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-142
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Joachim Van der Auwera
> Attachments: checkstyle-prop.patch
>
>
> At least, access to ${basedir} inside the configuration files would be very
> useful.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-346) LightWeight http wagon not thread-safe
[ https://jira.codehaus.org/browse/WAGON-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276717#comment-276717 ] Mark Struberg commented on WAGON-346: - +1 for using URL.openConnection(Proxy) wagon-2.0 (current trunk) got upgraded to java5 already. So all necessary requirements should be met. > LightWeight http wagon not thread-safe > -- > > Key: WAGON-346 > URL: https://jira.codehaus.org/browse/WAGON-346 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http-lightweight >Affects Versions: 1.0 > Environment: maven 3 with Aether >Reporter: nicolas de loof > > Aether (maven3) by default parallelized metadata resolution on 4 threads > (aether.metadataResolver.threads) and artifacts downloading on 5 > (maven.artifact.threads). > In such context, Wagon is not used sequentially. > LightWeightHttpWagon is designed for mono-thread, sequential usage. It rely > on system properties and on setting/resetting java.net.Authenticator > singleton. > The result is that, in some cases (typically : when settings defines many > repositories with various credentials), credentials may not apply and > download will fail > A potential fix is > - to use Java5 URL.openConnection(Proxy) instead of using system properties > - to use a shared, singleton java.net.Authenticator that lookup repositories > to match the requested URL -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-630) Request to include MKS Integrity SCM Provider along with the rest of the Maven SCM Providers
[ https://jira.codehaus.org/browse/SCM-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276718#comment-276718 ] Olivier Lamy commented on SCM-630: -- the file mksapi-jar-4.10.9049.jar contains some classes com/mks/api what is license for this library ? (note it contains some apache classes too : commons logging, commons-httpclient) could it be deployed to central maven repository ? > Request to include MKS Integrity SCM Provider along with the rest of the > Maven SCM Providers > > > Key: SCM-630 > URL: https://jira.codehaus.org/browse/SCM-630 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-api >Affects Versions: 1.5 > Environment: Unix and Windows >Reporter: Cletus D'Souza >Priority: Minor > Attachments: javadocs.zip, > maven-scm-provider-integrity-1.0-SNAPSHOT.jar, source.zip > > > I've developed an SCM Provider for MKS Integrity. > I would like to contribute this code to the Apache community for inclusion on > the Maven SCM Provider list -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MGPG-31) Integrate w/ Maven password encryption to avoid need to type passphrase
[
https://jira.codehaus.org/browse/MGPG-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276722#comment-276722
]
Jesse Glick commented on MGPG-31:
-
In my setup the GPG passphrase is on a login-encrypted disk, just like the
Maven master password. I would rather "use an agent integrated with the OS" for
GPG as well as for all other purposes in Maven builds, but Maven does not
currently integrate with the GNOME keyring.
It is not clear that a fix is possible. {{SettingsDecryptionRequest}} hardcodes
servers and proxies; there is no extension point for other kinds of things that
might need passwords (such as the GPG plugin). The only thing I can think of is
to create a dummy {{server}} entry with a magic {{id}} like {{gpg}} and no
{{username}}.
It also does not look like there is any way to override
{{DefaultSettingsDecrypter}} e.g. in a build extension to do something like
integrate with a desktop keyring; I have asked on the dev list before about
injecting a higher-priority alternative to a standard service and been told it
was not possible.
> Integrate w/ Maven password encryption to avoid need to type passphrase
> ---
>
> Key: MGPG-31
> URL: https://jira.codehaus.org/browse/MGPG-31
> Project: Maven 2.x and 3.x GPG Plugin
> Issue Type: Improvement
>Affects Versions: 1.1
> Environment: JDK 6u21, Ubuntu, Maven 3.0 RC1
>Reporter: Jesse Glick
>Priority: Minor
> Labels: contributers-welcome
>
> It is cumbersome to be prompted for a passphrase during both release:prepare
> and release:perform:
> {noformat}
> [INFO] --- maven-gpg-plugin:1.1:sign (sign-artifacts) @ nbm-maven-plugin
> ---
> GPG Passphrase: *
> {noformat}
> I already use http://maven.apache.org/guides/mini/guide-encryption.html (with
> a master password on an Ubuntu encrypted filesystem) so why do I need to type
> this pass phrase each time too?
> Not clear to me whether MGPG-30 already permits this. In any event, the
> plugin documentation does not seem to mention this as a use case.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-569) The numbering of the items in the FAQ on the site is messed up
The numbering of the items in the FAQ on the site is messed up -- Key: MASSEMBLY-569 URL: https://jira.codehaus.org/browse/MASSEMBLY-569 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2.1 Environment: n/a Reporter: Anders Hammar Priority: Trivial The numbering in the FAQ (http://maven.apache.org/plugins/maven-assembly-plugin/faq.html) is messed up. The items are numbered 1,2,3,4,1,1,2,3,1. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-569) The numbering of the items in the FAQ on the site is messed up
[ https://jira.codehaus.org/browse/MASSEMBLY-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276735#comment-276735 ] Anders Hammar commented on MASSEMBLY-569: - I haven't verified, but I think the problem is empty lines separating the items which makes the reporting plugin restart the numbering. > The numbering of the items in the FAQ on the site is messed up > -- > > Key: MASSEMBLY-569 > URL: https://jira.codehaus.org/browse/MASSEMBLY-569 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2.1 > Environment: n/a >Reporter: Anders Hammar >Priority: Trivial > > The numbering in the FAQ > (http://maven.apache.org/plugins/maven-assembly-plugin/faq.html) is messed > up. The items are numbered 1,2,3,4,1,1,2,3,1. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
