Right behaviour of versions:update-properties?
Hi all,
I made some tests with the Versions Maven Plugin and the behaviour of the
goal versions:update-properties is different from my expectation.
I have two artifacts in my repository:
1. pom-projet-a with the version 1.4.0 and 1.5.0-SNAPSHOT
2. jar-project-b with the version 1.11.0 and 1.12.0-SNAPSHOT
In a third project I have following pom definition:
parent
groupIdmycompany/groupId
artifactIdpom-project-a/artifactId
version1.5.0-SNAPSHOT/version
/parent
packagingpom/packaging
artifactIdrelease-test/artifactId
version1.0.0-SNAPSHOT/version
properties
jar.version1.12.0-SNAPSHOT/jar.version
/properties
nameRelease Test/name
dependencies
dependency
groupIdmycompany/groupId
artifactIdjar-project-b/artifactId
version${jar.version}/version
/dependency
/dependencies
When I call the goal versions:update-parent, the Versions Maven Plugin
changes the version number to the last release version (here 1.4.0). This
is what I expect. When I call the goal versions:update-properties, the
version in the property jar.version isn't changed. I would expect, that
the plugin would change the version number to the last release version
(here 1.11.0) , too.
I made another test. I put the artifact jar-project-b with the version
1.12.0 in my repository, so I have the version 1.11.0, 1.12.0,
1.12.0-SNAPSHOT in my repository. When I call now the goal
versions:update-properties, the version in the property jar.version is
changed to 1.12.0. (the last release version).
Now my question is:
Is this a bug in the plugin or is my expectation wrong?
Kind regards
Sandra
IT Solutions / Software Development
Rhenus Freight Logistics GmbH Co.KG, Rhenus-Platz 1, 59439 Holzwickede,
Deutschland
www.rhenus.com;
Sitz: Unna, AG Hamm, HRA 2089; phG: Rhenus Freight Logistics Verwaltungs
GmbH, Unna, AG Hamm HRB 3422; Geschäftsführer: Petra Finke, Herbert
Joeres, Dr.Martin Neese, Lutz Welter
Re: Right behaviour of versions:update-properties?
On Friday, 13 July 2012, wrote:
Hi all,
I made some tests with the Versions Maven Plugin and the behaviour of the
goal versions:update-properties is different from my expectation.
I have two artifacts in my repository:
1. pom-projet-a with the version 1.4.0 and 1.5.0-SNAPSHOT
2. jar-project-b with the version 1.11.0 and 1.12.0-SNAPSHOT
In a third project I have following pom definition:
parent
groupIdmycompany/groupId
artifactIdpom-project-a/artifactId
version1.5.0-SNAPSHOT/version
/parent
packagingpom/packaging
artifactIdrelease-test/artifactId
version1.0.0-SNAPSHOT/version
properties
jar.version1.12.0-SNAPSHOT/jar.version
/properties
nameRelease Test/name
dependencies
dependency
groupIdmycompany/groupId
artifactIdjar-project-b/artifactId
version${jar.version}/version
/dependency
/dependencies
When I call the goal versions:update-parent, the Versions Maven Plugin
changes the version number to the last release version (here 1.4.0). This
is what I expect.
If 1.5.0-SNAPSHOT is in the reactor/local/remote repo it should leave as
is. If this is not the case then you have a bug
When I call the goal versions:update-properties, the
version in the property jar.version isn't changed. I would expect, that
the plugin would change the version number to the last release version
(here 1.11.0) , too.
Should never downgrade to older versions, so FAD
I made another test. I put the artifact jar-project-b with the version
1.12.0 in my repository, so I have the version 1.11.0, 1.12.0,
1.12.0-SNAPSHOT in my repository. When I call now the goal
versions:update-properties, the version in the property jar.version is
changed to 1.12.0. (the last release version).
FAD
Now my question is:
Is this a bug in the plugin or is my expectation wrong?
Update-* should only move forward
Update-parent has a special case where it will try to fix child projects so
they can be built, a side-effect is that it might downgrade to a real
version... Perhaps that feature could be moved to a fix-parent goal
Kind regards
Sandra
IT Solutions / Software Development
Rhenus Freight Logistics GmbH Co.KG, Rhenus-Platz 1, 59439 Holzwickede,
Deutschland
www.rhenus.com;
Sitz: Unna, AG Hamm, HRA 2089; phG: Rhenus Freight Logistics Verwaltungs
GmbH, Unna, AG Hamm HRB 3422; Geschäftsführer: Petra Finke, Herbert
Joeres, Dr.Martin Neese, Lutz Welter
Antwort: Re: Right behaviour of versions:update-properties?
On Friday, 13 July 2012, wrote:
Hi all,
I made some tests with the Versions Maven Plugin and the behaviour of
the
goal versions:update-properties is different from my expectation.
I have two artifacts in my repository:
1. pom-projet-a with the version 1.4.0 and 1.5.0-SNAPSHOT
2. jar-project-b with the version 1.11.0 and 1.12.0-SNAPSHOT
In a third project I have following pom definition:
parent
groupIdmycompany/groupId
artifactIdpom-project-a/artifactId
version1.5.0-SNAPSHOT/version
/parent
packagingpom/packaging
artifactIdrelease-test/artifactId
version1.0.0-SNAPSHOT/version
properties
jar.version1.12.0-SNAPSHOT/jar.version
/properties
nameRelease Test/name
dependencies
dependency
groupIdmycompany/groupId
artifactIdjar-project-b/artifactId
version${jar.version}/version
/dependency
/dependencies
When I call the goal versions:update-parent, the Versions Maven Plugin
changes the version number to the last release version (here 1.4.0).
This
is what I expect.
If 1.5.0-SNAPSHOT is in the reactor/local/remote repo it should leave as
is. If this is not the case then you have a bug
It is.
When I call the goal versions:update-properties, the
version in the property jar.version isn't changed. I would expect,
that
the plugin would change the version number to the last release version
(here 1.11.0) , too.
Should never downgrade to older versions, so FAD
Usually I agree with you, but both projects (pom-project-a and
jar-project-b) are under my control. The use case I tried is I don't make
change in pom-project-a and jar-project-b but in release-test. So I want
to release release-test. Because of no change in pom-project-a and
jar-project-b I can downgrade to older versions. Perhaps Versions Maven
Plugin is not the right tool for my use case.
I made another test. I put the artifact jar-project-b with the version
1.12.0 in my repository, so I have the version 1.11.0, 1.12.0,
1.12.0-SNAPSHOT in my repository. When I call now the goal
versions:update-properties, the version in the property jar.version
is
changed to 1.12.0. (the last release version).
FAD
Now my question is:
Is this a bug in the plugin or is my expectation wrong?
Update-* should only move forward
Maybe I missunderstand the documentation of the goal because of the flag
-DallowsSnapshot.
Update-parent has a special case where it will try to fix child projects
so
they can be built, a side-effect is that it might downgrade to a real
version... Perhaps that feature could be moved to a fix-parent goal
Kind regards
Sandra
IT Solutions / Software Development
Rhenus Freight Logistics GmbH Co.KG, Rhenus-Platz 1, 59439
Holzwickede,
Deutschland
www.rhenus.com;
Sitz: Unna, AG Hamm, HRA 2089; phG: Rhenus Freight Logistics Verwaltungs
GmbH, Unna, AG Hamm HRB 3422; Geschäftsführer: Petra Finke, Herbert
Joeres, Dr.Martin Neese, Lutz Welter
Re: Re: Right behaviour of versions:update-properties?
On 13 July 2012 10:01, sandra.kosma...@de.rhenus.com wrote:
On Friday, 13 July 2012, wrote:
Hi all,
I made some tests with the Versions Maven Plugin and the behaviour of
the
goal versions:update-properties is different from my expectation.
I have two artifacts in my repository:
1. pom-projet-a with the version 1.4.0 and 1.5.0-SNAPSHOT
2. jar-project-b with the version 1.11.0 and 1.12.0-SNAPSHOT
In a third project I have following pom definition:
parent
groupIdmycompany/groupId
artifactIdpom-project-a/artifactId
version1.5.0-SNAPSHOT/version
/parent
packagingpom/packaging
artifactIdrelease-test/artifactId
version1.0.0-SNAPSHOT/version
properties
jar.version1.12.0-SNAPSHOT/jar.version
/properties
nameRelease Test/name
dependencies
dependency
groupIdmycompany/groupId
artifactIdjar-project-b/artifactId
version${jar.version}/version
/dependency
/dependencies
When I call the goal versions:update-parent, the Versions Maven Plugin
changes the version number to the last release version (here 1.4.0).
This
is what I expect.
If 1.5.0-SNAPSHOT is in the reactor/local/remote repo it should leave as
is. If this is not the case then you have a bug
It is.
When I call the goal versions:update-properties, the
version in the property jar.version isn't changed. I would expect,
that
the plugin would change the version number to the last release version
(here 1.11.0) , too.
Should never downgrade to older versions, so FAD
Usually I agree with you, but both projects (pom-project-a and
jar-project-b) are under my control. The use case I tried is I don't make
change in pom-project-a and jar-project-b but in release-test. So I want
to release release-test. Because of no change in pom-project-a and
jar-project-b I can downgrade to older versions. Perhaps Versions Maven
Plugin is not the right tool for my use case.
I made another test. I put the artifact jar-project-b with the version
1.12.0 in my repository, so I have the version 1.11.0, 1.12.0,
1.12.0-SNAPSHOT in my repository. When I call now the goal
versions:update-properties, the version in the property jar.version
is
changed to 1.12.0. (the last release version).
FAD
Now my question is:
Is this a bug in the plugin or is my expectation wrong?
Update-* should only move forward
Maybe I missunderstand the documentation of the goal because of the flag
-DallowsSnapshot.
That just says that it can upgrade to a newer -SNAPSHOT
but keep in mind that 1.1-SNAPSHOT is earlier than 1.1
Update-parent has a special case where it will try to fix child projects
so
they can be built, a side-effect is that it might downgrade to a real
version... Perhaps that feature could be moved to a fix-parent goal
Kind regards
Sandra
IT Solutions / Software Development
Rhenus Freight Logistics GmbH Co.KG, Rhenus-Platz 1, 59439
Holzwickede,
Deutschland
www.rhenus.com;
Sitz: Unna, AG Hamm, HRA 2089; phG: Rhenus Freight Logistics Verwaltungs
GmbH, Unna, AG Hamm HRB 3422; Geschäftsführer: Petra Finke, Herbert
Joeres, Dr.Martin Neese, Lutz Welter
Re: Generating javadoc for a set of unrelated projects?
On Thu, 12 Jul 2012 13:10:08 -0500 Curtis Rueden ctrue...@wisc.edu wrote: Hi org.apache.maven.user, What's the simplest way to generate (aggregated) javadoc for this set of projects? Is it enough that your javadocs cross-link with each other at their respective published locations? If so, you can add the links to the maven-javadoc-plugin configuration. E.g.: plugin artifactIdmaven-javadoc-plugin/artifactId version2.8.1/version configuration links linkhttps://pivot.apache.org/2.0.1/docs/api//link link http://help.eclipse.org/indigo/topic/org.eclipse.platform.doc.isv/reference/api/ /link /links /configuration /plugin Replacing the links with your published javadoc locations, of course. Yeah, that'll work. Thanks! I can't modify the pom files of the individual projects I haven't tested it, but presumably you could create a new aggregator POM that includes the individual projects as modules, and set the aggregator's javadoc configuration as above. Then run mvn site and wait for the magic. I avoided this because I assumed that the modules of the aggregator would have to exist as subdirectories of the project. Is this actually the case? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
pom formatter?
Hi all, I'm wondering if anyone knows of a command line formatter for pom files? Not just converting tabs/spaces and line lengths but sorting out the ordering of elements (model comes before parent which comes before dependencies etc) (whilst also at the same time maintaining comments!). Does anyone know if such a beast exists? /James ** This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmas...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00 **
Re: pom formatter?
tidy-maven-plugin @ mojo (only a snapshot release) will apply the canonical pom ordering but does not handle indenting (in fact it tries to keep all the indenting the same On 13 July 2012 14:49, Nord, James jn...@nds.com wrote: Hi all, I'm wondering if anyone knows of a command line formatter for pom files? Not just converting tabs/spaces and line lengths but sorting out the ordering of elements (model comes before parent which comes before dependencies etc) (whilst also at the same time maintaining comments!). Does anyone know if such a beast exists? /James ** This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmas...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00 **
How can I debug nexus?
Hi, I debugged a problem from the client side of maven, using mvnDebug and jdb -attach 8000. Now, I'd like to do the same from the nexus server side. I cloned the nexus.git repo, and checkedout the nexus-2.0.4 tag. I expect I ought to start nexus under jdb using an alternative port... The issue I am after is finding out whether nexus could not do better than returning an 'http 400 Bad request' response to the put request from maven deploy, when this one is told to deploy an existing artifact. I.e. I do: mvn deploy:deploy-file -Durl=http://eselivm2v214l.lmera.ericsson.se:8081/nexus/content/repositories/releases/ -DrepositoryId=releases -Dpackaging=pom -DgroupId=com.ericsson.test -DartifactId=foo-1.0.0.pom -Dversion=1.0.0 -Dfile=/home/emagiro/tmp/foo.txt ...and get success, then do it again and get: 400, ReasonPhrase:Bad Request. I clean away the storage, and it works fine again. Once. My goal would be to build up my own competence by submitting a patch to enhance this error report. Thanks, Marc -- View this message in context: http://maven.40175.n5.nabble.com/How-can-I-debug-nexus-tp5714072.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Inspector for Eclipse
As much as Maven makes it easy to deal with builds, the plethora of XML and the varying life cycles phases can sometimes make it hard to figure out what a build will actually do. To help with this, I'm happy to make available the Eclipse plugin called the Maven Inspector. This plugin provides a simple View called Maven Execution that presents for a given POM file the phases and associated MOJOs. Go check it out on http://prapicault.github.com/MavenInspector/ or directly install it from http://prapicault.github.com/MavenInspector/repository Hope you'll find this useful. Pascal - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How can I debug nexus?
...and get success, then do it again and get: 400, ReasonPhrase:Bad Request. I clean away the storage, and it works fine again. Once. My goal would be to build up my own competence by submitting a patch to enhance this error report. Sounds like a good improvement to Nexus. Nexus is produced by Sonatype, as such, you would need to ask them how to debug their product. http://www.sonatype.org/nexus/participate Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [ANN] Maven Inspector for Eclipse
Hello Pascal, Thanks for contributiong this plugin, this is a very good idea, and will save users a lot of time debugging maven builds. One remark though : * do you think it would be possible to contribute this view directly into m2e ? did you contact m2e team ? I mean, that would ease adoption of the plugin, and it seems to me that it would be useful for all m2e users. Thanks again Pascal, Anthony On Fri, Jul 13, 2012 at 11:06 AM, Pascal Rapicault pas...@rapicault.net wrote: As much as Maven makes it easy to deal with builds, the plethora of XML and the varying life cycles phases can sometimes make it hard to figure out what a build will actually do. To help with this, I'm happy to make available the Eclipse plugin called the Maven Inspector. This plugin provides a simple View called Maven Execution that presents for a given POM file the phases and associated MOJOs. Go check it out on http://prapicault.github.com/MavenInspector/ or directly install it from http://prapicault.github.com/MavenInspector/repository Hope you'll find this useful. Pascal - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [ANN] Maven Inspector for Eclipse
Hello Anthony Thanks for your feedback. To answer your question in full disclosure. I'm an m2e committer. However I'm doing this to promote myself and my consulting services, therefore merging it back into m2e at this point would do me a disservice. Pascal On 2012-07-13, at 5:40 PM, Anthony Dahanne wrote: Hello Pascal, Thanks for contributiong this plugin, this is a very good idea, and will save users a lot of time debugging maven builds. One remark though : * do you think it would be possible to contribute this view directly into m2e ? did you contact m2e team ? I mean, that would ease adoption of the plugin, and it seems to me that it would be useful for all m2e users. Thanks again Pascal, Anthony On Fri, Jul 13, 2012 at 11:06 AM, Pascal Rapicault pas...@rapicault.net wrote: As much as Maven makes it easy to deal with builds, the plethora of XML and the varying life cycles phases can sometimes make it hard to figure out what a build will actually do. To help with this, I'm happy to make available the Eclipse plugin called the Maven Inspector. This plugin provides a simple View called Maven Execution that presents for a given POM file the phases and associated MOJOs. Go check it out on http://prapicault.github.com/MavenInspector/ or directly install it from http://prapicault.github.com/MavenInspector/repository Hope you'll find this useful. Pascal - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
ssh pluginRepository not recognized by maven 3.0.4
Hello, I am trying to migrate from maven 2.2.1 to maven 3.0.4. My configuration involves a private ssh/scp server acting both as a repository and a pluginRepository. The problem is that maven 3 cannot recognize the pluginRepository properly, it fails with the following combination of warning and errors: [WARNING] Could not transfer metadata my-group/maven-metadata.xml from/to myrepop (scpexe://myhost): No connector available to access repository altsolp (scpexe://myhost) of type default using the available factories WagonRepositoryConnectorFactory [ERROR] No plugin found for prefix 'myrepop' in the current project and in the plugin groups [my-group, org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (~/.m2/repository), myrepop (scpexe://myhost), central (http://repo.maven.apache.org/maven2)] I also tried using the fullpath: mvn my-group:my-plugin:my-version:myTarget Then the warning doesn't show up, just the following error (which is the same problem description in other words): [ERROR] Plugin my-group:my-plugin:my-version or one of its dependencies could not be resolved: Failed to read artifact descriptor for my-group:my-plugin:my-version: Could not transfer artifact my-group:my-plugin:my-version from/to myrepop (scpexe://myhost): No connector available to access repository myrepop (scpexe://myhost) of type default using the available factories WagonRepositoryConnectorFactory - [Help 1] It seems impossible to convince Maven 3 to operate the pluginRepository server using wagon-ssh-external. If I switch it to http://, it works like a charm, but I prefer to access it using ssh. Using scpexe://myhost as a maven repo works ok for Maven 3. Maven 2 also works with the same configuration for both repo and pluginRepo. Does anyone have a clue ? Is it somehow possible to use ssh pluginRepositories ? Thanks in advance for your help. My settings.xml includes: pluginGroups pluginGroupmy.package/pluginGroup /pluginGroups servers server idmyrepo/id usernameme/username configuration sshExecutablessh/sshExecutable scpExecutablescp/scpExecutable /configuration /server server idmyrepop/id usernameme/username configuration sshExecutablessh/sshExecutable scpExecutablescp/scpExecutable /configuration /server /servers repositories repository idmyrepo/id namemyrepo/name urlscpexe://myhost/url /repository /repositories pluginRepositories pluginRepository namemyrepop/name idmyrepop/id urlscpexe://myhost/url /pluginRepository /pluginRepositories My project's pom.xml includes: build extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-ssh-external/artifactId version2.2/version !-- also tried with 1.0-beta-6 -- /extension /extensions plugins plugin groupIdmy.package/groupId artifactIdmy-plugin/artifactId versionmy-version/version - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: pom formatter?
Thanks Stephen, It appears to use spaces for the indentation of the moved block start tag - whereas the rest of the block (and the close) are left with tabs. But otherwise just the ticket :-) /James -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: 13 July 2012 14:56 To: Maven Users List Subject: Re: pom formatter? tidy-maven-plugin @ mojo (only a snapshot release) will apply the canonical pom ordering but does not handle indenting (in fact it tries to keep all the indenting the same On 13 July 2012 14:49, Nord, James jn...@nds.com wrote: Hi all, I'm wondering if anyone knows of a command line formatter for pom files? Not just converting tabs/spaces and line lengths but sorting out the ordering of elements (model comes before parent which comes before dependencies etc) (whilst also at the same time maintaining comments!). Does anyone know if such a beast exists? /James ** This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmas...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00 ** - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: ssh pluginRepository not recognized by maven 3.0.4
the default wagons in Maven 3.0 were trimmed. you will need to add the appropriate wagon as a build extension On 13 July 2012 17:11, Thanos Kyritsis dj...@linux.gr wrote: Hello, I am trying to migrate from maven 2.2.1 to maven 3.0.4. My configuration involves a private ssh/scp server acting both as a repository and a pluginRepository. The problem is that maven 3 cannot recognize the pluginRepository properly, it fails with the following combination of warning and errors: [WARNING] Could not transfer metadata my-group/maven-metadata.xml from/to myrepop (scpexe://myhost): No connector available to access repository altsolp (scpexe://myhost) of type default using the available factories WagonRepositoryConnectorFactor**y [ERROR] No plugin found for prefix 'myrepop' in the current project and in the plugin groups [my-group, org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (~/.m2/repository), myrepop (scpexe://myhost), central (http://repo.maven.apache.org/**maven2http://repo.maven.apache.org/maven2 )] I also tried using the fullpath: mvn my-group:my-plugin:my-version:**myTarget Then the warning doesn't show up, just the following error (which is the same problem description in other words): [ERROR] Plugin my-group:my-plugin:my-version or one of its dependencies could not be resolved: Failed to read artifact descriptor for my-group:my-plugin:my-version: Could not transfer artifact my-group:my-plugin:my-version from/to myrepop (scpexe://myhost): No connector available to access repository myrepop (scpexe://myhost) of type default using the available factories WagonRepositoryConnectorFactor**y - [Help 1] It seems impossible to convince Maven 3 to operate the pluginRepository server using wagon-ssh-external. If I switch it to http://, it works like a charm, but I prefer to access it using ssh. Using scpexe://myhost as a maven repo works ok for Maven 3. Maven 2 also works with the same configuration for both repo and pluginRepo. Does anyone have a clue ? Is it somehow possible to use ssh pluginRepositories ? Thanks in advance for your help. My settings.xml includes: pluginGroups pluginGroupmy.package/**pluginGroup /pluginGroups servers server idmyrepo/id usernameme/username configuration sshExecutablessh/**sshExecutable scpExecutablescp/**scpExecutable /configuration /server server idmyrepop/id usernameme/username configuration sshExecutablessh/**sshExecutable scpExecutablescp/**scpExecutable /configuration /server /servers repositories repository idmyrepo/id namemyrepo/name urlscpexe://myhost/url /repository /repositories pluginRepositories pluginRepository namemyrepop/name idmyrepop/id urlscpexe://myhost/url /pluginRepository /pluginRepositories My project's pom.xml includes: build extensions extension groupIdorg.apache.maven.**wagon/groupId artifactIdwagon-ssh-**external/artifactId version2.2/version !-- also tried with 1.0-beta-6 -- /extension /extensions plugins plugin groupIdmy.package/groupId artifactIdmy-plugin/**artifactId versionmy-version/version --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: ssh pluginRepository not recognized by maven 3.0.4
https://github.com/jvanzyl/maven-recipes/tree/master/deploy-with-scp-extension On Jul 13, 2012, at 12:11 PM, Thanos Kyritsis wrote: Hello, I am trying to migrate from maven 2.2.1 to maven 3.0.4. My configuration involves a private ssh/scp server acting both as a repository and a pluginRepository. The problem is that maven 3 cannot recognize the pluginRepository properly, it fails with the following combination of warning and errors: [WARNING] Could not transfer metadata my-group/maven-metadata.xml from/to myrepop (scpexe://myhost): No connector available to access repository altsolp (scpexe://myhost) of type default using the available factories WagonRepositoryConnectorFactory [ERROR] No plugin found for prefix 'myrepop' in the current project and in the plugin groups [my-group, org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (~/.m2/repository), myrepop (scpexe://myhost), central (http://repo.maven.apache.org/maven2)] I also tried using the fullpath: mvn my-group:my-plugin:my-version:myTarget Then the warning doesn't show up, just the following error (which is the same problem description in other words): [ERROR] Plugin my-group:my-plugin:my-version or one of its dependencies could not be resolved: Failed to read artifact descriptor for my-group:my-plugin:my-version: Could not transfer artifact my-group:my-plugin:my-version from/to myrepop (scpexe://myhost): No connector available to access repository myrepop (scpexe://myhost) of type default using the available factories WagonRepositoryConnectorFactory - [Help 1] It seems impossible to convince Maven 3 to operate the pluginRepository server using wagon-ssh-external. If I switch it to http://, it works like a charm, but I prefer to access it using ssh. Using scpexe://myhost as a maven repo works ok for Maven 3. Maven 2 also works with the same configuration for both repo and pluginRepo. Does anyone have a clue ? Is it somehow possible to use ssh pluginRepositories ? Thanks in advance for your help. My settings.xml includes: pluginGroups pluginGroupmy.package/pluginGroup /pluginGroups servers server idmyrepo/id usernameme/username configuration sshExecutablessh/sshExecutable scpExecutablescp/scpExecutable /configuration /server server idmyrepop/id usernameme/username configuration sshExecutablessh/sshExecutable scpExecutablescp/scpExecutable /configuration /server /servers repositories repository idmyrepo/id namemyrepo/name urlscpexe://myhost/url /repository /repositories pluginRepositories pluginRepository namemyrepop/name idmyrepop/id urlscpexe://myhost/url /pluginRepository /pluginRepositories My project's pom.xml includes: build extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-ssh-external/artifactId version2.2/version !-- also tried with 1.0-beta-6 -- /extension /extensions plugins plugin groupIdmy.package/groupId artifactIdmy-plugin/artifactId versionmy-version/version - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
Re: [ANN] Maven Inspector for Eclipse
Hello, just in case someone needs it, you can achieve the same in command line using tk.skuro:plan-maven-plugin: * https://github.com/skuro/plan-maven-plugin * http://search.maven.org/#search|ga|1|g%3A%22tk.skuro%22%20AND%20a%3A%22plan-maven-plugin%22 Regards, htfv (Aliaksei Lahachou) On Fri, Jul 13, 2012 at 5:06 PM, Pascal Rapicault pas...@rapicault.netwrote: As much as Maven makes it easy to deal with builds, the plethora of XML and the varying life cycles phases can sometimes make it hard to figure out what a build will actually do. To help with this, I'm happy to make available the Eclipse plugin called the Maven Inspector. This plugin provides a simple View called Maven Execution that presents for a given POM file the phases and associated MOJOs. Go check it out on http://prapicault.github.com/MavenInspector/ or directly install it from http://prapicault.github.com/MavenInspector/repository Hope you'll find this useful. Pascal - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Artifact with external configuration - the Maven way
Hi! I'm using Maven at work to organize my software projects. I will first of all describe you my current build process. - The typical deployment assembly contains at least: - the application JAR file, - a JAR file for every dependency, - an application configuration file (an XML file with an XSD schema file), - Log4J configuration file (a single XML file). It is important that the application configuration file is not packaged inside the application JAR file - I could not change configuration in production otherwise. The Maven assembly plugin is used to package all those files into a single ZIP to allow convenient deploy at the target machine. - For every environment (e.g. development, test, acceptance, production) there is a single Maven profile. The configuration files contain property placeholders. When building the assembly, the values of properties used in the configuration files (e.g. the default configuration values) are resolved according to the active profile. - The question I have is how to store the builds to be available for deployment - so that I don't have to build the project every time I need to deploy the application to a new machine. To my understanding, a Nexus repository is typically used for that. I have found out though that a Maven repository is only capable of storing simple artifacts, not ZIP assemblies. I am convinced that there are plenty of projects that need external configuration files in addition to the application JARs. What is the commonly used way to handle my issue? Thank you in advance for all replies. Dusan R.
Re: Passing system arguments to the forked maven process for release:prepare and release:perform
That sorted it. Here's a link to the complete POM for anyone else who has this
issue as well.
https://github.com/apigee/beanstalk-spring-integration/blob/02926556b51ec24b916a9ea41182c5bc10059609/pom.xml
Thanks again for the help!
--
Todd Nine
On Thursday, July 12, 2012 at 2:43 PM, Stephen Connolly wrote:
yours since you don't control the parent
On 12 July 2012 22:35, Todd Nine tn...@apigee.com (mailto:tn...@apigee.com)
wrote:
Thanks Stephen!
Do I need to do that in the parent pom or in mine?
--
Todd Nine
On Thursday, July 12, 2012 at 2:33 PM, Stephen Connolly wrote:
Override back to ${arguments} -Psonatype-...
On Thursday, 12 July 2012, Todd Nine wrote:
Any idea how to merge the two? I obviously want command line arguments,
putting our S3 creeds into a public repo isn't a very good idea! ;)
--
Todd Nine
On Thursday, July 12, 2012 at 2:14 PM, Ansgar Konermann wrote:
Am 12.07.2012 22:33, schrieb Todd Nine:
Hi all,
I'm attempting to re-package a 3rd party open source project and
create our own custom distribution. I've modified and the source, and
the
repo is available here.
https://github.com/apigee/beanstalk-spring-integration/tree/usergrid
I'm attempting to perform a release, however these properties must
be
present at runtime for testing to work properly.
-DAWS_ACCESS_KEY_ID=[your aws accesskey] -DAWS_SECRET_KEY=[your aws
secret key]
Because this uses sensitive data, I obviously don't want to put
these
properties in the Pom. I've scoured the documentation, but I'm unable
to
find an example of how to do this, and I know I've done it before!
Here is
what I'm attempting, which is failing.
mvn release:prepare release:perform
-Darguments=-DAWS_ACCESS_KEY_ID=[your aws accesskey]
-DAWS_SECRET_KEY=[your aws secret key]
Any help would be greatly appreciated!
Thanks,
This is in your parent pom (org.sonatype.oss:oss-parent:7:pom):
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.1/version
configuration
mavenExecutorIdforked-path/mavenExecutorId
useReleaseProfilefalse/useReleaseProfile
arguments-Psonatype-oss-release/arguments
/configuration
/plugin
/plugins
/pluginManagement
It overrides m-release-plugin's arguments. I suspect this will
override the -Darguments on the command line.
HTH
Ansgar
Re: Artifact with external configuration - the Maven way
Hello, Maven repository may contain anything, you just have to set appropriate classifier and type/packaging. I never deployed zip archives using Maven plugins, but I often upload zips to our company Nexus using web-front. Regards, htfv (Aliaksei Lahachou) On Fri, Jul 13, 2012 at 7:56 PM, Dušan Rychnovský geraltzri...@gmail.comwrote: Hi! I'm using Maven at work to organize my software projects. I will first of all describe you my current build process. - The typical deployment assembly contains at least: - the application JAR file, - a JAR file for every dependency, - an application configuration file (an XML file with an XSD schema file), - Log4J configuration file (a single XML file). It is important that the application configuration file is not packaged inside the application JAR file - I could not change configuration in production otherwise. The Maven assembly plugin is used to package all those files into a single ZIP to allow convenient deploy at the target machine. - For every environment (e.g. development, test, acceptance, production) there is a single Maven profile. The configuration files contain property placeholders. When building the assembly, the values of properties used in the configuration files (e.g. the default configuration values) are resolved according to the active profile. - The question I have is how to store the builds to be available for deployment - so that I don't have to build the project every time I need to deploy the application to a new machine. To my understanding, a Nexus repository is typically used for that. I have found out though that a Maven repository is only capable of storing simple artifacts, not ZIP assemblies. I am convinced that there are plenty of projects that need external configuration files in addition to the application JARs. What is the commonly used way to handle my issue? Thank you in advance for all replies. Dusan R.
Re: Generating javadoc for a set of unrelated projects?
Hi org.apache.maven.user, I avoided this because I assumed that the modules of the aggregator would have to exist as subdirectories of the project. Is this actually the case? Yep, you'd have to have a working copy of each module in its own subdirectory. Your original statement was that you have a set of projects, with some interdependencies so it wasn't clear to me whether you want every project in question to link to all the others' javadoc, or whether you just have one downstream project that could link into all of the dependencies' existing javadoc sites. Hopefully you don't have circular dependencies (even indirectly) and the latter is sufficient. -Curtis On Fri, Jul 13, 2012 at 4:47 AM, org.apache.maven.u...@io7m.com wrote: On Thu, 12 Jul 2012 13:10:08 -0500 Curtis Rueden ctrue...@wisc.edu wrote: Hi org.apache.maven.user, What's the simplest way to generate (aggregated) javadoc for this set of projects? Is it enough that your javadocs cross-link with each other at their respective published locations? If so, you can add the links to the maven-javadoc-plugin configuration. E.g.: plugin artifactIdmaven-javadoc-plugin/artifactId version2.8.1/version configuration links linkhttps://pivot.apache.org/2.0.1/docs/api//link link http://help.eclipse.org/indigo/topic/org.eclipse.platform.doc.isv/reference/api/ /link /links /configuration /plugin Replacing the links with your published javadoc locations, of course. Yeah, that'll work. Thanks! I can't modify the pom files of the individual projects I haven't tested it, but presumably you could create a new aggregator POM that includes the individual projects as modules, and set the aggregator's javadoc configuration as above. Then run mvn site and wait for the magic. I avoided this because I assumed that the modules of the aggregator would have to exist as subdirectories of the project. Is this actually the case? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Issue-wise Crowdfunding platform for Maven
Hi all, I have set up a website where people can place small money bounties for open issues on Maven JIRA http://jira.codehaus.org/browse/MNG (or Jenkins, or Hibernate, or whatever). So far it's only got two real offers - and one of them I placed myself (JENKINS-9216: Make OpenID work with Google Apps accountshttp://www.freedomsponsors.com/core/issue/11/make-openid-work-with-google-apps-accounts ), but I really think that as it gets more popular, such a tool can have a big positive impact on a lot of open source projects, especially popular ones like Maven. If you think so too, I welcome you to use it -- www.freedomsponsors.com :-) Cheers Tony Lâmpada
snapshot built locally
I understand that a SNAPSHOT dependency will be pulled from my local repository, and once a day maven will make a check for a newer version in remote repositories known to the build. Is this behavior the same if the SNAPSHOT dependency in local was built and installed from a local build?
OT: Re: Issue-wise Crowdfunding platform for Maven
Tony, I hate to rain on your parade because it's a very good idea, but isn't this something that the Apache Foundation should also be collecting at least as much as you are collecting (3%) for the service? To keep things honest and since 3% is barely more than Paypal charges to intermediate the funds in the first place, I'd alternately suggest a Jira plugin project that Apache could use to manage this through Apache Jira itself. Because Apache is a large non-profit, it may be able to negotiate better terms with services like Paypal such that more of the money stays in the family. While this may not sound as glorious as running this yourself, as eventual founder and PMC of the project, you'll still get all the recognition for changing the world of OSS for the better and will never have to worry about someone else getting a lead on your idea (nobody will be able to give more to developers than a non-profit with 0% holdback will). $0.02... On Jul 13, 2012, at 11:38 PM, tony Tony wrote: Hi all, I have set up a website where people can place small money bounties for open issues on Maven JIRA http://jira.codehaus.org/browse/MNG (or Jenkins, or Hibernate, or whatever). So far it's only got two real offers - and one of them I placed myself (JENKINS-9216: Make OpenID work with Google Apps accountshttp://www.freedomsponsors.com/core/issue/11/make-openid-work-with-google-apps-accounts ), but I really think that as it gets more popular, such a tool can have a big positive impact on a lot of open source projects, especially popular ones like Maven. If you think so too, I welcome you to use it -- www.freedomsponsors.com :-) Cheers Tony Lâmpada - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: snapshot built locally
I understand that a SNAPSHOT dependency will be pulled from my local repository, and once a day maven will make a check for a newer version in remote repositories known to the build. Is this behavior the same if the SNAPSHOT dependency in local was built and installed from a local build? I don't understand the question. Maven will use the latest SNAPSHOT in your local repo cache, period. If this happens to be a built-locally SNAPSHOT, it will be used. If this happens to be a built-remotely-and-downloaded-from-corporate-repo SNAPSHOT (eg your local SNAPSHOT is older than this one), then it will be used -- until you build and install a newer one locally. The fun stuff happens when multiple people are working on branches of the same artifact... and colliding with each other in local and remote repos with their various jars... which causes some people to either lock down a given artifact to one person/group each day or insert a branch-id into the artifact-id or other things. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: OT: Re: Issue-wise Crowdfunding platform for Maven
Hi Brian, Actually this is exactly where we are aimed to. Since we do want to see open source projects growing from our initiative it just makes sense to get open-source communities (such as Apache) involved. Right now we're focused on getting the platform up and running so we can put together enough material for engaging into conversation. Thanks for getting involved! Cheers, On 13 July 2012 18:16, Brian Topping topp...@codehaus.org wrote: Tony, I hate to rain on your parade because it's a very good idea, but isn't this something that the Apache Foundation should also be collecting at least as much as you are collecting (3%) for the service? To keep things honest and since 3% is barely more than Paypal charges to intermediate the funds in the first place, I'd alternately suggest a Jira plugin project that Apache could use to manage this through Apache Jira itself. Because Apache is a large non-profit, it may be able to negotiate better terms with services like Paypal such that more of the money stays in the family. While this may not sound as glorious as running this yourself, as eventual founder and PMC of the project, you'll still get all the recognition for changing the world of OSS for the better and will never have to worry about someone else getting a lead on your idea (nobody will be able to give more to developers than a non-profit with 0% holdback will). $0.02... On Jul 13, 2012, at 11:38 PM, tony Tony wrote: Hi all, I have set up a website where people can place small money bounties for open issues on Maven JIRA http://jira.codehaus.org/browse/MNG (or Jenkins, or Hibernate, or whatever). So far it's only got two real offers - and one of them I placed myself (JENKINS-9216: Make OpenID work with Google Apps accounts http://www.freedomsponsors.com/core/issue/11/make-openid-work-with-google-apps-accounts ), but I really think that as it gets more popular, such a tool can have a big positive impact on a lot of open source projects, especially popular ones like Maven. If you think so too, I welcome you to use it -- www.freedomsponsors.com:-) Cheers Tony Lâmpada - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: OT: Re: Issue-wise Crowdfunding platform for Maven
Crowdfunding is the way of the future and will accelerate the growth of open source and proprietary software. Apache will have to come to grips with it since it is a way for companies to ensure that their priorities get to the top of the pile if they are only interested in providing money. It will erode the power of the PMC since private groups will be able to fund specific enhancements that have value to an audience rather than features that appeal to the developers. If the management of the Apache project leads the effort, it should be able to collect something but if someone else is doing the job, it is not clear where Apache fits in. This means that the PMC will have to get a structure in place to focus user financial contributions onto worthwhile projects and guarantee that specific functionality gets incorporated into the project. This will not replace the current collection of funds that are not dedicated or contingent on a specific result but will provide additional funding for specific features. Ron On 13/07/2012 5:16 PM, Brian Topping wrote: Tony, I hate to rain on your parade because it's a very good idea, but isn't this something that the Apache Foundation should also be collecting at least as much as you are collecting (3%) for the service? To keep things honest and since 3% is barely more than Paypal charges to intermediate the funds in the first place, I'd alternately suggest a Jira plugin project that Apache could use to manage this through Apache Jira itself. Because Apache is a large non-profit, it may be able to negotiate better terms with services like Paypal such that more of the money stays in the family. While this may not sound as glorious as running this yourself, as eventual founder and PMC of the project, you'll still get all the recognition for changing the world of OSS for the better and will never have to worry about someone else getting a lead on your idea (nobody will be able to give more to developers than a non-profit with 0% holdback will). $0.02... On Jul 13, 2012, at 11:38 PM, tony Tony wrote: Hi all, I have set up a website where people can place small money bounties for open issues on Maven JIRA http://jira.codehaus.org/browse/MNG (or Jenkins, or Hibernate, or whatever). So far it's only got two real offers - and one of them I placed myself (JENKINS-9216: Make OpenID work with Google Apps accountshttp://www.freedomsponsors.com/core/issue/11/make-openid-work-with-google-apps-accounts ), but I really think that as it gets more popular, such a tool can have a big positive impact on a lot of open source projects, especially popular ones like Maven. If you think so too, I welcome you to use it -- www.freedomsponsors.com :-) Cheers Tony Lâmpada - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Problem with maven and deleting files in a test case
Am 12.07.2012 23:19, schrieb Wayne Fay: With JUnit everthing is perfekt on Linux and Windows. With Maven it What version of JUnit and how are you calling it? works perfekt under Linux, but fails sometimes under Windows 7 64. What is the failure under Windows? Can you add code to trap that error and report the details? Do you have any idea why it fails sometimes but not always? I know there is an issue with file handling on Windows that does not exists on Linux, but wondering that JUnit do the trick and Maven don't do it (sometimes). Does anyone knows a solution, if it is a Maven problem? For good measure, I'd suggest adding config to your pom to specify the Surefire version: build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.12/version dependencies dependency groupIdorg.apache.maven.surefire/groupId artifactIdsurefire-junit47/artifactId version2.12/version /dependency /dependencies /plugin /plugins /build Windows is annoying for reasons like this so I try to stay on OSX and Linux whenever possible. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Damn, you made my day! Now everything works like I expected. Yes, I understand if you don't want to download and execute code like this. It was just a try to bring this thread fast forward. The maven-surefire-plugin-hint above was all I needed. I did the JUnit tests with version 4.8.1 using eclipse and just hit the run button some times with no error. If I do it with mvn clean install using the command prompt with the following pom, I got an error after a few hits on enter. modelVersion4.0.0/modelVersion groupIdtest/groupId artifactIdmaven-file-test/artifactId version0.0.1-SNAPSHOT/version packagingjar/packaging namemaven-file-test/name properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version4.8.1/version scopetest/scope /dependency /dependencies My code is quite simple. A method that writes a file and another one that deletes a file. The first test inside the test class writes the file, the second test case delete it. And I know that it may failed because of the underlying platform like the javadoc told, for example, in FileOutputStream. After I added a third test case with a loop around writing and deleting - which is much as faster as I can do it by pressing the run button inside an IDE ;) - and after I added maven-surefire-plugin to my pom like you told, I saw that both executions (IDE and command prompt) ends with an error. With the IDE after a while also and with the command prompt not as often as before. The different frequency of the error appearance made me mad. The next two questens I have to find out are: 1. What does the maven-surefire-plugin exactly do? It still fails, but not so much like without it. 2. Is there a way to avoid running tests with maven depends on the OS if I reach a level where no independent solution exists like loading a C-lib for example, don't care if it is a good idea? Your hint let my go in the right direction again. Thanks! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
jdk version detect error
I am running the netty project. when i run mvn clean install It crashed with an error: Detected JDK Version: 1.6.0-24 is not in the allowed range [1.7.0,) I first want to modify the pom file but It comments that: 1.7.0 jdk is needed,or may lead to problem So I update my jdk to 1.7.0 I have checked the java -version .It do be a 1.7.0 version! But maven still complain that the JDK version is 1.6.0. Why? -- View this message in context: http://maven.40175.n5.nabble.com/jdk-version-detect-error-tp5714118.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
