Re: Versions maven plugin
Howdy, sorry I missed this thread. But spotted when you closed this issue, so answered there: https://github.com/mojohaus/versions/issues/961#issuecomment-1946797974 On Sat, May 27, 2023 at 8:57 AM Andrzej wrote: > Hi all, > > I've been looking at Versions Maven Plugin and I can say that there are a > few places that could use some refactoring. > > For example, VersionDetails and AbstractArtifactVersions serve several > purposes: they seem to be both a collection of cached artifact versions, > but at the same time store the information on the current version (unless > they don't – like PropertyVersions which is a child of > AbstractArtifactVersions). On top of that, they offer plenty of different > utility methods for retrieving versions which may or not duplicate > themselves. > > So, let's suppose I wanted to refactor that a little bit: is it ok to use > Aether (like e.g. org.eclipse.aether.artifact.Artifact or > org.eclipse.aether.version.VersionRange) API there? Or should I be looking > somewhere else? > > Best regards, > Andrzej >
Re: Versions maven plugin
You'll need to know what the binary compatibility policy is for this plugin. Gary On Sat, May 27, 2023, 02:57 Andrzej wrote: > Hi all, > > I've been looking at Versions Maven Plugin and I can say that there are a > few places that could use some refactoring. > > For example, VersionDetails and AbstractArtifactVersions serve several > purposes: they seem to be both a collection of cached artifact versions, > but at the same time store the information on the current version (unless > they don't – like PropertyVersions which is a child of > AbstractArtifactVersions). On top of that, they offer plenty of different > utility methods for retrieving versions which may or not duplicate > themselves. > > So, let's suppose I wanted to refactor that a little bit: is it ok to use > Aether (like e.g. org.eclipse.aether.artifact.Artifact or > org.eclipse.aether.version.VersionRange) API there? Or should I be looking > somewhere else? > > Best regards, > Andrzej >
Versions maven plugin
Hi all, I've been looking at Versions Maven Plugin and I can say that there are a few places that could use some refactoring. For example, VersionDetails and AbstractArtifactVersions serve several purposes: they seem to be both a collection of cached artifact versions, but at the same time store the information on the current version (unless they don't – like PropertyVersions which is a child of AbstractArtifactVersions). On top of that, they offer plenty of different utility methods for retrieving versions which may or not duplicate themselves. So, let's suppose I wanted to refactor that a little bit: is it ok to use Aether (like e.g. org.eclipse.aether.artifact.Artifact or org.eclipse.aether.version.VersionRange) API there? Or should I be looking somewhere else? Best regards, Andrzej
[ANN] Versions Maven Plugin 2.11.0 Released
Hi, The Mojo team is pleased to announce the release of the Versions Maven Plugin version 2.11.0. https://www.mojohaus.org/versions-maven-plugin/ To get this update, simply specify the version in your project's plugin configuration: org.codehaus.mojo versions-maven-plugin 2.11.0 Release Notes https://github.com/mojohaus/versions-maven-plugin/releases/tag/versions-maven-plugin-2.11.0 Enjoy, The Mojo team. Stefan - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Versions Maven Plugin 2.10.0 Released
Hi, The Mojo team is pleased to announce the release of the Versions Maven Plugin version 2.10.0. https://www.mojohaus.org/versions-maven-plugin/ To get this update, simply specify the version in your project's plugin configuration: org.codehaus.mojo versions-maven-plugin 2.10.0 Release Notes https://github.com/mojohaus/versions-maven-plugin/releases/tag/versions-maven-plugin-2.10.0 Enjoy, The Mojo team. Stefan - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [ANN] Versions Maven Plugin 2.9.0 Released
Hi, first of all thanks a lot for the release. Unfortunately, I also experienced display-plugin-updates hanging and reported this in https://github.com/mojohaus/versions-maven-plugin/issues/538 <https://github.com/mojohaus/versions-maven-plugin/issues/538>. Hopefully this regression can be fixed soon. Konrad > On 21. Jan 2022, at 12:28, Delany wrote: > > Hi. I still can't display plugin updates with the latest version of the > plugin (2.9.0) > > `./mvnw -N versions:display-plugin-updates -DgenerateBackupPoms=false -X` > > In the output I see > > [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for > apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository). > > [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for > snapshots (http://snapshots.maven.codehaus.org/maven2). > > [DEBUG] Using mirror presto-central ( > http://presto:8081/repository/maven-central/) for central ( > http://repo1.maven.org/maven2). > > [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for > apache.snapshots (http://people.apache.org/maven-snapshot-repository). > > Presto is mine, but what are these other repositories? > > And further down > > [DEBUG] super-pom version map > > >org.apache.maven.plugins:maven-clean-plugin:2.5 > > >org.apache.maven.plugins:maven-install-plugin:2.4 > > >org.apache.maven.plugins:maven-deploy-plugin:2.7 > > >org.apache.maven.plugins:maven-site-plugin:3.3 > > >org.apache.maven.plugins:maven-antrun-plugin:1.3 > > >org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5 > > >org.apache.maven.plugins:maven-dependency-plugin:2.8 > > >org.apache.maven.plugins:maven-release-plugin:2.5.3 > > >org.apache.maven.plugins:maven-source-plugin:null > > >org.apache.maven.plugins:maven-javadoc-plugin:null > > > [DEBUG] parent version map > > > [DEBUG] aggregate version map > > >org.apache.maven.plugins:maven-clean-plugin:2.5 > > >org.apache.maven.plugins:maven-release-plugin:2.5.3 > > >org.apache.maven.plugins:maven-install-plugin:2.4 > > >org.apache.maven.plugins:maven-dependency-plugin:2.8 > > >org.apache.maven.plugins:maven-site-plugin:3.3 > > >org.apache.maven.plugins:maven-source-plugin:null > > >org.apache.maven.plugins:maven-javadoc-plugin:null > > >org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5 > > >org.apache.maven.plugins:maven-deploy-plugin:2.7 > > >org.apache.maven.plugins:maven-antrun-plugin:1.3 > > > [DEBUG] final aggregate version map > > >org.apache.maven.plugins:maven-release-plugin:2.5.3 > > > org.apache.maven.plugins:maven-javadoc-plugin:null > > at which point it hangs using all of a CPU core and no network. What's up > here? > > Thanks, > Delany > > > On Fri, 21 Jan 2022 at 12:05, Stefan Seifert > wrote: > >> Hi, >> >> The Mojo team is pleased to announce the release of the Versions Maven >> Plugin version 2.9.0. >> >> The Versions Plugin is used when you want to manage the versions of >> artifacts in a project's POM. >> >> https://www.mojohaus.org/versions-maven-plugin/ >> >> To get this update, simply specify the version in your project's plugin >> configuration: >> >> >> org.codehaus.mojo >> versions-maven-plugin >> 2.9.0 >> >> >> Release Notes >> >> https://github.com/mojohaus/versions-maven-plugin/releases/tag/versions-maven-plugin-2.9.0 >> >> Enjoy, >> >> The Mojo team. >> >> stefan >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >>
Re: [ANN] Versions Maven Plugin 2.9.0 Released
Hi. I still can't display plugin updates with the latest version of the plugin (2.9.0) `./mvnw -N versions:display-plugin-updates -DgenerateBackupPoms=false -X` In the output I see [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository). [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for snapshots (http://snapshots.maven.codehaus.org/maven2). [DEBUG] Using mirror presto-central ( http://presto:8081/repository/maven-central/) for central ( http://repo1.maven.org/maven2). [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for apache.snapshots (http://people.apache.org/maven-snapshot-repository). Presto is mine, but what are these other repositories? And further down [DEBUG] super-pom version map org.apache.maven.plugins:maven-clean-plugin:2.5 org.apache.maven.plugins:maven-install-plugin:2.4 org.apache.maven.plugins:maven-deploy-plugin:2.7 org.apache.maven.plugins:maven-site-plugin:3.3 org.apache.maven.plugins:maven-antrun-plugin:1.3 org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5 org.apache.maven.plugins:maven-dependency-plugin:2.8 org.apache.maven.plugins:maven-release-plugin:2.5.3 org.apache.maven.plugins:maven-source-plugin:null org.apache.maven.plugins:maven-javadoc-plugin:null [DEBUG] parent version map [DEBUG] aggregate version map org.apache.maven.plugins:maven-clean-plugin:2.5 org.apache.maven.plugins:maven-release-plugin:2.5.3 org.apache.maven.plugins:maven-install-plugin:2.4 org.apache.maven.plugins:maven-dependency-plugin:2.8 org.apache.maven.plugins:maven-site-plugin:3.3 org.apache.maven.plugins:maven-source-plugin:null org.apache.maven.plugins:maven-javadoc-plugin:null org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5 org.apache.maven.plugins:maven-deploy-plugin:2.7 org.apache.maven.plugins:maven-antrun-plugin:1.3 [DEBUG] final aggregate version map org.apache.maven.plugins:maven-release-plugin:2.5.3 org.apache.maven.plugins:maven-javadoc-plugin:null at which point it hangs using all of a CPU core and no network. What's up here? Thanks, Delany On Fri, 21 Jan 2022 at 12:05, Stefan Seifert wrote: > Hi, > > The Mojo team is pleased to announce the release of the Versions Maven > Plugin version 2.9.0. > > The Versions Plugin is used when you want to manage the versions of > artifacts in a project's POM. > > https://www.mojohaus.org/versions-maven-plugin/ > > To get this update, simply specify the version in your project's plugin > configuration: > > > org.codehaus.mojo > versions-maven-plugin > 2.9.0 > > > Release Notes > > https://github.com/mojohaus/versions-maven-plugin/releases/tag/versions-maven-plugin-2.9.0 > > Enjoy, > > The Mojo team. > > stefan > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
[ANN] Versions Maven Plugin 2.9.0 Released
Hi, The Mojo team is pleased to announce the release of the Versions Maven Plugin version 2.9.0. The Versions Plugin is used when you want to manage the versions of artifacts in a project's POM. https://www.mojohaus.org/versions-maven-plugin/ To get this update, simply specify the version in your project's plugin configuration: org.codehaus.mojo versions-maven-plugin 2.9.0 Release Notes https://github.com/mojohaus/versions-maven-plugin/releases/tag/versions-maven-plugin-2.9.0 Enjoy, The Mojo team. stefan - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Fwd: [versions-maven-plugin] how to update version property in pom.xml?
Here is my pom.xml:
1. mvn versions:update-properties works fine , the properties updated
2. mvn versions:use-next-snapshots not work
[INFO] --- versions-maven-plugin:2.8.1:use-next-snapshots (default-cli) @
test-mymvnversion ---
[INFO] Incremental version changes allowed
[INFO] Ignoring reactor dependency:
com.***.example:submodtest:jar:1.1.1-SNAPSHOT
[INFO] Ignoring com.***.example:afeaturemod:jar:[1.3.0] as the version
number is too short
[INFO] Incremental version changes allowed
How to update the property for next snapshots?
ref:
https://www.mojohaus.org/versions-maven-plugin/examples/update-properties.html
afeaturemod.version had updated to 1.3.1-SNAPSHOT already.
if I use:
com.panda.example
afeaturemod
1.3.0
It works fine.
my current pom.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
https://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0
pom
com.panda.example
example-root-pom
1.0.0-SNAPSHOT
com.panda.example
test-mymvnversion
1.1.1-SNAPSHOT
test-mymvnversion
submodtest
1.3.0
com.panda.example
submodtest
${project.version}
com.panda.example
afeaturemod
[${afeaturemod.version}]
[ANN] Versions Maven Plugin 2.8.1 released
Hi, The Mojo team is pleased to announce the release of the Versions Plugin version 2.8.1. The Versions Plugin is used when you want to manage the versions of artifacts in a project's POM. https://www.mojohaus.org/versions-maven-plugin/ To get this update, simply specify the version in your project's plugin configuration: org.codehaus.mojo versions-maven-plugin 2.8.1 Release Notes: https://github.com/mojohaus/versions-maven-plugin/releases/tag/versions-maven-plugin-2.8.1 Enjoy, The Mojo team. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[versions-maven-plugin] Ignored usage of properties in child POMs
Hello! I’m using versions-maven-plugin 2.7 and I have an issue with versions
defined as properties in a multi-module project.
I have all version properties defined in the parent POM, then I have several
child POMs defining dependency and plugin management.
When running `display-property-updates` on the parent POM, I would expect the
plugin to resolve the property usage on its children; instead, it returns:
```
This project does not have any properties associated with versions.
```
Example POMs:
```xml
my.group
my-parent
1.0.0
pom
1.0.0
```
```xml
my.group
my-parent
1.0.0
my-artifact
pom
foo.group
foo-artifact
${version.foo}
```
Output of plugin execution:
```
~/my-parent$ mvn versions:display-property-updates
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] my-parent [pom]
[INFO] my-artifact[pom]
[INFO]
[INFO] -< my.group:my-parent >-
[INFO] Building my-parent 1.0.0 [1/2]
[INFO] [ pom ]-
[INFO]
[INFO] --- versions-maven-plugin:2.7:display-property-updates (default-cli) @
my-parent ---
[INFO]
[INFO] This project does not have any properties associated with versions.
[INFO]
[INFO]
[INFO] ---< my.group:my-artifact >-
[INFO] Building my-artifact 1.0.0 [2/2]
[INFO] [ pom ]-
[INFO]
[INFO] --- versions-maven-plugin:2.7:display-property-updates (default-cli) @
my-artifact ---
[INFO]
[INFO] This project does not have any properties associated with versions.
[INFO]
[INFO] my-parent .. SUCCESS [ 0.484 s]
[INFO] my-artifact SUCCESS [ 0.007 s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 0.491 s
[INFO] Finished at: 2019-09-11T10:46:53+02:00
[INFO]
```
GitHub issue: https://github.com/mojohaus/versions-maven-plugin/issues/367
<https://github.com/mojohaus/versions-maven-plugin/issues/367>
versions-maven-plugin release?
Hi, Can someone please make a new release of the versions-maven-plugin? I and other people keep hitting this fixed issue: https://github.com/mojohaus/versions-maven-plugin/issues/5 Thank you.
versions-maven-plugin not updating properties any more
Hi all! I have two multi-module projects where the first one is a dependency of the second one. Usually before a release of the second one also the first one is released and the second one has to update the dependency-version which is set via a property. For this update I use versions-maven-plugin (v2.1) to do the update: mvn -DincludeProperties=mylib.version versions:update-properties This used to work, when the released version was for example 1.0-beta-13 and the new development version was 1.0-beta-14-SNAPSHOT. After I changed the new development version to always be 1.0-SNAPSHOT the update via versions-maven-plugin stopped working. I get debugging output like state from somebody else on StackOverflow: http://stackoverflow.com/questions/25034556/how-can-i-update-a-property-in-a-maven-pom For me this means version 1.0-beta-13/14 are found but than it says current winner is: null and leaves the version unchanged. Could this be a bug or am I doing something wrong? - martin signature.asc Description: PGP signature
RE: versions maven plugin
I wouldn't have normally chimed in here against Stephen (He knows what he is on about) however... IMHO Staging only works with very small teams with dedicated infrastructure (in which case QC generally are ok with a rebuild!). If you have larger teams and share infrastructure (repo manager, CI) across projects (and binaries across teams) then that way will lead to madness. Or to put it another way Staging with any human intervention is evil. Staging without human intervention is doing things too late - you should know before hand that your code is good to go (if you use releases) - and if you are doing things without human intervention then you should know up front that the code is good to go - which means you don't need staging (apart form for an atomic deployment of a multi module build; but there are other ways to do that now). Or to put a contrived (yet realistic) example on this - Consider a shared library Y. You have no auto testing of it so its only tested inside products (otherwise you know its good to go - and wouldn't release RCs). Library Y is in a stage at version 1.2.3 This library is picked up from the stage and placed into a product Z (inside say an RPM) Z is released into a stage The library is picked up in product X (inside say another RPM) QC start testing Z. QC test X and it reveals a bug in Y. Both stages (Y and X) are dropped QC finish testing Z from the stage and then promote it as its good. The Y developers re-spin 1.2.3... Z is released into the field with a verison of Y that doesn't match what's at some point going to be in the repo. The build Z is unreproducible - this is the worst possible situation to be in, Now there are those that say - your staging rules on your MRM should check the dependencies - but now you are at the behest of your MRM. Nexus certainly can't do this without custom effort on your side - and then you will have to intimately have full knowledge of the inside of the build that produced this artifact - what groups on your MRM use, what version of maven.. You can't just unpack and look at the use the dependencies - what about shaded deps. To do all this work post build is IMHO nigh on impossible. /James -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: 20 January 2014 19:40 To: Maven Users List Subject: Re: versions maven plugin Consider staging support on your repo manager On Monday, 20 January 2014, alejandro.e...@miranda.com wrote: I didn't. QA is not happy about rebuilding the system once it's been approved so we have to release the RC as approved. So all our versions are always RC-X-SNAPSHOT or RC-X Alejandro Endo | Software Designer/Concepteur de logiciels From: Stephen Connolly stephen.alan.conno...@gmail.com javascript:; To: Maven Users List users@maven.apache.org javascript:;, Date: 2014-01-20 13:50 Subject:Re: versions maven plugin How did you turn your RC into a released version? (I would do it with the release plugin and just verify the SCM changelog is unchanged) On Monday, 20 January 2014, alejandro.e...@miranda.com javascript:; wrote: Thank you Stephen. Are there any other ways to stabilize my dependencies then? i have 300 poms all depending on the released+1 development version. This must be a common use-case when using RCs, no? you increase all your versions to your next RC-2-SNAPSHOT as soon as you create your RC-1, but if that RC-1 happens to be released, then all your poms will be depending on the SNAPSHOT of an RC-2 that will never be made so you have to downgrade your dependency versions Am I doing something out of the ordinary here? Alejandro Endo | Software Designer/Concepteur de logiciels From: Stephen Connolly stephen.alan.conno...@gmail.com javascript:;javascript: ; To: Maven Users List users@maven.apache.org javascript:;javascript:;, Date: 2014-01-20 12:34 Subject:Re: versions maven plugin v-m-p does not roll back version numbers On 20 January 2014 16:59, alejandro.e...@miranda.com javascript:;javascript:; wrote: Not sure if this is the right list for codehaus plugins. If not I apologize I have a pom with this dependencies dependency groupIdfoo.blah/groupId artifactIdbar/artifactId version1.2.0-RC-7-SNAPSHOT/version /dependency /dependencies I want to run the versions plugin to replace 1.2.0-RC-7-SNAPSHOT with the version we actually released of the code, which is 1.2.0-RC-6. Looking at the available mojos, it seems like versions:use-latest-releases is the right one to use. In the matrix here it says that this goal will modify -SNAPSHOT dependencies
Re: versions maven plugin
On 21 January 2014 09:41, James Nord (jnord) jn...@cisco.com wrote: I wouldn't have normally chimed in here against Stephen (He knows what he is on about) however... IMHO Staging only works with very small teams with dedicated infrastructure (in which case QC generally are ok with a rebuild!). If you have larger teams and share infrastructure (repo manager, CI) across projects (and binaries across teams) then that way will lead to madness. Or to put it another way Staging with any human intervention is evil. Staging without human intervention is doing things too late - you should know before hand that your code is good to go (if you use releases) - and if you are doing things without human intervention then you should know up front that the code is good to go - which means you don't need staging (apart form for an atomic deployment of a multi module build; but there are other ways to do that now). Or to put a contrived (yet realistic) example on this - Consider a shared library Y. You have no auto testing of it so its only tested inside products (otherwise you know its good to go - and wouldn't release RCs). Library Y is in a stage at version 1.2.3 This library is picked up from the stage and placed into a product Z (inside say an RPM) If you are doing this then you are using staging wrong IMHO. A stage should *only* be used for either testing the staged release *or* for where there is a synchronized deliverable that must be built from a different machine, e.g. the windows .DLL and the linux .so's The case of Z may be OK as Z may be an arch specific component... but you are calling it a product, so if it is a product then you should have closed and released the library Y stage *before* you consume from Z Z is released into a stage The library is picked up in product X (inside say another RPM) QC start testing Z. QC test X and it reveals a bug in Y. Both stages (Y and X) are dropped QC finish testing Z from the stage and then promote it as its good. The Y developers re-spin 1.2.3... Well the issue here is that you should only stage the last layer. In this example Y cannot be tested on its own, so there is no point spinning RCs, etc. You just have to bite the bullet and cut a release. It doesn't matter whether you call the release 1.5-RC-1 or 1.5.0 because if you need to respin, you'll be bumping another version anyway. Where staging matters is at the last, publically visible, layer... i.e. Z. You use staging for Z and just spin version numbers and releases for everything else. If Y and Z are in the same release root... then they both get staged. If they are in separate release roots, then Y just bangs out releases and Z has staging. More complex is when both Y and Z are public... i.e. Y is the API client that Z uses... well in that case how is a broken 1.5-RC-1 being out there any different from a broken 1.5.0... the solution is obvious... you need tests that you can trust... get those tests and then apply staging on Y Z is released into the field with a verison of Y that doesn't match what's at some point going to be in the repo. The build Z is unreproducible - this is the worst possible situation to be in, Now there are those that say - your staging rules on your MRM should check the dependencies - but now you are at the behest of your MRM. Nexus certainly can't do this without custom effort on your side - and then you will have to intimately have full knowledge of the inside of the build that produced this artifact - what groups on your MRM use, what version of maven.. You can't just unpack and look at the use the dependencies - what about shaded deps. To do all this work post build is IMHO nigh on impossible. /James -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: 20 January 2014 19:40 To: Maven Users List Subject: Re: versions maven plugin Consider staging support on your repo manager On Monday, 20 January 2014, alejandro.e...@miranda.com wrote: I didn't. QA is not happy about rebuilding the system once it's been approved so we have to release the RC as approved. So all our versions are always RC-X-SNAPSHOT or RC-X Alejandro Endo | Software Designer/Concepteur de logiciels From: Stephen Connolly stephen.alan.conno...@gmail.com javascript:; To: Maven Users List users@maven.apache.org javascript:;, Date: 2014-01-20 13:50 Subject:Re: versions maven plugin How did you turn your RC into a released version? (I would do it with the release plugin and just verify the SCM changelog is unchanged) On Monday, 20 January 2014, alejandro.e...@miranda.com javascript:; wrote: Thank you Stephen. Are there any other ways to stabilize my dependencies then? i have 300 poms all depending on the released+1 development version. This must be a common use-case when using RCs, no? you
RE: versions maven plugin
Or to put a contrived (yet realistic) example on this - Consider a shared library Y. You have no auto testing of it so its only tested inside products (otherwise you know its good to go - and wouldn't release RCs). Library Y is in a stage at version 1.2.3 This library is picked up from the stage and placed into a product Z (inside say an RPM) If you are doing this then you are using staging wrong IMHO. A stage should *only* be used for either testing the staged release *or* for where there is a synchronized deliverable that must be built from a different machine, e.g. the windows .DLL and the linux .so's But it did not sound like that was the original authors request as he was using RCs of dependencies (libraries). So I felt like the solution of staging here would leave to a somewhat similar example to that above. /James - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: versions maven plugin
It sounded like a single reactor release of everything to me... in which case staging is fine On 21 January 2014 11:07, James Nord (jnord) jn...@cisco.com wrote: Or to put a contrived (yet realistic) example on this - Consider a shared library Y. You have no auto testing of it so its only tested inside products (otherwise you know its good to go - and wouldn't release RCs). Library Y is in a stage at version 1.2.3 This library is picked up from the stage and placed into a product Z (inside say an RPM) If you are doing this then you are using staging wrong IMHO. A stage should *only* be used for either testing the staged release *or* for where there is a synchronized deliverable that must be built from a different machine, e.g. the windows .DLL and the linux .so's But it did not sound like that was the original authors request as he was using RCs of dependencies (libraries). So I felt like the solution of staging here would leave to a somewhat similar example to that above. /James - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
versions maven plugin
Not sure if this is the right list for codehaus plugins. If not I apologize I have a pom with this dependencies dependency groupIdfoo.blah/groupId artifactIdbar/artifactId version1.2.0-RC-7-SNAPSHOT/version /dependency /dependencies I want to run the versions plugin to replace 1.2.0-RC-7-SNAPSHOT with the version we actually released of the code, which is 1.2.0-RC-6. Looking at the available mojos, it seems like versions:use-latest-releases is the right one to use. In the matrix here it says that this goal will modify -SNAPSHOT dependencies. Well, it doesn't. If i instead set the version to 1.2.0-RC-3 (no snapshot), the mojo does update the dependency to 1.2.0-RC-6 so I don't know if this is just the documentation being wrong. I also tried use-latest-versions without success Any idea how to do this? I just want to change the dependencies (which are currently SNAPSHOT due to the m-release-p) to the latest released versions Thank you, Alejandro Endo | Software Designer/Concepteur de logiciels DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.
Re: versions maven plugin
v-m-p does not roll back version numbers On 20 January 2014 16:59, alejandro.e...@miranda.com wrote: Not sure if this is the right list for codehaus plugins. If not I apologize I have a pom with this dependencies dependency groupIdfoo.blah/groupId artifactIdbar/artifactId version1.2.0-RC-7-SNAPSHOT/version /dependency /dependencies I want to run the versions plugin to replace 1.2.0-RC-7-SNAPSHOT with the version we actually released of the code, which is 1.2.0-RC-6. Looking at the available mojos, it seems like versions:use-latest-releases is the right one to use. In the matrix here it says that this goal will modify -SNAPSHOT dependencies. Well, it doesn't. If i instead set the version to 1.2.0-RC-3 (no snapshot), the mojo does update the dependency to 1.2.0-RC-6 so I don't know if this is just the documentation being wrong. I also tried use-latest-versions without success Any idea how to do this? I just want to change the dependencies (which are currently SNAPSHOT due to the m-release-p) to the latest released versions Thank you, Alejandro Endo | Software Designer/Concepteur de logiciels DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.
Re: versions maven plugin
Thank you Stephen. Are there any other ways to stabilize my dependencies then? i have 300 poms all depending on the released+1 development version. This must be a common use-case when using RCs, no? you increase all your versions to your next RC-2-SNAPSHOT as soon as you create your RC-1, but if that RC-1 happens to be released, then all your poms will be depending on the SNAPSHOT of an RC-2 that will never be made so you have to downgrade your dependency versions Am I doing something out of the ordinary here? Alejandro Endo | Software Designer/Concepteur de logiciels From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Users List users@maven.apache.org, Date: 2014-01-20 12:34 Subject:Re: versions maven plugin v-m-p does not roll back version numbers On 20 January 2014 16:59, alejandro.e...@miranda.com wrote: Not sure if this is the right list for codehaus plugins. If not I apologize I have a pom with this dependencies dependency groupIdfoo.blah/groupId artifactIdbar/artifactId version1.2.0-RC-7-SNAPSHOT/version /dependency /dependencies I want to run the versions plugin to replace 1.2.0-RC-7-SNAPSHOT with the version we actually released of the code, which is 1.2.0-RC-6. Looking at the available mojos, it seems like versions:use-latest-releases is the right one to use. In the matrix here it says that this goal will modify -SNAPSHOT dependencies. Well, it doesn't. If i instead set the version to 1.2.0-RC-3 (no snapshot), the mojo does update the dependency to 1.2.0-RC-6 so I don't know if this is just the documentation being wrong. I also tried use-latest-versions without success Any idea how to do this? I just want to change the dependencies (which are currently SNAPSHOT due to the m-release-p) to the latest released versions Thank you, Alejandro Endo | Software Designer/Concepteur de logiciels DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.
Re: versions maven plugin
How did you turn your RC into a released version? (I would do it with the release plugin and just verify the SCM changelog is unchanged) On Monday, 20 January 2014, alejandro.e...@miranda.com wrote: Thank you Stephen. Are there any other ways to stabilize my dependencies then? i have 300 poms all depending on the released+1 development version. This must be a common use-case when using RCs, no? you increase all your versions to your next RC-2-SNAPSHOT as soon as you create your RC-1, but if that RC-1 happens to be released, then all your poms will be depending on the SNAPSHOT of an RC-2 that will never be made so you have to downgrade your dependency versions Am I doing something out of the ordinary here? Alejandro Endo | Software Designer/Concepteur de logiciels From: Stephen Connolly stephen.alan.conno...@gmail.com javascript:; To: Maven Users List users@maven.apache.org javascript:;, Date: 2014-01-20 12:34 Subject:Re: versions maven plugin v-m-p does not roll back version numbers On 20 January 2014 16:59, alejandro.e...@miranda.com javascript:; wrote: Not sure if this is the right list for codehaus plugins. If not I apologize I have a pom with this dependencies dependency groupIdfoo.blah/groupId artifactIdbar/artifactId version1.2.0-RC-7-SNAPSHOT/version /dependency /dependencies I want to run the versions plugin to replace 1.2.0-RC-7-SNAPSHOT with the version we actually released of the code, which is 1.2.0-RC-6. Looking at the available mojos, it seems like versions:use-latest-releases is the right one to use. In the matrix here it says that this goal will modify -SNAPSHOT dependencies. Well, it doesn't. If i instead set the version to 1.2.0-RC-3 (no snapshot), the mojo does update the dependency to 1.2.0-RC-6 so I don't know if this is just the documentation being wrong. I also tried use-latest-versions without success Any idea how to do this? I just want to change the dependencies (which are currently SNAPSHOT due to the m-release-p) to the latest released versions Thank you, Alejandro Endo | Software Designer/Concepteur de logiciels DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. -- Sent from my phone
Re: versions maven plugin
I didn't. QA is not happy about rebuilding the system once it's been approved so we have to release the RC as approved. So all our versions are always RC-X-SNAPSHOT or RC-X Alejandro Endo | Software Designer/Concepteur de logiciels From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Users List users@maven.apache.org, Date: 2014-01-20 13:50 Subject:Re: versions maven plugin How did you turn your RC into a released version? (I would do it with the release plugin and just verify the SCM changelog is unchanged) On Monday, 20 January 2014, alejandro.e...@miranda.com wrote: Thank you Stephen. Are there any other ways to stabilize my dependencies then? i have 300 poms all depending on the released+1 development version. This must be a common use-case when using RCs, no? you increase all your versions to your next RC-2-SNAPSHOT as soon as you create your RC-1, but if that RC-1 happens to be released, then all your poms will be depending on the SNAPSHOT of an RC-2 that will never be made so you have to downgrade your dependency versions Am I doing something out of the ordinary here? Alejandro Endo | Software Designer/Concepteur de logiciels From: Stephen Connolly stephen.alan.conno...@gmail.com javascript: ; To: Maven Users List users@maven.apache.org javascript:;, Date: 2014-01-20 12:34 Subject:Re: versions maven plugin v-m-p does not roll back version numbers On 20 January 2014 16:59, alejandro.e...@miranda.com javascript:; wrote: Not sure if this is the right list for codehaus plugins. If not I apologize I have a pom with this dependencies dependency groupIdfoo.blah/groupId artifactIdbar/artifactId version1.2.0-RC-7-SNAPSHOT/version /dependency /dependencies I want to run the versions plugin to replace 1.2.0-RC-7-SNAPSHOT with the version we actually released of the code, which is 1.2.0-RC-6. Looking at the available mojos, it seems like versions:use-latest-releases is the right one to use. In the matrix here it says that this goal will modify -SNAPSHOT dependencies. Well, it doesn't. If i instead set the version to 1.2.0-RC-3 (no snapshot), the mojo does update the dependency to 1.2.0-RC-6 so I don't know if this is just the documentation being wrong. I also tried use-latest-versions without success Any idea how to do this? I just want to change the dependencies (which are currently SNAPSHOT due to the m-release-p) to the latest released versions Thank you, Alejandro Endo | Software Designer/Concepteur de logiciels DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. -- Sent from my phone DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.
Re: versions maven plugin
Consider staging support on your repo manager On Monday, 20 January 2014, alejandro.e...@miranda.com wrote: I didn't. QA is not happy about rebuilding the system once it's been approved so we have to release the RC as approved. So all our versions are always RC-X-SNAPSHOT or RC-X Alejandro Endo | Software Designer/Concepteur de logiciels From: Stephen Connolly stephen.alan.conno...@gmail.com javascript:; To: Maven Users List users@maven.apache.org javascript:;, Date: 2014-01-20 13:50 Subject:Re: versions maven plugin How did you turn your RC into a released version? (I would do it with the release plugin and just verify the SCM changelog is unchanged) On Monday, 20 January 2014, alejandro.e...@miranda.com javascript:; wrote: Thank you Stephen. Are there any other ways to stabilize my dependencies then? i have 300 poms all depending on the released+1 development version. This must be a common use-case when using RCs, no? you increase all your versions to your next RC-2-SNAPSHOT as soon as you create your RC-1, but if that RC-1 happens to be released, then all your poms will be depending on the SNAPSHOT of an RC-2 that will never be made so you have to downgrade your dependency versions Am I doing something out of the ordinary here? Alejandro Endo | Software Designer/Concepteur de logiciels From: Stephen Connolly stephen.alan.conno...@gmail.com javascript:;javascript: ; To: Maven Users List users@maven.apache.org javascript:;javascript:;, Date: 2014-01-20 12:34 Subject:Re: versions maven plugin v-m-p does not roll back version numbers On 20 January 2014 16:59, alejandro.e...@miranda.com javascript:;javascript:; wrote: Not sure if this is the right list for codehaus plugins. If not I apologize I have a pom with this dependencies dependency groupIdfoo.blah/groupId artifactIdbar/artifactId version1.2.0-RC-7-SNAPSHOT/version /dependency /dependencies I want to run the versions plugin to replace 1.2.0-RC-7-SNAPSHOT with the version we actually released of the code, which is 1.2.0-RC-6. Looking at the available mojos, it seems like versions:use-latest-releases is the right one to use. In the matrix here it says that this goal will modify -SNAPSHOT dependencies. Well, it doesn't. If i instead set the version to 1.2.0-RC-3 (no snapshot), the mojo does update the dependency to 1.2.0-RC-6 so I don't know if this is just the documentation being wrong. I also tried use-latest-versions without success Any idea how to do this? I just want to change the dependencies (which are currently SNAPSHOT due to the m-release-p) to the latest released versions Thank you, Alejandro Endo | Software Designer/Concepteur de logiciels DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. -- Sent from my phone DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. -- Sent from my phone
Re: versions maven plugin
Possibly using 1.0-SNAPSHOT instead of 1.0-RC-SNAPSHOT as your naming rule would make it easier: you're working towards 1.0 and on the path to this release you cut a few RCs: 1.0-RC-1, 1.0-RC-2, etc. Le 20 janv. 2014 19:34, alejandro.e...@miranda.com a écrit : Thank you Stephen. Are there any other ways to stabilize my dependencies then? i have 300 poms all depending on the released+1 development version. This must be a common use-case when using RCs, no? you increase all your versions to your next RC-2-SNAPSHOT as soon as you create your RC-1, but if that RC-1 happens to be released, then all your poms will be depending on the SNAPSHOT of an RC-2 that will never be made so you have to downgrade your dependency versions Am I doing something out of the ordinary here? Alejandro Endo | Software Designer/Concepteur de logiciels From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Users List users@maven.apache.org, Date: 2014-01-20 12:34 Subject:Re: versions maven plugin v-m-p does not roll back version numbers On 20 January 2014 16:59, alejandro.e...@miranda.com wrote: Not sure if this is the right list for codehaus plugins. If not I apologize I have a pom with this dependencies dependency groupIdfoo.blah/groupId artifactIdbar/artifactId version1.2.0-RC-7-SNAPSHOT/version /dependency /dependencies I want to run the versions plugin to replace 1.2.0-RC-7-SNAPSHOT with the version we actually released of the code, which is 1.2.0-RC-6. Looking at the available mojos, it seems like versions:use-latest-releases is the right one to use. In the matrix here it says that this goal will modify -SNAPSHOT dependencies. Well, it doesn't. If i instead set the version to 1.2.0-RC-3 (no snapshot), the mojo does update the dependency to 1.2.0-RC-6 so I don't know if this is just the documentation being wrong. I also tried use-latest-versions without success Any idea how to do this? I just want to change the dependencies (which are currently SNAPSHOT due to the m-release-p) to the latest released versions Thank you, Alejandro Endo | Software Designer/Concepteur de logiciels DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.
Re: [ANN] Versions Maven Plugin 2.0 released
Responding to all, as MVERSIONS-200 is important enough to flag the
potential issue if you are using deprecated properties (the ones that Maven
3 warns you about if you use them)
@Dennis Wheeler: I suspect you have hit
https://jira.codehaus.org/browse/MVERSIONS-200
The right thing to do is to update your poms replacing:
${pom.parent.groupId} with ${project.parent.groupId}
${pom.parent.artifactId} with ${project.parent.artifactId}
${pom.parent.version} with ${project.parent.version}
${pom.groupId} with ${project.groupId},
${pom.artifactId} with ${project.artifactId},
${pom.version} with ${project.version},
${parent.groupId} with ${project.parent.groupId}
${parent.artifactId} with ${project.parent.artifactId}
${parent.version} with ${project.parent.version}
${groupId} with ${project.groupId},
${artifactId} with ${project.artifactId},
${version} with ${project.version},
as that will ensure that your poms are compatibile with future versions of
Maven.
It is still to be decided whether to roll a patch release of 2.0 with
workaround code for this (use of deprecated properties) edge case.
-Stephen
On 28 November 2012 23:31, Wheeler, Dennis dwhee...@cobaltgroup.com wrote:
While I would love to assist, this issue has not been consistently
reproducible. It hasn't yet failed on our automated trunk builds, but
consistently fails on our automated branch builds (it consistently fails
for me locally both in the trunk and the branch, but the project's primary
developer claims is doesn't fail for him at all (and I don't yet believe
he's using the exact same steps -- I think he only wants access to our
automated servers)).
I am extremely backlogged with other pressing tasks, and my boss doesn't
want me to spend the time debugging this issue any further now that we
have a workaround solution. Not to mention that we're working within a
closed source environment and I'm unsure about how much of our build logs
and environment info we can share.
Perhaps I can pass this off to one of our other developers who is also
more experienced using maven who can then help debug and better report on
the NPE.
I'm just guessing (and its just a wild unfounded guess at this point),
that our project contains some circular dependencies and the new versions
plugin is attempting to be more strict in that area.
Thanks for all the assistance.
On 11/28/12 5:18 AM, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
Can you please raise a JIRA for the NPE
On 28 November 2012 08:04, Wheeler, Dennis dwhee...@cobaltgroup.com
wrote:
Someone please help me from navigating through the forest of no return,
that is Google, and tell me how to force our projects back to using the
older 1.2 version of the Versions plugin, instead of this newer 2.0
version which is now giving us null pointer exceptions with this simple
command:
mvn -U versions:set -DnewVersion=12345
I don't really know anything about maven myself, I only plugin what the
devs give me into our build configuration system.
Can I make a global setting in the settings.xml, or does it have to be
in
each project's pom.xml?
Dennis Wheeler
Release Engineer II
ADP Digital Marketing Solutions
p 206.219.8049 | c 206.375.6781 | e dwhee...@cobalt.com
http://www.cobalt.com/
Join the conversation facebook http://www.facebook.com/#!/adpdmc|
twitter http://twitter.com/#!/adp_cobalt | blog
http://www.digitalmileage.com/
This message and any attachments are intended only for the use of the
addressee and may contain information that is privileged and
confidential.
If the reader of the message is not the intended recipient or an
authorized representative of the intended recipient, you are hereby
notified that any dissemination of this communication is strictly
prohibited. If you have received this communication in error, please
notify us immediately by email and delete the message and any
attachments
from your system.
On 11/27/12 5:57 AM, Stephen Connolly
stephen.alan.conno...@gmail.com
wrote:
The Mojo team is pleased to announce the release of the Versions
Maven Plugin, version 2.0
NOTE: This release requires Maven 2.2.1 or newer and consequently JRE
1.5
or newer.
NOTE: This is the *last* planned release that will support running on
Maven
2.2.x
The Versions Plugin has the following goals.
* versions:compare-dependencies compares the dependency versions of
the current project to the dependency management section of a remote
project.
* versions:display-dependency-updates scans a project's dependencies
and produces a report of those dependencies which have newer versions
available.
* versions:display-plugin-updates scans a project's plugins and
produces a report of those plugins which have newer versions
available.
* versions:display-property-updates scans a projectand produces a
report of those properties which
Re: [ANN] Versions Maven Plugin 2.0 released
Someone please help me from navigating through the forest of no return, that is Google, and tell me how to force our projects back to using the older 1.2 version of the Versions plugin, instead of this newer 2.0 version which is now giving us null pointer exceptions with this simple command: mvn -U versions:set -DnewVersion=12345 I don't really know anything about maven myself, I only plugin what the devs give me into our build configuration system. Can I make a global setting in the settings.xml, or does it have to be in each project's pom.xml? Dennis Wheeler Release Engineer II ADP Digital Marketing Solutions p 206.219.8049 | c 206.375.6781 | e dwhee...@cobalt.com http://www.cobalt.com/ Join the conversation facebook http://www.facebook.com/#!/adpdmc| twitter http://twitter.com/#!/adp_cobalt | blog http://www.digitalmileage.com/ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by email and delete the message and any attachments from your system. On 11/27/12 5:57 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: The Mojo team is pleased to announce the release of the Versions Maven Plugin, version 2.0 NOTE: This release requires Maven 2.2.1 or newer and consequently JRE 1.5 or newer. NOTE: This is the *last* planned release that will support running on Maven 2.2.x The Versions Plugin has the following goals. * versions:compare-dependencies compares the dependency versions of the current project to the dependency management section of a remote project. * versions:display-dependency-updates scans a project's dependencies and produces a report of those dependencies which have newer versions available. * versions:display-plugin-updates scans a project's plugins and produces a report of those plugins which have newer versions available. * versions:display-property-updates scans a projectand produces a report of those properties which are used to control artifact versions and which properies have newer versions available. * versions:update-parent updates the parent section of a project so that it references the newest available version. For example, if you use a corporate root POM, this goal can be helpful if you need to ensure you are using the latest version of the corporate root POM. * versions:update-properties updates properties defined in a project so that they correspond to the latest available version of specific dependencies. This can be useful if a suite of dependencies must all be locked to one version. * versions:update-child-modules updates the parent section of the child modules of a project so the version matches the version of the current project. For example, if you have an aggregator pom that is also the parent for the projects that it aggregates and the children and parent versions get out of sync, this mojo can help fix the versions of the child modules. (Note you may need to invoke Maven with the -N option in order to run this goal if your project is broken so badly that it cannot build because of the version mis-match). * versions:lock-snapshots searches the pom for all -SNAPSHOT versions and replaces them with the current timestamp version of that -SNAPSHOT, e.g. -20090327.172306-4 * versions:unlock-snapshots searches the pom for all timestamp locked snapshot versions and replaces them with -SNAPSHOT. * versions:resolve-ranges finds dependencies using version ranges and resolves the range to the specific version being used. * versions:set can be used to set the project version from the command line. * versions:use-releases searches the pom for all -SNAPSHOT versions which have been released and replaces them with the corresponding release version. * versions:use-next-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the next release version. * versions:use-latest-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the latest release version. * versions:use-next-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the next -SNAPSHOT version. * versions:use-latest-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the latest -SNAPSHOT version. * versions:use-next-versions searches the pom for all versions which have been a newer version and replaces them with the next version. * versions:use-latest-versions searches the pom for all versions which have been a newer version and replaces them with the latest version
Re: [ANN] Versions Maven Plugin 2.0 released
mvn org.codehaus.mojo:versions-maven-plugin:1.2:set /Anders On Wed, Nov 28, 2012 at 9:04 AM, Wheeler, Dennis dwhee...@cobaltgroup.comwrote: Someone please help me from navigating through the forest of no return, that is Google, and tell me how to force our projects back to using the older 1.2 version of the Versions plugin, instead of this newer 2.0 version which is now giving us null pointer exceptions with this simple command: mvn -U versions:set -DnewVersion=12345 I don't really know anything about maven myself, I only plugin what the devs give me into our build configuration system. Can I make a global setting in the settings.xml, or does it have to be in each project's pom.xml? Dennis Wheeler Release Engineer II ADP Digital Marketing Solutions p 206.219.8049 | c 206.375.6781 | e dwhee...@cobalt.com http://www.cobalt.com/ Join the conversation facebook http://www.facebook.com/#!/adpdmc| twitter http://twitter.com/#!/adp_cobalt | blog http://www.digitalmileage.com/ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by email and delete the message and any attachments from your system. On 11/27/12 5:57 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: The Mojo team is pleased to announce the release of the Versions Maven Plugin, version 2.0 NOTE: This release requires Maven 2.2.1 or newer and consequently JRE 1.5 or newer. NOTE: This is the *last* planned release that will support running on Maven 2.2.x The Versions Plugin has the following goals. * versions:compare-dependencies compares the dependency versions of the current project to the dependency management section of a remote project. * versions:display-dependency-updates scans a project's dependencies and produces a report of those dependencies which have newer versions available. * versions:display-plugin-updates scans a project's plugins and produces a report of those plugins which have newer versions available. * versions:display-property-updates scans a projectand produces a report of those properties which are used to control artifact versions and which properies have newer versions available. * versions:update-parent updates the parent section of a project so that it references the newest available version. For example, if you use a corporate root POM, this goal can be helpful if you need to ensure you are using the latest version of the corporate root POM. * versions:update-properties updates properties defined in a project so that they correspond to the latest available version of specific dependencies. This can be useful if a suite of dependencies must all be locked to one version. * versions:update-child-modules updates the parent section of the child modules of a project so the version matches the version of the current project. For example, if you have an aggregator pom that is also the parent for the projects that it aggregates and the children and parent versions get out of sync, this mojo can help fix the versions of the child modules. (Note you may need to invoke Maven with the -N option in order to run this goal if your project is broken so badly that it cannot build because of the version mis-match). * versions:lock-snapshots searches the pom for all -SNAPSHOT versions and replaces them with the current timestamp version of that -SNAPSHOT, e.g. -20090327.172306-4 * versions:unlock-snapshots searches the pom for all timestamp locked snapshot versions and replaces them with -SNAPSHOT. * versions:resolve-ranges finds dependencies using version ranges and resolves the range to the specific version being used. * versions:set can be used to set the project version from the command line. * versions:use-releases searches the pom for all -SNAPSHOT versions which have been released and replaces them with the corresponding release version. * versions:use-next-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the next release version. * versions:use-latest-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the latest release version. * versions:use-next-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the next -SNAPSHOT version. * versions:use-latest-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the latest -SNAPSHOT version. * versions:use-next-versions searches the pom
Re: [ANN] Versions Maven Plugin 2.0 released
Can you please raise a JIRA for the NPE On 28 November 2012 08:04, Wheeler, Dennis dwhee...@cobaltgroup.com wrote: Someone please help me from navigating through the forest of no return, that is Google, and tell me how to force our projects back to using the older 1.2 version of the Versions plugin, instead of this newer 2.0 version which is now giving us null pointer exceptions with this simple command: mvn -U versions:set -DnewVersion=12345 I don't really know anything about maven myself, I only plugin what the devs give me into our build configuration system. Can I make a global setting in the settings.xml, or does it have to be in each project's pom.xml? Dennis Wheeler Release Engineer II ADP Digital Marketing Solutions p 206.219.8049 | c 206.375.6781 | e dwhee...@cobalt.com http://www.cobalt.com/ Join the conversation facebook http://www.facebook.com/#!/adpdmc| twitter http://twitter.com/#!/adp_cobalt | blog http://www.digitalmileage.com/ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by email and delete the message and any attachments from your system. On 11/27/12 5:57 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: The Mojo team is pleased to announce the release of the Versions Maven Plugin, version 2.0 NOTE: This release requires Maven 2.2.1 or newer and consequently JRE 1.5 or newer. NOTE: This is the *last* planned release that will support running on Maven 2.2.x The Versions Plugin has the following goals. * versions:compare-dependencies compares the dependency versions of the current project to the dependency management section of a remote project. * versions:display-dependency-updates scans a project's dependencies and produces a report of those dependencies which have newer versions available. * versions:display-plugin-updates scans a project's plugins and produces a report of those plugins which have newer versions available. * versions:display-property-updates scans a projectand produces a report of those properties which are used to control artifact versions and which properies have newer versions available. * versions:update-parent updates the parent section of a project so that it references the newest available version. For example, if you use a corporate root POM, this goal can be helpful if you need to ensure you are using the latest version of the corporate root POM. * versions:update-properties updates properties defined in a project so that they correspond to the latest available version of specific dependencies. This can be useful if a suite of dependencies must all be locked to one version. * versions:update-child-modules updates the parent section of the child modules of a project so the version matches the version of the current project. For example, if you have an aggregator pom that is also the parent for the projects that it aggregates and the children and parent versions get out of sync, this mojo can help fix the versions of the child modules. (Note you may need to invoke Maven with the -N option in order to run this goal if your project is broken so badly that it cannot build because of the version mis-match). * versions:lock-snapshots searches the pom for all -SNAPSHOT versions and replaces them with the current timestamp version of that -SNAPSHOT, e.g. -20090327.172306-4 * versions:unlock-snapshots searches the pom for all timestamp locked snapshot versions and replaces them with -SNAPSHOT. * versions:resolve-ranges finds dependencies using version ranges and resolves the range to the specific version being used. * versions:set can be used to set the project version from the command line. * versions:use-releases searches the pom for all -SNAPSHOT versions which have been released and replaces them with the corresponding release version. * versions:use-next-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the next release version. * versions:use-latest-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the latest release version. * versions:use-next-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the next -SNAPSHOT version. * versions:use-latest-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the latest -SNAPSHOT version. * versions:use-next-versions searches the pom for all versions which have
Re: [ANN] Versions Maven Plugin 2.0 released
While I would love to assist, this issue has not been consistently reproducible. It hasn't yet failed on our automated trunk builds, but consistently fails on our automated branch builds (it consistently fails for me locally both in the trunk and the branch, but the project's primary developer claims is doesn't fail for him at all (and I don't yet believe he's using the exact same steps -- I think he only wants access to our automated servers)). I am extremely backlogged with other pressing tasks, and my boss doesn't want me to spend the time debugging this issue any further now that we have a workaround solution. Not to mention that we're working within a closed source environment and I'm unsure about how much of our build logs and environment info we can share. Perhaps I can pass this off to one of our other developers who is also more experienced using maven who can then help debug and better report on the NPE. I'm just guessing (and its just a wild unfounded guess at this point), that our project contains some circular dependencies and the new versions plugin is attempting to be more strict in that area. Thanks for all the assistance. On 11/28/12 5:18 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Can you please raise a JIRA for the NPE On 28 November 2012 08:04, Wheeler, Dennis dwhee...@cobaltgroup.com wrote: Someone please help me from navigating through the forest of no return, that is Google, and tell me how to force our projects back to using the older 1.2 version of the Versions plugin, instead of this newer 2.0 version which is now giving us null pointer exceptions with this simple command: mvn -U versions:set -DnewVersion=12345 I don't really know anything about maven myself, I only plugin what the devs give me into our build configuration system. Can I make a global setting in the settings.xml, or does it have to be in each project's pom.xml? Dennis Wheeler Release Engineer II ADP Digital Marketing Solutions p 206.219.8049 | c 206.375.6781 | e dwhee...@cobalt.com http://www.cobalt.com/ Join the conversation facebook http://www.facebook.com/#!/adpdmc| twitter http://twitter.com/#!/adp_cobalt | blog http://www.digitalmileage.com/ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by email and delete the message and any attachments from your system. On 11/27/12 5:57 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: The Mojo team is pleased to announce the release of the Versions Maven Plugin, version 2.0 NOTE: This release requires Maven 2.2.1 or newer and consequently JRE 1.5 or newer. NOTE: This is the *last* planned release that will support running on Maven 2.2.x The Versions Plugin has the following goals. * versions:compare-dependencies compares the dependency versions of the current project to the dependency management section of a remote project. * versions:display-dependency-updates scans a project's dependencies and produces a report of those dependencies which have newer versions available. * versions:display-plugin-updates scans a project's plugins and produces a report of those plugins which have newer versions available. * versions:display-property-updates scans a projectand produces a report of those properties which are used to control artifact versions and which properies have newer versions available. * versions:update-parent updates the parent section of a project so that it references the newest available version. For example, if you use a corporate root POM, this goal can be helpful if you need to ensure you are using the latest version of the corporate root POM. * versions:update-properties updates properties defined in a project so that they correspond to the latest available version of specific dependencies. This can be useful if a suite of dependencies must all be locked to one version. * versions:update-child-modules updates the parent section of the child modules of a project so the version matches the version of the current project. For example, if you have an aggregator pom that is also the parent for the projects that it aggregates and the children and parent versions get out of sync, this mojo can help fix the versions of the child modules. (Note you may need to invoke Maven with the -N option in order to run this goal if your project is broken so badly that it cannot build because of the version mis-match). * versions:lock-snapshots searches the pom for all -SNAPSHOT versions and replaces them with the current timestamp version of that -SNAPSHOT, e.g
Re: [ANN] Versions Maven Plugin 2.0 released
Even the stack trace from the NPE would help On 28 November 2012 23:31, Wheeler, Dennis dwhee...@cobaltgroup.com wrote: While I would love to assist, this issue has not been consistently reproducible. It hasn't yet failed on our automated trunk builds, but consistently fails on our automated branch builds (it consistently fails for me locally both in the trunk and the branch, but the project's primary developer claims is doesn't fail for him at all (and I don't yet believe he's using the exact same steps -- I think he only wants access to our automated servers)). I am extremely backlogged with other pressing tasks, and my boss doesn't want me to spend the time debugging this issue any further now that we have a workaround solution. Not to mention that we're working within a closed source environment and I'm unsure about how much of our build logs and environment info we can share. Perhaps I can pass this off to one of our other developers who is also more experienced using maven who can then help debug and better report on the NPE. I'm just guessing (and its just a wild unfounded guess at this point), that our project contains some circular dependencies and the new versions plugin is attempting to be more strict in that area. Thanks for all the assistance. On 11/28/12 5:18 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Can you please raise a JIRA for the NPE On 28 November 2012 08:04, Wheeler, Dennis dwhee...@cobaltgroup.com wrote: Someone please help me from navigating through the forest of no return, that is Google, and tell me how to force our projects back to using the older 1.2 version of the Versions plugin, instead of this newer 2.0 version which is now giving us null pointer exceptions with this simple command: mvn -U versions:set -DnewVersion=12345 I don't really know anything about maven myself, I only plugin what the devs give me into our build configuration system. Can I make a global setting in the settings.xml, or does it have to be in each project's pom.xml? Dennis Wheeler Release Engineer II ADP Digital Marketing Solutions p 206.219.8049 | c 206.375.6781 | e dwhee...@cobalt.com http://www.cobalt.com/ Join the conversation facebook http://www.facebook.com/#!/adpdmc| twitter http://twitter.com/#!/adp_cobalt | blog http://www.digitalmileage.com/ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by email and delete the message and any attachments from your system. On 11/27/12 5:57 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: The Mojo team is pleased to announce the release of the Versions Maven Plugin, version 2.0 NOTE: This release requires Maven 2.2.1 or newer and consequently JRE 1.5 or newer. NOTE: This is the *last* planned release that will support running on Maven 2.2.x The Versions Plugin has the following goals. * versions:compare-dependencies compares the dependency versions of the current project to the dependency management section of a remote project. * versions:display-dependency-updates scans a project's dependencies and produces a report of those dependencies which have newer versions available. * versions:display-plugin-updates scans a project's plugins and produces a report of those plugins which have newer versions available. * versions:display-property-updates scans a projectand produces a report of those properties which are used to control artifact versions and which properies have newer versions available. * versions:update-parent updates the parent section of a project so that it references the newest available version. For example, if you use a corporate root POM, this goal can be helpful if you need to ensure you are using the latest version of the corporate root POM. * versions:update-properties updates properties defined in a project so that they correspond to the latest available version of specific dependencies. This can be useful if a suite of dependencies must all be locked to one version. * versions:update-child-modules updates the parent section of the child modules of a project so the version matches the version of the current project. For example, if you have an aggregator pom that is also the parent for the projects that it aggregates and the children and parent versions get out of sync, this mojo can help fix the versions of the child modules. (Note you may need to invoke Maven with the -N option in order to run this goal if your project
[ANN] Versions Maven Plugin 1.3.1 released
The Mojo team is pleased to announce the release of the Versions Maven Plugin, version 1.3.1 NOTE: This is the *last* planned release that will support running on Maven 2.0.x and JRE 1.4 The Versions Plugin has the following goals. * versions:compare-dependencies compares the dependency versions of the current project to the dependency management section of a remote project. * versions:display-dependency-updates scans a project's dependencies and produces a report of those dependencies which have newer versions available. * versions:display-plugin-updates scans a project's plugins and produces a report of those plugins which have newer versions available. * versions:display-property-updates scans a projectand produces a report of those properties which are used to control artifact versions and which properies have newer versions available. * versions:update-parent updates the parent section of a project so that it references the newest available version. For example, if you use a corporate root POM, this goal can be helpful if you need to ensure you are using the latest version of the corporate root POM. * versions:update-properties updates properties defined in a project so that they correspond to the latest available version of specific dependencies. This can be useful if a suite of dependencies must all be locked to one version. * versions:update-child-modules updates the parent section of the child modules of a project so the version matches the version of the current project. For example, if you have an aggregator pom that is also the parent for the projects that it aggregates and the children and parent versions get out of sync, this mojo can help fix the versions of the child modules. (Note you may need to invoke Maven with the -N option in order to run this goal if your project is broken so badly that it cannot build because of the version mis-match). * versions:lock-snapshots searches the pom for all -SNAPSHOT versions and replaces them with the current timestamp version of that -SNAPSHOT, e.g. -20090327.172306-4 * versions:unlock-snapshots searches the pom for all timestamp locked snapshot versions and replaces them with -SNAPSHOT. * versions:resolve-ranges finds dependencies using version ranges and resolves the range to the specific version being used. * versions:set can be used to set the project version from the command line. * versions:use-releases searches the pom for all -SNAPSHOT versions which have been released and replaces them with the corresponding release version. * versions:use-next-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the next release version. * versions:use-latest-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the latest release version. * versions:use-next-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the next -SNAPSHOT version. * versions:use-latest-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the latest -SNAPSHOT version. * versions:use-next-versions searches the pom for all versions which have been a newer version and replaces them with the next version. * versions:use-latest-versions searches the pom for all versions which have been a newer version and replaces them with the latest version. * versions:commit removes the pom.xml.versionsBackup files. Forms one half of the built-in Poor Man's SCM. * versions:revert restores the pom.xml files from the pom.xml.versionsBackup files. Forms one half of the built-in Poor Man's SCM. The artifacts have been deployed to the mojo repository and will be mirrored to central. The Mojo Team. Release Notes - Maven 2.x Versions Plugin - Version 1.3.1 ** Bug * [MVERSIONS-174] - Loss of JRE 1.4 compatibility * [MVERSIONS-175] - NPE when running versions:display-plugin-updates Share and Enjoy[1] The Mojo Team [1] The Hitchhiker's Guide to the Galaxy: Share and Enjoy
[ANN] Versions Maven Plugin 1.3 released
The Mojo team is pleased to announce the release of the Versions Maven Plugin, version 1.3. NOTE: This is the last release line that will support running on Maven 2.0.x. NOTE: This version contains one method that requires JDK 1.5, version 1.3.1 of this plugin will be released tomorrow and that will run on JDK 1.4. Version 2.0 of the plugin will require Maven 2.2.1 and JDK 1.5. NOTE: One major change in this version is that the versions:display-plugin-updates goal has been modified to take into account the project and plugin's prerequisites, so that if you invoke it on a project that specifies a minimum of Maven 2.0.9, it will only suggest plugin updates that are compatible with that version of Maven... oh and it will also suggest what plugin updates are available if you increase the minimum version of Maven in your project's pom. The Versions Plugin has the following goals. * versions:compare-dependencies compares the dependency versions of the current project to the dependency management section of a remote project. * versions:display-dependency-updates scans a project's dependencies and produces a report of those dependencies which have newer versions available. * versions:display-plugin-updates scans a project's plugins and produces a report of those plugins which have newer versions available. * versions:display-property-updates scans a projectand produces a report of those properties which are used to control artifact versions and which properies have newer versions available. * versions:update-parent updates the parent section of a project so that it references the newest available version. For example, if you use a corporate root POM, this goal can be helpful if you need to ensure you are using the latest version of the corporate root POM. * versions:update-properties updates properties defined in a project so that they correspond to the latest available version of specific dependencies. This can be useful if a suite of dependencies must all be locked to one version. * versions:update-child-modules updates the parent section of the child modules of a project so the version matches the version of the current project. For example, if you have an aggregator pom that is also the parent for the projects that it aggregates and the children and parent versions get out of sync, this mojo can help fix the versions of the child modules. (Note you may need to invoke Maven with the -N option in order to run this goal if your project is broken so badly that it cannot build because of the version mis-match). * versions:lock-snapshots searches the pom for all -SNAPSHOT versions and replaces them with the current timestamp version of that -SNAPSHOT, e.g. -20090327.172306-4 * versions:unlock-snapshots searches the pom for all timestamp locked snapshot versions and replaces them with -SNAPSHOT. * versions:resolve-ranges finds dependencies using version ranges and resolves the range to the specific version being used. * versions:set can be used to set the project version from the command line. * versions:use-releases searches the pom for all -SNAPSHOT versions which have been released and replaces them with the corresponding release version. * versions:use-next-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the next release version. * versions:use-latest-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the latest release version. * versions:use-next-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the next -SNAPSHOT version. * versions:use-latest-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the latest -SNAPSHOT version. * versions:use-next-versions searches the pom for all versions which have been a newer version and replaces them with the next version. * versions:use-latest-versions searches the pom for all versions which have been a newer version and replaces them with the latest version. * versions:commit removes the pom.xml.versionsBackup files. Forms one half of the built-in Poor Man's SCM. * versions:revert restores the pom.xml files from the pom.xml.versionsBackup files. Forms one half of the built-in Poor Man's SCM. The artifacts have been deployed to the mojo repository and will be mirrored to central. The Mojo Team. Release Notes - Maven 2.x Versions Plugin - Version 1.3 ** Bug * [MVERSIONS-99] - display-dependency-updates reports dependencies with ranges under wrong heading (when the range contains the latest version) * [MVERSIONS-114] - Explict versions inside child poms are updated if they are the same than the version in the parent pom * [MVERSIONS-117] - NPE in UseLatestSnapshotsMojo when allowMajorUpdates=true * [MVERSIONS-120] - NPE from DefaultArtifactVersion.parseVersion
versions-maven-plugin: specfify to update only dependencies from a special, inhouse repository only
Hello, I would like to update the versions in the dependencyManagement section for our inhouse artifacts only, which are specified in our global parent pom. Is there a way to specify dependencies by groupId:artifactId which should (or should not) be updated automatically? Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: versions-maven-plugin: specfify to update only dependencies from a special, inhouse repository only
I found the answer, should have looked at http://mojo.codehaus.org/versions-maven-plugin/examples/advancing-dependency-versions.html beforehand :-). Sorry for the noise. Regards Mirko On Thu, Dec 8, 2011 at 21:24, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Hello, I would like to update the versions in the dependencyManagement section for our inhouse artifacts only, which are specified in our global parent pom. Is there a way to specify dependencies by groupId:artifactId which should (or should not) be updated automatically? Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[versions-maven-plugin] Why is the default to generate backup poms?
Hi, I wonder why the versions-maven-plugin generates backup poms by default? I would assume that 95% of maven users also uses some kind of version control system, so I really don't see the need for that. regards, Wim
Re: [versions-maven-plugin] Why is the default to generate backup poms?
Well, I guess it was decided at some point as a good default behavior. Changing a default behavior is not good as it will trick people when upgrading. But you can always disable this in the pluginManagement section (via the generateBackupPoms param) of your project. http://mojo.codehaus.org/versions-maven-plugin/set-mojo.html#generateBackupPoms /Anders On Mon, Dec 6, 2010 at 13:57, Wim Deblauwe wim.debla...@gmail.com wrote: Hi, I wonder why the versions-maven-plugin generates backup poms by default? I would assume that 95% of maven users also uses some kind of version control system, so I really don't see the need for that. regards, Wim
Re: [versions-maven-plugin] Why is the default to generate backup poms?
I have considered changing the default so that if the effective pom includes an SCM section then it would default to false... but the problem occurs if the parent has an scm section but we are not in scm, e..g. if I use apache-parent-7 as my parent even though I am not in apache's svn server then I will have an scm section which is invalid. Given that v-m-p rewrites pom.xml files, and there is the potential to truely screw your build over, it seemed safer to add the default as generate the backup. you can always add versions:commit to the end of any command line invoking v-m-p and the backup will bre removed... e.g. I often set versions like so mvn versions:set versions:commit -DnewVersion=1.0.4-SNAPSHOT -Stephen On 6 December 2010 13:22, Anders Hammar and...@hammar.net wrote: Well, I guess it was decided at some point as a good default behavior. Changing a default behavior is not good as it will trick people when upgrading. But you can always disable this in the pluginManagement section (via the generateBackupPoms param) of your project. http://mojo.codehaus.org/versions-maven-plugin/set-mojo.html#generateBackupPoms /Anders On Mon, Dec 6, 2010 at 13:57, Wim Deblauwe wim.debla...@gmail.com wrote: Hi, I wonder why the versions-maven-plugin generates backup poms by default? I would assume that 95% of maven users also uses some kind of version control system, so I really don't see the need for that. regards, Wim
Re: [versions-maven-plugin] Why is the default to generate backup poms?
Did not know about versions:commit, that is nice. I know about the command line option, but I always forget the exact syntax, so I have to look it up each time. I have a feeling that I will remember versions:commit more easily :) 2010/12/6 Stephen Connolly stephen.alan.conno...@gmail.com I have considered changing the default so that if the effective pom includes an SCM section then it would default to false... but the problem occurs if the parent has an scm section but we are not in scm, e..g. if I use apache-parent-7 as my parent even though I am not in apache's svn server then I will have an scm section which is invalid. Given that v-m-p rewrites pom.xml files, and there is the potential to truely screw your build over, it seemed safer to add the default as generate the backup. you can always add versions:commit to the end of any command line invoking v-m-p and the backup will bre removed... e.g. I often set versions like so mvn versions:set versions:commit -DnewVersion=1.0.4-SNAPSHOT -Stephen On 6 December 2010 13:22, Anders Hammar and...@hammar.net wrote: Well, I guess it was decided at some point as a good default behavior. Changing a default behavior is not good as it will trick people when upgrading. But you can always disable this in the pluginManagement section (via the generateBackupPoms param) of your project. http://mojo.codehaus.org/versions-maven-plugin/set-mojo.html#generateBackupPoms /Anders On Mon, Dec 6, 2010 at 13:57, Wim Deblauwe wim.debla...@gmail.com wrote: Hi, I wonder why the versions-maven-plugin generates backup poms by default? I would assume that 95% of maven users also uses some kind of version control system, so I really don't see the need for that. regards, Wim
Re: [versions-maven-plugin] Why is the default to generate backup poms?
And versions: rollback reverts - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 6 Dec 2010 15:38, Wim Deblauwe wim.debla...@gmail.com wrote: Did not know about versions:commit, that is nice. I know about the command line option, but I always forget the exact syntax, so I have to look it up each time. I have a feeling that I will remember versions:commit more easily :) 2010/12/6 Stephen Connolly stephen.alan.conno...@gmail.com I have considered changing the default so that if the effective pom includes an SCM section t...
[ANN] Versions Maven Plugin 1.2 released
The Mojo team is pleased to announce the release of the Versions Maven Plugin, version 1.2. The Versions Plugin has the following goals. * versions:display-dependency- updates scans a project's dependencies and produces a report of those dependencies which have newer versions available. * versions:display-plugin-updates scans a project's plugins and produces a report of those plugins which have newer versions available. * versions:display-property-updates scans a projectand produces a report of those properties which are used to control artifact versions and which properies have newer versions available. * versions:update-parent updates the parent section of a project so that it references the newest available version. For example, if you use a corporate root POM, this goal can be helpful if you need to ensure you are using the latest version of the corporate root POM. * versions:update-properties updates properties defined in a project so that they correspond to the latest available version of specific dependencies. This can be useful if a suite of dependencies must all be locked to one version. * versions:update-child-modules updates the parent section of the child modules of a project so the version matches the version of the current project. For example, if you have an aggregator pom that is also the parent for the projects that it aggregates and the children and parent versions get out of sync, this mojo can help fix the versions of the child modules. (Note you may need to invoke Maven with the -N option in order to run this goal if your project is broken so badly that it cannot build because of the version mis-match). * versions:lock-snapshots searches the pom for all -SNAPSHOT versions and replaces them with the current timestamp version of that -SNAPSHOT, e.g. -20090327.172306-4 * versions:unlock-snapshots searches the pom for all timestamp locked snapshot versions and replaces them with -SNAPSHOT. * versions:resolve-ranges finds dependencies using version ranges and resolves the range to the specific version being used. * versuibs:set can be used to set the project version from the command line. * versions:use-releases searches the pom for all -SNAPSHOT versions which have been released and replaces them with the corresponding release version. * versions:use-next-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the next release version. * versions:use-latest-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the latest release version. * versions:use-next-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the next -SNAPSHOT version. * versions:use-latest-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the latest -SNAPSHOT version. * versions:use-next-versions searches the pom for all versions which have been a newer version and replaces them with the next version. * versions:use-latest-versions searches the pom for all versions which have been a newer version and replaces them with the latest version. * versions:commit removes the pom.xml.versionsBackup files. Forms one half of the built-in Poor Man's SCM. * versions:revert restores the pom.xml files from the pom.xml.versionsBackup files. Forms one half of the built-in Poor Man's SCM. The artifacts have been deployed to the mojo repository and have been mirrored to central. The Mojo Team. Release Notes - Maven 2.x Versions Plugin - Version 1.2 ** Bug * [MVERSIONS-84] - versions:set fails to update dependencies when -f option points to a file with more than one subfolder in its path * [MVERSIONS-86] - NullPointerException in versions:display-dependency-updates with version range * [MVERSIONS-87] - missing text for property report.description * [MVERSIONS-88] - mvn versions:display-dependency-updates does not consider snapshots even if they are in local repository * [MVERSIONS-89] - NPE when generating site:site * [MVERSIONS-90] - update snapshots mojos parameter configuration incorrect and version increment logic is wrong * [MVERSIONS-99] - display-dependency-updates reports dependencies with ranges under wrong heading (when the range contains the latest version) * [MVERSIONS-100] - Misspelled goal on Verions Maven Plugin page * [MVERSIONS-105] - versions-maven-plugin display-plugin-updates fails on 3.0-beta-1 while working on 3.0-alph-* ** New Feature * [MVERSIONS-92] - Add new mojo to set dependencies to a specific version * [MVERSIONS-101] - Add processDependencies and processDependencyManagement parameters to display-dependency-updates goal Note: as of 01:26 IST (Irish Summer Time = GMT+1h) 22/05/2010 the versions-maven-plugin has not been pushed to maven central. If you cannot wait
[ANN] Versions Maven Plugin 1.1 released
he Mojo team is pleased to announce the release of the Versions Maven Plugin, version 1.1. The Versions Plugin has the following goals. * versions:display-dependency-updates scans a project's dependencies and produces a report of those dependencies which have newer versions available. * versions:display-plugin-updates scans a project's plugins and produces a report of those plugins which have newer versions available. * versions:display-property-updates scans a projectand produces a report of those properties which are used to control artifact versions and which properies have newer versions available. * versions:update-parent updates the parent section of a project so that it references the newest available version. For example, if you use a corporate root POM, this goal can be helpful if you need to ensure you are using the latest version of the corporate root POM. * versions:update-properties updates properties defined in a project so that they correspond to the latest available version of specific dependencies. This can be useful if a suite of dependencies must all be locked to one version. * versions:update-child-modules updates the parent section of the child modules of a project so the version matches the version of the current project. For example, if you have an aggregator pom that is also the parent for the projects that it aggregates and the children and parent versions get out of sync, this mojo can help fix the versions of the child modules. (Note you may need to invoke Maven with the -N option in order to run this goal if your project is broken so badly that it cannot build because of the version mis-match). * versions:lock-snapshots searches the pom for all -SNAPSHOT versions and replaces them with the current timestamp version of that -SNAPSHOT, e.g. -20090327.172306-4 * versions:unlock-snapshots searches the pom for all timestamp locked snapshot versions and replaces them with -SNAPSHOT. * versions:resolve-ranges finds dependencies using version ranges and resolves the range to the specific version being used. * versuibs:set can be used to set the project version from the command line. * versions:use-releases searches the pom for all -SNAPSHOT versions which have been released and replaces them with the corresponding release version. * versions:use-next-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the next release version. * versions:use-latest-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the latest release version. * versions:use-next-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the next -SNAPSHOT version. * versions:use-latest-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the latest -SNAPSHOT version. * versions:use-next-versions searches the pom for all versions which have been a newer version and replaces them with the next version. * versions:use-latest-versions searches the pom for all versions which have been a newer version and replaces them with the latest version. * versions:commit removes the pom.xml.versionsBackup files. Forms one half of the built-in Poor Man's SCM. * versions:revert restores the pom.xml files from the pom.xml.versionsBackup files. Forms one half of the built-in Poor Man's SCM. The artifacts have been deployed to the mojo repository and have been mirrored to central. The Mojo Team. Release Notes - Maven 2.x Versions Plugin - Version 1.1 ** Bug * [MVERSIONS-66] - FATAL Error thrown for versions:dependency-updates-report GOAL * [MVERSIONS-67] - Reporting IllegalArgumentException plugin comparator used for normal dependencies * [MVERSIONS-71] - versions:set changes both parent and module version * [MVERSIONS-75] - Spelling error * [MVERSIONS-80] - update-properties doesn't work when version is specified in plugin configuration ** Improvement * [MVERSIONS-72] - versions-maven-plugin should determine POM encoding from property/configuration entry * [MVERSIONS-73] - Documentation should provide a matrix table showing what the different goals do exactly Note: as of 21:22 GMT 30/10/2009 the versions-maven-plugin has not been pushed to maven central. If you cannot wait the (at most) 24 hours for this sync, you can use the codehaus repository (http://repository.codehaus.org/). - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Unexpected results from versions-maven-plugin:1.0:use-latest-versions
Hi All, I've 2 queries in regard to the usage of versions-maven-plugin:1.0:use-latest-versions. QUERY 1 I was trying to use the maven version plugin to get the various latest (released or snapshot) versions of a project from our Nexus. However the version plugin doesn't seem to return the results I was expecting. Can someone please confirm whether and what it is doing is correct or not? First when I ran: mvn org.codehaus.mojo:versions-maven-plugin:1.0:use-latest-versions -Dincludes=com.dzango.addresslookup:addresslookup-jaxb The version in my local pom file was 7.37.0-SNAPSHOT. The above command returned 7.37.0 from nexus. This is correct behaviour as from the 2 nexus repository listing below, one can see that the last released version in nexus is 7.37.0. However when I run: mvn org.codehaus.mojo:versions-maven-plugin:1.0:use-latest-versions -Dincludes=com.dzango.addresslookup:addresslookup-jaxb -DallowSnapshots=true Again the version in my local pom file was 7.37.0-SNAPSHOT. The command again returns 7.37.0 from nexus. This is NOT what I was expecting. As I've mentioned -DallowSnapshots=true in the command, it should have returned me the latest snapshot version NOT the released version. Similary when I ran the above command but with the version in my local pom file being 7.26.1-SNAPSHOT it again returned me 7.37.0. Again INCORRECT. I was expecting the latest SNAPSHOT version. Any idea what's going on or what I'm missing? - My RELEASE repository metadata groupIdcom.dzango.addresslookup/groupId artifactIdaddresslookup-jaxb/artifactId version7.26.0/version − versioning − versions version7.26.0/version version7.27.0/version version7.27.1/version version7.28.0/version version7.29.0/version version7.29.1/version version7.29.2/version version7.30.0/version version7.30.1/version version7.30.2/version version7.31.0/version version7.34.0/version version7.34.1/version version7.34.2/version version7.34.3/version version7.35.0/version version7.35.1/version version7.36.0/version version7.37.0/version /versions lastUpdated20090924132030/lastUpdated /versioning /metadata - My SNAPSHOT repository metadata groupIdcom.dzango.addresslookup/groupId artifactIdaddresslookup-jaxb/artifactId versioning latest7.37.1-SNAPSHOT/latest versions version7.30.3-SNAPSHOT/version version7.27.2-SNAPSHOT/version version7.26.1-SNAPSHOT/version version7.36.1-SNAPSHOT/version version7.32.0-SNAPSHOT/version version7.28.1-SNAPSHOT/version version7.31.1-SNAPSHOT/version version7.29.3-SNAPSHOT/version version7.33.0-SNAPSHOT/version version7.35.2-SNAPSHOT/version version7.37.0-SNAPSHOT/version version7.34.4-SNAPSHOT/version version7.38.0-SNAPSHOT/version version7.37.1-SNAPSHOT/version /versions lastUpdated20090924132147/lastUpdated /versioning /metadata ** QUERY 2 -- My second query is about the latest version shown in the above SNAPSHOT repositories meta data. Why is the latest version shown as 7.37.1-SNAPSHOT while the latest version we actually have is 7.38.0-SNAPSHOT? However point to be noted here is that update time for 7.37.1-SNAPSHOT is later to 7.38.0-SNAPSHOT. If the update timestamp decides the latest version, then is there any way to ask the plugin to overlook that and go for the version which has the highest number against it and return than? -- View this message in context: http://www.nabble.com/Unexpected-results-from-versions-maven-plugin%3A1.0%3Ause-latest-versions-tp25682772p25682772.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
RE : [Versions Maven Plugin 1.0] FATAL Error thrown for versions:dependency-updates-report GOAL
Hi, It seems the new version need also org.apache.maven.shared:maven-common-artifact-filters:jar:1.2 but only version 1.1 is accessible from central. Best regards, Vincent Hardion -Message d'origine- De : Arnaud HERITIER [mailto:aherit...@gmail.com] Envoyé : lundi 24 août 2009 10:37 À : Maven Users List Cc : u...@mojo.codehaus.org Objet : Re: [Versions Maven Plugin 1.0] FATAL Error thrown for versions:dependency-updates-report GOAL it seems to be a doxia incompabilityWe have to verify it. Can you open an issue here please : http://jira.codehaus.org/browse/MVERSIONS If you can also give us the result of mvn help:effective-pom in your module MBS - utilities. You can remove all private information if needed. NOTE : this plugin isn't maintain by the maven team thus I recommend that you contact the mojo team on u...@mojo.codehaus.org Cheers, Arnaud # Arnaud Héritier # Software Factory Manager # eXo Platform # http://www.exoplatform.com # http://blog.aheritier.net On Mon, Aug 24, 2009 at 10:25 AM, subir.sasiku...@wipro.com wrote: Hi, I tried to use this plugin to check the dependency version updates I might need for the project. I use Maven 2.1.0, on WinXP professional, and JDK 1.6.0 I got the following exceptions: E:\maven-work\main\bsmmvn versions:dependency-updates-report [WARNING] Not decrypting password for server 'repo.mobiletv.org-releases' due to exception in security handler. Ensure that you have configured your master password file (and relocation if app ropriate) See the installation instructions for details. Cause: C:\Documents and Settings\subirs.W\.m2\settings-security.xml (The sys tem cannot find the file specified) [WARNING] Not decrypting password for server 'repo.mobiletv.org-snapshots' due t o exception in security handler. Ensure that you have configured your master password file (and relocation if app ropriate) See the installation instructions for details. Cause: C:\Documents and Settings\subirs.W\.m2\settings-security.xml (The sys tem cannot find the file specified) [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] MBS - utilities [INFO] BSM - model [INFO] BSM - GUI Web Application Module [INFO] BSM - WSI Web Application Module [INFO] BSM - Welcome Web Application Module [INFO] BSM - Root [INFO] Searching repository for plugin with prefix: 'versions'. [INFO] [INFO] Building MBS - utilities [INFO]task-segment: [versions:dependency-updates-report] [INFO] Downloading: http://10.150.137.44:8080/artifactory/repo/org/hibernate/hibernate- core/3.3.2.GA/hibernate-core-3.3.2.GA.pom [INFO] Unable to find resource 'org.hibernate:hibernate-core:pom:3.3.2.GA' in re pository central (http://10.150.137.44:8080/artifactory/repo) Downloading: http://10.150.137.44:8080/artifactory/repo/org/hibernate/hibernate- core/3.3.2.GA/hibernate-core-3.3.2.GA.jar 2255K downloaded (hibernate-core-3.3.2.GA.jar) [INFO] [versions:dependency-updates-report] [INFO] artifact axis:axis-wsdl4j: checking for updates from central [INFO] artifact c3p0:c3p0: checking for updates from central [INFO] artifact c3p0:c3p0-oracle-thin-extras: checking for updates from central [INFO] artifact com.oracle:ojdbc14: checking for updates from central [INFO] artifact commons-discovery:commons-discovery: checking for updates from c entral [INFO] artifact commons-fileupload:commons-fileupload: checking for updates from central [INFO] artifact commons-io:commons-io: checking for updates from central [INFO] artifact commons-lang:commons-lang: checking for updates from central [INFO] artifact commons-logging:commons-logging: checking for updates from centr al [INFO] artifact javax.activation:activation: checking for updates from central [INFO] artifact javax.mail:mail: checking for updates from central [INFO] artifact javax.servlet:jsp-api: checking for updates from central [INFO] artifact javax.servlet:jstl: checking for updates from central [INFO] artifact javax.servlet:servlet-api: checking for updates from central [INFO] artifact json_simple:json_simple: checking for updates from central [INFO] artifact log4j:log4j: checking for updates from central [INFO] artifact net.sf.mime-util:mime-util: checking for updates from central [INFO] artifact net.sourceforge.stripes:stripes: checking for updates from centr al [INFO] artifact org.apache.ant:ant: checking for updates from central [INFO] artifact org.apache.axis:axis: checking for updates from central [INFO] artifact org.apache.axis:axis-jaxrpc: checking for updates from central [INFO] artifact org.apache.axis:axis-saaj: checking for updates from central [INFO] artifact org.apache.maven:jspc-compiler-tomcat6: checking for updates fro m central [INFO] artifact org.apache.maven:maven-archiver
RE: RE : [Versions Maven Plugin 1.0] FATAL Error thrown for versions:dependency-updates-report GOAL
Can you please add a comment to http://jira.codehaus.org/browse/MVERSIONS-66 so that this information could help in fixing this issue? Thanks Subir -Original Message- From: HARDION Vincent [mailto:vincent.hard...@synchrotron-soleil.fr] Sent: Tuesday, August 25, 2009 5:33 PM To: Maven Users List Subject: RE : [Versions Maven Plugin 1.0] FATAL Error thrown for versions:dependency-updates-report GOAL Hi, It seems the new version need also org.apache.maven.shared:maven-common-artifact-filters:jar:1.2 but only version 1.1 is accessible from central. Best regards, Vincent Hardion -Message d'origine- De : Arnaud HERITIER [mailto:aherit...@gmail.com] Envoyé : lundi 24 août 2009 10:37 À : Maven Users List Cc : u...@mojo.codehaus.org Objet : Re: [Versions Maven Plugin 1.0] FATAL Error thrown for versions:dependency-updates-report GOAL it seems to be a doxia incompabilityWe have to verify it. Can you open an issue here please : http://jira.codehaus.org/browse/MVERSIONS If you can also give us the result of mvn help:effective-pom in your module MBS - utilities. You can remove all private information if needed. NOTE : this plugin isn't maintain by the maven team thus I recommend that you contact the mojo team on u...@mojo.codehaus.org Cheers, Arnaud # Arnaud Héritier # Software Factory Manager # eXo Platform # http://www.exoplatform.com # http://blog.aheritier.net On Mon, Aug 24, 2009 at 10:25 AM, subir.sasiku...@wipro.com wrote: Hi, I tried to use this plugin to check the dependency version updates I might need for the project. I use Maven 2.1.0, on WinXP professional, and JDK 1.6.0 I got the following exceptions: E:\maven-work\main\bsmmvn versions:dependency-updates-report [WARNING] Not decrypting password for server 'repo.mobiletv.org-releases' due to exception in security handler. Ensure that you have configured your master password file (and relocation if app ropriate) See the installation instructions for details. Cause: C:\Documents and Settings\subirs.W\.m2\settings-security.xml (The sys tem cannot find the file specified) [WARNING] Not decrypting password for server 'repo.mobiletv.org-snapshots' due t o exception in security handler. Ensure that you have configured your master password file (and relocation if app ropriate) See the installation instructions for details. Cause: C:\Documents and Settings\subirs.W\.m2\settings-security.xml (The sys tem cannot find the file specified) [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] MBS - utilities [INFO] BSM - model [INFO] BSM - GUI Web Application Module [INFO] BSM - WSI Web Application Module [INFO] BSM - Welcome Web Application Module [INFO] BSM - Root [INFO] Searching repository for plugin with prefix: 'versions'. [INFO] [INFO] Building MBS - utilities [INFO]task-segment: [versions:dependency-updates-report] [INFO] Downloading: http://10.150.137.44:8080/artifactory/repo/org/hibernate/hibernate- core/3.3.2.GA/hibernate-core-3.3.2.GA.pom [INFO] Unable to find resource 'org.hibernate:hibernate-core:pom:3.3.2.GA' in re pository central (http://10.150.137.44:8080/artifactory/repo) Downloading: http://10.150.137.44:8080/artifactory/repo/org/hibernate/hibernate- core/3.3.2.GA/hibernate-core-3.3.2.GA.jar 2255K downloaded (hibernate-core-3.3.2.GA.jar) [INFO] [versions:dependency-updates-report] [INFO] artifact axis:axis-wsdl4j: checking for updates from central [INFO] artifact c3p0:c3p0: checking for updates from central [INFO] artifact c3p0:c3p0-oracle-thin-extras: checking for updates from central [INFO] artifact com.oracle:ojdbc14: checking for updates from central [INFO] artifact commons-discovery:commons-discovery: checking for updates from c entral [INFO] artifact commons-fileupload:commons-fileupload: checking for updates from central [INFO] artifact commons-io:commons-io: checking for updates from central [INFO] artifact commons-lang:commons-lang: checking for updates from central [INFO] artifact commons-logging:commons-logging: checking for updates from centr al [INFO] artifact javax.activation:activation: checking for updates from central [INFO] artifact javax.mail:mail: checking for updates from central [INFO] artifact javax.servlet:jsp-api: checking for updates from central [INFO] artifact javax.servlet:jstl: checking for updates from central [INFO] artifact javax.servlet:servlet-api: checking for updates from central [INFO] artifact json_simple:json_simple: checking for updates from central [INFO] artifact log4j:log4j: checking for updates from central [INFO] artifact net.sf.mime-util:mime-util: checking for updates from central [INFO] artifact net.sourceforge.stripes:stripes: checking for updates from centr al [INFO] artifact org.apache.ant:ant
Re: RE : [Versions Maven Plugin 1.0] FATAL Error thrown for versions:dependency-updates-report GOAL
They are here : http://repo1.maven.org/maven2/org/apache/maven/shared/maven-common-artifact-filters/1.2/ I published them few days before the release of versions plugin Cheers, Arnaud # Arnaud Héritier # Software Factory Manager # eXo Platform # http://www.exoplatform.com # http://blog.aheritier.net On Tue, Aug 25, 2009 at 2:02 PM, HARDION Vincent vincent.hard...@synchrotron-soleil.fr wrote: Hi, It seems the new version need also org.apache.maven.shared:maven-common-artifact-filters:jar:1.2 but only version 1.1 is accessible from central. Best regards, Vincent Hardion -Message d'origine- De : Arnaud HERITIER [mailto:aherit...@gmail.com] Envoyé : lundi 24 août 2009 10:37 À : Maven Users List Cc : u...@mojo.codehaus.org Objet : Re: [Versions Maven Plugin 1.0] FATAL Error thrown for versions:dependency-updates-report GOAL it seems to be a doxia incompabilityWe have to verify it. Can you open an issue here please : http://jira.codehaus.org/browse/MVERSIONS If you can also give us the result of mvn help:effective-pom in your module MBS - utilities. You can remove all private information if needed. NOTE : this plugin isn't maintain by the maven team thus I recommend that you contact the mojo team on u...@mojo.codehaus.org Cheers, Arnaud # Arnaud Héritier # Software Factory Manager # eXo Platform # http://www.exoplatform.com # http://blog.aheritier.net On Mon, Aug 24, 2009 at 10:25 AM, subir.sasiku...@wipro.com wrote: Hi, I tried to use this plugin to check the dependency version updates I might need for the project. I use Maven 2.1.0, on WinXP professional, and JDK 1.6.0 I got the following exceptions: E:\maven-work\main\bsmmvn versions:dependency-updates-report [WARNING] Not decrypting password for server 'repo.mobiletv.org-releases' due to exception in security handler. Ensure that you have configured your master password file (and relocation if app ropriate) See the installation instructions for details. Cause: C:\Documents and Settings\subirs.W\.m2\settings-security.xml (The sys tem cannot find the file specified) [WARNING] Not decrypting password for server 'repo.mobiletv.org-snapshots' due t o exception in security handler. Ensure that you have configured your master password file (and relocation if app ropriate) See the installation instructions for details. Cause: C:\Documents and Settings\subirs.W\.m2\settings-security.xml (The sys tem cannot find the file specified) [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] MBS - utilities [INFO] BSM - model [INFO] BSM - GUI Web Application Module [INFO] BSM - WSI Web Application Module [INFO] BSM - Welcome Web Application Module [INFO] BSM - Root [INFO] Searching repository for plugin with prefix: 'versions'. [INFO] [INFO] Building MBS - utilities [INFO]task-segment: [versions:dependency-updates-report] [INFO] Downloading: http://10.150.137.44:8080/artifactory/repo/org/hibernate/hibernate- core/3.3.2.GA/hibernate-core-3.3.2.GA.pom [INFO] Unable to find resource 'org.hibernate:hibernate-core:pom:3.3.2.GA' in re pository central (http://10.150.137.44:8080/artifactory/repo) Downloading: http://10.150.137.44:8080/artifactory/repo/org/hibernate/hibernate- core/3.3.2.GA/hibernate-core-3.3.2.GA.jar 2255K downloaded (hibernate-core-3.3.2.GA.jar) [INFO] [versions:dependency-updates-report] [INFO] artifact axis:axis-wsdl4j: checking for updates from central [INFO] artifact c3p0:c3p0: checking for updates from central [INFO] artifact c3p0:c3p0-oracle-thin-extras: checking for updates from central [INFO] artifact com.oracle:ojdbc14: checking for updates from central [INFO] artifact commons-discovery:commons-discovery: checking for updates from c entral [INFO] artifact commons-fileupload:commons-fileupload: checking for updates from central [INFO] artifact commons-io:commons-io: checking for updates from central [INFO] artifact commons-lang:commons-lang: checking for updates from central [INFO] artifact commons-logging:commons-logging: checking for updates from centr al [INFO] artifact javax.activation:activation: checking for updates from central [INFO] artifact javax.mail:mail: checking for updates from central [INFO] artifact javax.servlet:jsp-api: checking for updates from central [INFO] artifact javax.servlet:jstl: checking for updates from central [INFO] artifact javax.servlet:servlet-api: checking for updates from central [INFO] artifact json_simple:json_simple: checking for updates from central [INFO] artifact log4j:log4j: checking for updates from central [INFO] artifact net.sf.mime-util:mime-util: checking for updates from central [INFO] artifact
Re: RE : [Versions Maven Plugin 1.0] FATAL Error thrown for versions:dependency-updates-report GOAL
Sorry I've just seen that our mirror (http://ftp.cica.es/mirrors/ maven2) is not updated from february 2009 !!! Thank you very much for your work Vincent Le 25 août 09 à 18:46, Arnaud HERITIER a écrit : They are here : http://repo1.maven.org/maven2/org/apache/maven/shared/maven-common-artifact-filters/1.2/ I published them few days before the release of versions plugin Cheers, Arnaud # Arnaud Héritier # Software Factory Manager # eXo Platform # http://www.exoplatform.com # http://blog.aheritier.net On Tue, Aug 25, 2009 at 2:02 PM, HARDION Vincent vincent.hard...@synchrotron-soleil.fr wrote: Hi, It seems the new version need also org.apache.maven.shared:maven-common-artifact-filters:jar:1.2 but only version 1.1 is accessible from central. Best regards, Vincent Hardion -Message d'origine- De : Arnaud HERITIER [mailto:aherit...@gmail.com] Envoyé : lundi 24 août 2009 10:37 À : Maven Users List Cc : u...@mojo.codehaus.org Objet : Re: [Versions Maven Plugin 1.0] FATAL Error thrown for versions:dependency-updates-report GOAL it seems to be a doxia incompabilityWe have to verify it. Can you open an issue here please : http://jira.codehaus.org/browse/MVERSIONS If you can also give us the result of mvn help:effective-pom in your module MBS - utilities. You can remove all private information if needed. NOTE : this plugin isn't maintain by the maven team thus I recommend that you contact the mojo team on u...@mojo.codehaus.org Cheers, Arnaud # Arnaud Héritier # Software Factory Manager # eXo Platform # http://www.exoplatform.com # http://blog.aheritier.net On Mon, Aug 24, 2009 at 10:25 AM, subir.sasiku...@wipro.com wrote: Hi, I tried to use this plugin to check the dependency version updates I might need for the project. I use Maven 2.1.0, on WinXP professional, and JDK 1.6.0 I got the following exceptions: E:\maven-work\main\bsmmvn versions:dependency-updates-report [WARNING] Not decrypting password for server 'repo.mobiletv.org-releases' due to exception in security handler. Ensure that you have configured your master password file (and relocation if app ropriate) See the installation instructions for details. Cause: C:\Documents and Settings\subirs.W\.m2\settings- security.xml (The sys tem cannot find the file specified) [WARNING] Not decrypting password for server 'repo.mobiletv.org-snapshots' due t o exception in security handler. Ensure that you have configured your master password file (and relocation if app ropriate) See the installation instructions for details. Cause: C:\Documents and Settings\subirs.W\.m2\settings- security.xml (The sys tem cannot find the file specified) [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] MBS - utilities [INFO] BSM - model [INFO] BSM - GUI Web Application Module [INFO] BSM - WSI Web Application Module [INFO] BSM - Welcome Web Application Module [INFO] BSM - Root [INFO] Searching repository for plugin with prefix: 'versions'. [INFO] [INFO] Building MBS - utilities [INFO]task-segment: [versions:dependency-updates-report] [INFO] Downloading: http://10.150.137.44:8080/artifactory/repo/org/hibernate/hibernate- core/3.3.2.GA/hibernate-core-3.3.2.GA.pom [INFO] Unable to find resource 'org.hibernate:hibernate-core:pom:3.3.2.GA' in re pository central (http://10.150.137.44:8080/artifactory/repo) Downloading: http://10.150.137.44:8080/artifactory/repo/org/hibernate/hibernate- core/3.3.2.GA/hibernate-core-3.3.2.GA.jar 2255K downloaded (hibernate-core-3.3.2.GA.jar) [INFO] [versions:dependency-updates-report] [INFO] artifact axis:axis-wsdl4j: checking for updates from central [INFO] artifact c3p0:c3p0: checking for updates from central [INFO] artifact c3p0:c3p0-oracle-thin-extras: checking for updates from central [INFO] artifact com.oracle:ojdbc14: checking for updates from central [INFO] artifact commons-discovery:commons-discovery: checking for updates from c entral [INFO] artifact commons-fileupload:commons-fileupload: checking for updates from central [INFO] artifact commons-io:commons-io: checking for updates from central [INFO] artifact commons-lang:commons-lang: checking for updates from central [INFO] artifact commons-logging:commons-logging: checking for updates from centr al [INFO] artifact javax.activation:activation: checking for updates from central [INFO] artifact javax.mail:mail: checking for updates from central [INFO] artifact javax.servlet:jsp-api: checking for updates from central [INFO] artifact javax.servlet:jstl: checking for updates from central [INFO] artifact javax.servlet:servlet-api: checking for updates from central [INFO] artifact json_simple:json_simple: checking for updates from central [INFO] artifact log4j:log4j: checking for updates from central [INFO] artifact net.sf.mime-util:mime-util: checking
[Versions Maven Plugin 1.0] FATAL Error thrown for versions:dependency-updates-report GOAL
/repository/org/codeha us/mojo/versions-maven-plugin/1.0/versions-maven-plugin-1.0.jar urls[1] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/codeha us/plexus/plexus-utils/1.5.1/plexus-utils-1.5.1.jar urls[2] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apache /maven/reporting/maven-reporting-impl/2.0.4.1/maven-reporting-impl-2.0.4 .1.jar urls[3] = file:/C:/Documents and Settings/subirs.W/.m2/repository/commons-va lidator/commons-validator/1.2.0/commons-validator-1.2.0.jar urls[4] = file:/C:/Documents and Settings/subirs.W/.m2/repository/commons-be anutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar urls[5] = file:/C:/Documents and Settings/subirs.W/.m2/repository/commons-lo gging/commons-logging/1.0.4/commons-logging-1.0.4.jar urls[6] = file:/C:/Documents and Settings/subirs.W/.m2/repository/commons-di gester/commons-digester/1.6/commons-digester-1.6.jar urls[7] = file:/C:/Documents and Settings/subirs.W/.m2/repository/commons-co llections/commons-collections/3.2/commons-collections-3.2.jar urls[8] = file:/C:/Documents and Settings/subirs.W/.m2/repository/oro/oro/2. 0.8/oro-2.0.8.jar urls[9] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apache /maven/doxia/doxia-core/1.0-alpha-10/doxia-core-1.0-alpha-10.jar urls[10] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/maven/doxia/doxia-site-renderer/1.0/doxia-site-renderer-1.0.jar urls[11] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/codeh aus/plexus/plexus-i18n/1.0-beta-7/plexus-i18n-1.0-beta-7.jar urls[12] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/codeh aus/plexus/plexus-velocity/1.1.7/plexus-velocity-1.1.7.jar urls[13] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/velocity/velocity/1.5/velocity-1.5.jar urls[14] = file:/C:/Documents and Settings/subirs.W/.m2/repository/commons-l ang/commons-lang/2.1/commons-lang-2.1.jar urls[15] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/maven/doxia/doxia-decoration-model/1.0/doxia-decoration-model-1.0.jar urls[16] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/maven/doxia/doxia-module-apt/1.0/doxia-module-apt-1.0.jar urls[17] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/maven/doxia/doxia-module-fml/1.0/doxia-module-fml-1.0.jar urls[18] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/maven/doxia/doxia-module-xdoc/1.0/doxia-module-xdoc-1.0.jar urls[19] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/maven/doxia/doxia-module-xhtml/1.0/doxia-module-xhtml-1.0.jar urls[20] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/maven/shared/maven-common-artifact-filters/1.2/maven-common-artifact-f ilters-1 .2.jar urls[21] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/maven/shared/maven-plugin-testing-harness/1.1/maven-plugin-testing-har ness-1.1 .jar urls[22] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/codeh aus/plexus/plexus-archiver/1.0-alpha-7/plexus-archiver-1.0-alpha-7.jar urls[23] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/codeh aus/woodstox/wstx-asl/3.2.7/wstx-asl-3.2.7.jar urls[24] = file:/C:/Documents and Settings/subirs.W/.m2/repository/stax/stax -api/1.0.1/stax-api-1.0.1.jar [FATAL ERROR] Container realm = plexus.core urls[0] = file:/D:/apache-maven-2.1.0/lib/maven-2.1.0-uber.jar [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.maven.doxia.module.xhtml.XhtmlSink.writeEndTagWithoutEOL(Ljav a x/swing/text/html/HTML$Tag;)V [INFO] [INFO] Trace java.lang.NoSuchMethodError: org.apache.maven.doxia.module.xhtml.XhtmlSink.write EndTagWithoutEOL(Ljavax/swing/text/html/HTML$Tag;)V at org.apache.maven.doxia.module.xhtml.XhtmlSink.bold_(XhtmlSink.java:11 14) at org.codehaus.mojo.versions.AbstractVersionsReportRenderer.renderDepen dencySummaryTableRow(AbstractVersionsReportRenderer.java:197) at org.codehaus.mojo.versions.AbstractVersionsReportRenderer.renderDepen dencySummaryTable(AbstractVersionsReportRenderer.java:447) at org.codehaus.mojo.versions.AbstractVersionsReportRenderer.renderDepen dencySummaryTable(AbstractVersionsReportRenderer.java:436) at org.codehaus.mojo.versions.DependencyUpdatesRenderer.renderSummaryTab le(DependencyUpdatesRenderer.java:110) at org.codehaus.mojo.versions.DependencyUpdatesRenderer.renderBody(Depen dencyUpdatesRenderer.java:72) at org.apache.maven.reporting.AbstractMavenReportRenderer.render(Abstrac tMavenReportRenderer.java:65) at org.codehaus.mojo.versions.DependencyUpdatesReport.doGenerateReport(D ependencyUpdatesReport.java:92
Re: [Versions Maven Plugin 1.0] FATAL Error thrown for versions:dependency-updates-report GOAL
] artifact org.codehaus.mojo.jspc:jspc-compiler-tomcat6: checking for updat es from central [INFO] artifact org.hibernate:hibernate-core: checking for updates from central [INFO] artifact org.testng:testng: checking for updates from central [INFO] artifact session-plugin3:session-plugin3: checking for updates from centr al [INFO] artifact taglibs:standard: checking for updates from central [FATAL ERROR] org.codehaus.mojo.versions.DependencyUpdatesReport#execute() cause d a linkage error (java.lang.NoSuchMethodError) and may be out-of-date. Check th e realms: [FATAL ERROR] Plugin realm = app0.child-container[org.codehaus.mojo:versions-mav en-plugin:1.0] urls[0] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/codeha us/mojo/versions-maven-plugin/1.0/versions-maven-plugin-1.0.jar urls[1] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/codeha us/plexus/plexus-utils/1.5.1/plexus-utils-1.5.1.jar urls[2] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apache /maven/reporting/maven-reporting-impl/2.0.4.1/maven-reporting-impl-2.0.4 .1.jar urls[3] = file:/C:/Documents and Settings/subirs.W/.m2/repository/commons-va lidator/commons-validator/1.2.0/commons-validator-1.2.0.jar urls[4] = file:/C:/Documents and Settings/subirs.W/.m2/repository/commons-be anutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar urls[5] = file:/C:/Documents and Settings/subirs.W/.m2/repository/commons-lo gging/commons-logging/1.0.4/commons-logging-1.0.4.jar urls[6] = file:/C:/Documents and Settings/subirs.W/.m2/repository/commons-di gester/commons-digester/1.6/commons-digester-1.6.jar urls[7] = file:/C:/Documents and Settings/subirs.W/.m2/repository/commons-co llections/commons-collections/3.2/commons-collections-3.2.jar urls[8] = file:/C:/Documents and Settings/subirs.W/.m2/repository/oro/oro/2. 0.8/oro-2.0.8.jar urls[9] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apache /maven/doxia/doxia-core/1.0-alpha-10/doxia-core-1.0-alpha-10.jar urls[10] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/maven/doxia/doxia-site-renderer/1.0/doxia-site-renderer-1.0.jar urls[11] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/codeh aus/plexus/plexus-i18n/1.0-beta-7/plexus-i18n-1.0-beta-7.jar urls[12] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/codeh aus/plexus/plexus-velocity/1.1.7/plexus-velocity-1.1.7.jar urls[13] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/velocity/velocity/1.5/velocity-1.5.jar urls[14] = file:/C:/Documents and Settings/subirs.W/.m2/repository/commons-l ang/commons-lang/2.1/commons-lang-2.1.jar urls[15] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/maven/doxia/doxia-decoration-model/1.0/doxia-decoration-model-1.0.jar urls[16] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/maven/doxia/doxia-module-apt/1.0/doxia-module-apt-1.0.jar urls[17] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/maven/doxia/doxia-module-fml/1.0/doxia-module-fml-1.0.jar urls[18] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/maven/doxia/doxia-module-xdoc/1.0/doxia-module-xdoc-1.0.jar urls[19] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/maven/doxia/doxia-module-xhtml/1.0/doxia-module-xhtml-1.0.jar urls[20] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/maven/shared/maven-common-artifact-filters/1.2/maven-common-artifact-f ilters-1 .2.jar urls[21] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/maven/shared/maven-plugin-testing-harness/1.1/maven-plugin-testing-har ness-1.1 .jar urls[22] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/codeh aus/plexus/plexus-archiver/1.0-alpha-7/plexus-archiver-1.0-alpha-7.jar urls[23] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/codeh aus/woodstox/wstx-asl/3.2.7/wstx-asl-3.2.7.jar urls[24] = file:/C:/Documents and Settings/subirs.W/.m2/repository/stax/stax -api/1.0.1/stax-api-1.0.1.jar [FATAL ERROR] Container realm = plexus.core urls[0] = file:/D:/apache-maven-2.1.0/lib/maven-2.1.0-uber.jar [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.maven.doxia.module.xhtml.XhtmlSink.writeEndTagWithoutEOL(Ljav a x/swing/text/html/HTML$Tag;)V [INFO] [INFO] Trace java.lang.NoSuchMethodError: org.apache.maven.doxia.module.xhtml.XhtmlSink.write EndTagWithoutEOL(Ljavax/swing/text/html/HTML$Tag;)V at org.apache.maven.doxia.module.xhtml.XhtmlSink.bold_(XhtmlSink.java:11 14) at org.codehaus.mojo.versions.AbstractVersionsReportRenderer.renderDepen dencySummaryTableRow
Re: [Versions Maven Plugin 1.0] FATAL Error thrown for versions:dependency-updates-report GOAL
: checking for updates from centr al [INFO] artifact org.apache.maven:maven-artifact: checking for updates from centr al [INFO] artifact org.apache.maven:maven-project: checking for updates from centra l [INFO] artifact org.apache.tomcat:juli: checking for updates from central [INFO] artifact org.apache.tomcat:tribes: checking for updates from central [INFO] artifact org.codehaus.mojo:rpm-maven-plugin: checking for updates from ce ntral [INFO] artifact org.codehaus.mojo.jspc:jspc-compiler-tomcat6: checking for updat es from central [INFO] artifact org.hibernate:hibernate-core: checking for updates from central [INFO] artifact org.testng:testng: checking for updates from central [INFO] artifact session-plugin3:session-plugin3: checking for updates from centr al [INFO] artifact taglibs:standard: checking for updates from central [FATAL ERROR] org.codehaus.mojo.versions.DependencyUpdatesReport#execute() cause d a linkage error (java.lang.NoSuchMethodError) and may be out-of-date. Check th e realms: [FATAL ERROR] Plugin realm = app0.child-container[org.codehaus.mojo:versions-mav en-plugin:1.0] urls[0] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/codeha us/mojo/versions-maven-plugin/1.0/versions-maven-plugin-1.0.jar urls[1] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/codeha us/plexus/plexus-utils/1.5.1/plexus-utils-1.5.1.jar urls[2] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apache /maven/reporting/maven-reporting-impl/2.0.4.1/maven-reporting-impl-2.0.4 .1.jar urls[3] = file:/C:/Documents and Settings/subirs.W/.m2/repository/commons-va lidator/commons-validator/1.2.0/commons-validator-1.2.0.jar urls[4] = file:/C:/Documents and Settings/subirs.W/.m2/repository/commons-be anutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar urls[5] = file:/C:/Documents and Settings/subirs.W/.m2/repository/commons-lo gging/commons-logging/1.0.4/commons-logging-1.0.4.jar urls[6] = file:/C:/Documents and Settings/subirs.W/.m2/repository/commons-di gester/commons-digester/1.6/commons-digester-1.6.jar urls[7] = file:/C:/Documents and Settings/subirs.W/.m2/repository/commons-co llections/commons-collections/3.2/commons-collections-3.2.jar urls[8] = file:/C:/Documents and Settings/subirs.W/.m2/repository/oro/oro/2. 0.8/oro-2.0.8.jar urls[9] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apache /maven/doxia/doxia-core/1.0-alpha-10/doxia-core-1.0-alpha-10.jar urls[10] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/maven/doxia/doxia-site-renderer/1.0/doxia-site-renderer-1.0.jar urls[11] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/codeh aus/plexus/plexus-i18n/1.0-beta-7/plexus-i18n-1.0-beta-7.jar urls[12] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/codeh aus/plexus/plexus-velocity/1.1.7/plexus-velocity-1.1.7.jar urls[13] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/velocity/velocity/1.5/velocity-1.5.jar urls[14] = file:/C:/Documents and Settings/subirs.W/.m2/repository/commons-l ang/commons-lang/2.1/commons-lang-2.1.jar urls[15] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/maven/doxia/doxia-decoration-model/1.0/doxia-decoration-model-1.0.jar urls[16] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/maven/doxia/doxia-module-apt/1.0/doxia-module-apt-1.0.jar urls[17] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/maven/doxia/doxia-module-fml/1.0/doxia-module-fml-1.0.jar urls[18] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/maven/doxia/doxia-module-xdoc/1.0/doxia-module-xdoc-1.0.jar urls[19] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/maven/doxia/doxia-module-xhtml/1.0/doxia-module-xhtml-1.0.jar urls[20] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/maven/shared/maven-common-artifact-filters/1.2/maven-common-artifact-f ilters-1 .2.jar urls[21] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/apach e/maven/shared/maven-plugin-testing-harness/1.1/maven-plugin-testing-har ness-1.1 .jar urls[22] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/codeh aus/plexus/plexus-archiver/1.0-alpha-7/plexus-archiver-1.0-alpha-7.jar urls[23] = file:/C:/Documents and Settings/subirs.W/.m2/repository/org/codeh aus/woodstox/wstx-asl/3.2.7/wstx-asl-3.2.7.jar urls[24] = file:/C:/Documents and Settings/subirs.W/.m2/repository/stax/stax -api/1.0.1/stax-api-1.0.1.jar [FATAL ERROR] Container realm = plexus.core urls[0] = file:/D:/apache-maven-2.1.0/lib/maven-2.1.0-uber.jar [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.maven.doxia.module.xhtml.XhtmlSink.writeEndTagWithoutEOL(Ljav a x
[ANN] Versions Maven Plugin 1.0 released
The Mojo team is pleased to announce the release of the Versions Maven Plugin, version 1.0. The Versions Plugin has the following goals. * versions:display-dependency-updates scans a project's dependencies and produces a report of those dependencies which have newer versions available. * versions:display-plugin-updates scans a project's plugins and produces a report of those plugins which have newer versions available. * versions:display-property-updates scans a projectand produces a report of those properties which are used to control artifact versions and which properies have newer versions available. * versions:update-parent updates the parent section of a project so that it references the newest available version. For example, if you use a corporate root POM, this goal can be helpful if you need to ensure you are using the latest version of the corporate root POM. * versions:update-properties updates properties defined in a project so that they correspond to the latest available version of specific dependencies. This can be useful if a suite of dependencies must all be locked to one version. * versions:update-child-modules updates the parent section of the child modules of a project so the version matches the version of the current project. For example, if you have an aggregator pom that is also the parent for the projects that it aggregates and the children and parent versions get out of sync, this mojo can help fix the versions of the child modules. (Note you may need to invoke Maven with the -N option in order to run this goal if your project is broken so badly that it cannot build because of the version mis-match). * versions:lock-snapshots searches the pom for all -SNAPSHOT versions and replaces them with the current timestamp version of that -SNAPSHOT, e.g. -20090327.172306-4 * versions:unlock-snapshots searches the pom for all timestamp locked snapshot versions and replaces them with -SNAPSHOT. * versions:resolve-ranges finds dependencies using version ranges and resolves the range to the specific version being used. * versuibs:set can be used to set the project version from the command line. * versions:use-releases searches the pom for all -SNAPSHOT versions which have been released and replaces them with the corresponding release version. * versions:use-next-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the next release version. * versions:use-latest-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the latest release version. * versions:use-next-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the next -SNAPSHOT version. * versions:use-latest-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the latest -SNAPSHOT version. * versions:use-next-versions searches the pom for all versions which have been a newer version and replaces them with the next version. * versions:use-latest-versions searches the pom for all versions which have been a newer version and replaces them with the latest version. * versions:commit removes the pom.xml.versionsBackup files. Forms one half of the built-in Poor Man's SCM. * versions:revert restores the pom.xml files from the pom.xml.versionsBackup files. Forms one half of the built-in Poor Man's SCM. The artifacts have been deployed to the mojo repository and have been mirrored to central. The Mojo Team. Release Notes - Maven 2.x Versions Plugin - Version 1.0 ** Bug * [MVERSIONS-38] - Rulessets are not correctly loaded from http uri's * [MVERSIONS-39] - update-properties throws NPE if a property is configured for updating but is not defined in the pom * [MVERSIONS-44] - versions:set Fails for Projects with No Dependencies * [MVERSIONS-45] - use-latest-versio ignores the allowSnapshots bug * [MVERSIONS-46] - IT it-display-dependency-updates-report-001 fails * [MVERSIONS-47] - IT it-display-plugin-updates-004 fails * [MVERSIONS-48] - IT it-update-properties-004 fails * [MVERSIONS-49] - IT it-update-properties-005 fails * [MVERSIONS-50] - remove the display-dependency-updates-report and replace with dependency-updates-report * [MVERSIONS-59] - versions:display-plugin-updates fails * [MVERSIONS-60] - NPE in versions:dependency-updates-report * [MVERSIONS-61] - it-dependency-updates-report-001 fails * [MVERSIONS-62] - it-plugin-updates-report-001 fails * [MVERSIONS-63] - it-update-properties-005 fails ** Improvement * [MVERSIONS-23] - Add possibility to include dependencymanagement in DisplayDependencyUpdates * [MVERSIONS-40] - [update-child-modules] Recursively process the whole hierarchy * [MVERSIONS-57] - Refactor display-dependency-updates to use
[ANN] Versions Maven Plugin 1.0-alpha-3 released
The Mojo team is pleased to announce the release of the Versions Maven Plugin, version 1.0-alpha-3. The Versions Plugin has the following goals. * versions:display-dependency-updates scans a project's dependencies and produces a report of those dependencies which have newer versions available. * versions:display-plugin-updates scans a project's plugins and produces a report of those plugins which have newer versions available. * versions:update-parent updates the parent section of a project so that it references the newest available version. For example, if you use a corporate root POM, this goal can be helpful if you need to ensure you are using the latest version of the corporate root POM. * versions:update-properties updates properties defined in a project so that they correspond to the latest available version of specific dependencies. This can be useful if a suite of dependencies must all be locked to one version. * versions:update-child-modules updates the parent section of the child modules of a project so the version matches the version of the current project. For example, if you have an aggregator pom that is also the parent for the projects that it aggregates and the children and parent versions get out of sync, this mojo can help fix the versions of the child modules. (Note you may need to invoke Maven with the -N option in order to run this goal if your project is broken so badly that it cannot build because of the version mis-match). * versions:lock-snapshots searches the pom for all -SNAPSHOT versions and replaces them with the current timestamp version of that -SNAPSHOT, e.g. -20090327.172306-4 * versions:unlock-snapshots searches the pom for all timestamp locked snapshot versions and replaces them with -SNAPSHOT. * versions:resolve-ranges finds dependencies using version ranges and resolves the range to the specific version being used. * versions:use-releases searches the pom for all -SNAPSHOT versions which have been released and replaces them with the corresponding release version. * versions:use-next-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the next release version. * versions:use-latest-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the latest release version. * versions:use-next-versions searches the pom for all versions which have been a newer version and replaces them with the next version. * versions:use-latest-versions searches the pom for all versions which have been a newer version and replaces them with the latest version. * versions:commit removes the pom.xml.versionsBackup files. Forms one half of the built-in Poor Man's SCM. * versions:revert restores the pom.xml files from the pom.xml.versionsBackup files. Forms one half of the built-in Poor Man's SCM. The artifacts have been deployed to the mojo repository and will be mirrored to central within the next 24 hours. The Mojo Team. Release Notes - Maven 2.x Versions Plugin - Version 1.0-alpha-3 ** Bug * [MVERSIONS-3] - display-plugin-updates does not identify the plugin version as not being provided when derived from the super-pom * [MVERSIONS-10] - Property Placedholders output in versions:display-plugin-updates * [MVERSIONS-13] - display-plugin-updates warns that version is not defined if same versio as in parent pom is defined ** Improvement * [MVERSIONS-25] - Users should be made aware that this plugin relies on accurate maven-metadata.xml files. ** New Feature * [MVERSIONS-15] - Add comparisonMethod=mercury * [MVERSIONS-18] - Expose updated versions as a report * [MVERSIONS-21] - Add mojo to lock snapshots to timestamp version * [MVERSIONS-24] - Enable resolution of dependency version ranges * [MVERSIONS-28] - use-releases mojo * [MVERSIONS-32] - Add versions:commit and versions:revert using a Poor-man's SCM so that changes to the pom can be accepted and rolled back * [MVERSIONS-33] - add use-next-releases goal * [MVERSIONS-34] - add a use-latest-releases goal * [MVERSIONS-35] - add use-next-versions goal * [MVERSIONS-36] - add use-latest-versions goal * [MVERSIONS-37] - add a use-releases goal that replaces -SNAPSHOT dependencies with their corresponding release version (if available) ** Task * [MVERSIONS-12] - Documentation is incorrect on http://mojo.codehaus.org/versions-maven-plugin/examples/update-parent.html ** Wish * [MVERSIONS-26] - Can't resolve pom properties for specifying plugin version in pluginmanagement
Re: versions-maven-plugin, complains about version of versions-maven-plugin
Known bugs fixed for 1.0-alpha-3... but I'm not ready for that to be released yet 2009/3/19 Reto Bachmann-Gmür r...@gmuer.ch Hello The output of mvn versions:display-plugin-updates [INFO] All plugins are using the latest versions. [INFO] [WARNING] The following plugins do not have their version specified: [WARNING] maven-clean-plugin .. (from super-pom) 2.2 adding the following to the parent-pom doesn't help, adding it to the pom itself does prevent the warning: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-clean-plugin/artifactId version2.3/version /plugin specifying an older version in the pom (not in the parent) yields to the correct output: [INFO] [INFO] The following plugin updates are available: [INFO] maven-clean-plugin ... 2.2 - 2.3 Cheers, Reto - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
versions-maven-plugin, complains about version of versions-maven-plugin
Hello The output of mvn versions:display-plugin-updates [INFO] All plugins are using the latest versions. [INFO] [WARNING] The following plugins do not have their version specified: [WARNING] maven-clean-plugin .. (from super-pom) 2.2 adding the following to the parent-pom doesn't help, adding it to the pom itself does prevent the warning: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-clean-plugin/artifactId version2.3/version /plugin specifying an older version in the pom (not in the parent) yields to the correct output: [INFO] [INFO] The following plugin updates are available: [INFO] maven-clean-plugin ... 2.2 - 2.3 Cheers, Reto - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Versions Maven Plugin 1.0-alpha-2 released
The Mojo team is pleased to announce the release of the Versions Maven Plugin, version 1.0-alpha-2. This plugin allows: * the querying for newer versions of plugins used in a project. * the querying for newer versions of dependencies used in a project. * updating a project's parent to the latest available version (e.g. useful for syncing with corporate poms to ensure the latest is used prior to rolling a release) * updating properties defined in a project to the latest version of a specific artifact (e.g. for ensuring that a suite of dependencies are all the same version) * fixing a multi-module build when the child projects reference an different version of the parent http://mojo.codehaus.org/versions-maven-plugin/ You can run mvn -up to get the latest version of the plugin, or specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdversions-maven-plugin/artifactId version1.0-alpha-2/version /plugin Release Notes - Maven 2.x Versions Plugin - Version 1.0-alpha-2 Bug * MVERSIONS-8 - If multiple properties require updating, only the first gets updated by versions:update-properties Improvement * MVERSIONS-5 - update-child-modules goal
Re: [ANN] Versions Maven Plugin 1.0-alpha-1 released
Does it work if you are not using the central repo directly but a repository manager (archiva in my case) in between. Will this plugin see the newer versions, even if they are not in archiva yet? regards, Wim 2008/9/5 Stephen Connolly [EMAIL PROTECTED] The Mojo team is pleased to announce the release of the Versions Maven Plugin, version 1.0-alpha-1. This plugin allows: * the querying for newer versions of plugins used in a project. * the querying for newer versions of dependencies used in a project. * updating a project's parent to the latest available version (e.g. useful for syncing with corporate poms to ensure the latest is used prior to rolling a release) * updating properties defined in a project to the latest version of a specific artifact (e.g. for ensuring that a suite of dependencies are all the same version) http://mojo.codehaus.org/versions-maven-plugin/ You can run mvn -up to get the latest version of the plugin, or specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdversions-maven-plugin/artifactId version1.0-alpha-1/version /plugin Release Notes - Maven 2.x Versions Plugin - Version 1.0-alpha-1 ** Bug * [MVERSIONS-1] - javadoc plugin doesn't have its version specified but it has * [MVERSIONS-2] - display-plugin-updates does not include lifecycle plugins that are not defined in the pom. ** Known Issues - Maven 2.x Versions Plugin - Version 1.0-alpha-1 * [MVERSIONS-3] - display-plugin-updates does not identify the plugin version as not being provided when derived from the super-pom Enjoy, -The Mojo team
Re: [ANN] Versions Maven Plugin 1.0-alpha-1 released
That is a good question... I would think that when you ask for the latest maven-metatdata.xml archivia will check if it's cache is out of date and then query central... if you do mvn -U do you get the latest version of a plugin automatically (if yes, then the answer is yes, if no then the answer is no) FYI, we're using nexus and have no issues in this regard -Stephen On Fri, Sep 5, 2008 at 7:46 AM, Wim Deblauwe [EMAIL PROTECTED] wrote: Does it work if you are not using the central repo directly but a repository manager (archiva in my case) in between. Will this plugin see the newer versions, even if they are not in archiva yet? regards, Wim 2008/9/5 Stephen Connolly [EMAIL PROTECTED] The Mojo team is pleased to announce the release of the Versions Maven Plugin, version 1.0-alpha-1. This plugin allows: * the querying for newer versions of plugins used in a project. * the querying for newer versions of dependencies used in a project. * updating a project's parent to the latest available version (e.g. useful for syncing with corporate poms to ensure the latest is used prior to rolling a release) * updating properties defined in a project to the latest version of a specific artifact (e.g. for ensuring that a suite of dependencies are all the same version) http://mojo.codehaus.org/versions-maven-plugin/ You can run mvn -up to get the latest version of the plugin, or specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdversions-maven-plugin/artifactId version1.0-alpha-1/version /plugin Release Notes - Maven 2.x Versions Plugin - Version 1.0-alpha-1 ** Bug * [MVERSIONS-1] - javadoc plugin doesn't have its version specified but it has * [MVERSIONS-2] - display-plugin-updates does not include lifecycle plugins that are not defined in the pom. ** Known Issues - Maven 2.x Versions Plugin - Version 1.0-alpha-1 * [MVERSIONS-3] - display-plugin-updates does not identify the plugin version as not being provided when derived from the super-pom Enjoy, -The Mojo team
Re: [ANN] Versions Maven Plugin 1.0-alpha-1 released
Yes, Archiva will proxy and merge the metadata as well if configured to do so. - Brett 2008/9/5 Stephen Connolly [EMAIL PROTECTED] That is a good question... I would think that when you ask for the latest maven-metatdata.xml archivia will check if it's cache is out of date and then query central... if you do mvn -U do you get the latest version of a plugin automatically (if yes, then the answer is yes, if no then the answer is no) FYI, we're using nexus and have no issues in this regard -Stephen On Fri, Sep 5, 2008 at 7:46 AM, Wim Deblauwe [EMAIL PROTECTED] wrote: Does it work if you are not using the central repo directly but a repository manager (archiva in my case) in between. Will this plugin see the newer versions, even if they are not in archiva yet? regards, Wim 2008/9/5 Stephen Connolly [EMAIL PROTECTED] The Mojo team is pleased to announce the release of the Versions Maven Plugin, version 1.0-alpha-1. This plugin allows: * the querying for newer versions of plugins used in a project. * the querying for newer versions of dependencies used in a project. * updating a project's parent to the latest available version (e.g. useful for syncing with corporate poms to ensure the latest is used prior to rolling a release) * updating properties defined in a project to the latest version of a specific artifact (e.g. for ensuring that a suite of dependencies are all the same version) http://mojo.codehaus.org/versions-maven-plugin/ You can run mvn -up to get the latest version of the plugin, or specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdversions-maven-plugin/artifactId version1.0-alpha-1/version /plugin Release Notes - Maven 2.x Versions Plugin - Version 1.0-alpha-1 ** Bug * [MVERSIONS-1] - javadoc plugin doesn't have its version specified but it has * [MVERSIONS-2] - display-plugin-updates does not include lifecycle plugins that are not defined in the pom. ** Known Issues - Maven 2.x Versions Plugin - Version 1.0-alpha-1 * [MVERSIONS-3] - display-plugin-updates does not identify the plugin version as not being provided when derived from the super-pom Enjoy, -The Mojo team -- Brett Porter Blog: http://blogs.exist.com/bporter/
Re: [ANN] Versions Maven Plugin 1.0-alpha-1 released
On Thu, Sep 4, 2008 at 7:18 PM, Stephen Connolly [EMAIL PROTECTED] wrote: The Mojo team is pleased to announce the release of the Versions Maven Plugin, version 1.0-alpha-1. This plugin allows: * the querying for newer versions of plugins used in a project. * the querying for newer versions of dependencies used in a project. * updating a project's parent to the latest available version (e.g. useful for syncing with corporate poms to ensure the latest is used prior to rolling a release) * updating properties defined in a project to the latest version of a specific artifact (e.g. for ensuring that a suite of dependencies are all the same version) http://mojo.codehaus.org/versions-maven-plugin/ You can run mvn -up to get the latest version of the plugin, or specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdversions-maven-plugin/artifactId version1.0-alpha-1/version /plugin Release Notes - Maven 2.x Versions Plugin - Version 1.0-alpha-1 ** Bug * [MVERSIONS-1] - javadoc plugin doesn't have its version specified but it has * [MVERSIONS-2] - display-plugin-updates does not include lifecycle plugins that are not defined in the pom. ** Known Issues - Maven 2.x Versions Plugin - Version 1.0-alpha-1 * [MVERSIONS-3] - display-plugin-updates does not identify the plugin version as not being provided when derived from the super-pom Enjoy, -The Mojo team My first attempt to run it gave this output that seems...incorrect: [INFO] The following dependency updates are available: [INFO] c3p0:c3p0 .. 0.9.1.2 - 0.9.0 -- Stephen Duncan Jr www.stephenduncanjr.com
Re: [ANN] Versions Maven Plugin 1.0-alpha-1 released
On Fri, Sep 5, 2008 at 9:24 AM, Stephen Duncan Jr [EMAIL PROTECTED]wrote: My first attempt to run it gave this output that seems...incorrect: [INFO] The following dependency updates are available: [INFO] c3p0:c3p0 .. 0.9.1.2 - 0.9.0 Sorry about the noise; I see from the FAQ that a fourth digit in a version number isn't handled numerically by default... -- Stephen Duncan Jr www.stephenduncanjr.com
Re: [ANN] Versions Maven Plugin 1.0-alpha-1 released
Yep, basically 4 digit version numbers are not in the maven format! On Fri, Sep 5, 2008 at 2:37 PM, Stephen Duncan Jr [EMAIL PROTECTED]wrote: On Fri, Sep 5, 2008 at 9:24 AM, Stephen Duncan Jr [EMAIL PROTECTED]wrote: My first attempt to run it gave this output that seems...incorrect: [INFO] The following dependency updates are available: [INFO] c3p0:c3p0 .. 0.9.1.2 - 0.9.0 Sorry about the noise; I see from the FAQ that a fourth digit in a version number isn't handled numerically by default... -- Stephen Duncan Jr www.stephenduncanjr.com
[ANN] Versions Maven Plugin 1.0-alpha-1 released
The Mojo team is pleased to announce the release of the Versions Maven Plugin, version 1.0-alpha-1. This plugin allows: * the querying for newer versions of plugins used in a project. * the querying for newer versions of dependencies used in a project. * updating a project's parent to the latest available version (e.g. useful for syncing with corporate poms to ensure the latest is used prior to rolling a release) * updating properties defined in a project to the latest version of a specific artifact (e.g. for ensuring that a suite of dependencies are all the same version) http://mojo.codehaus.org/versions-maven-plugin/ You can run mvn -up to get the latest version of the plugin, or specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdversions-maven-plugin/artifactId version1.0-alpha-1/version /plugin Release Notes - Maven 2.x Versions Plugin - Version 1.0-alpha-1 ** Bug * [MVERSIONS-1] - javadoc plugin doesn't have its version specified but it has * [MVERSIONS-2] - display-plugin-updates does not include lifecycle plugins that are not defined in the pom. ** Known Issues - Maven 2.x Versions Plugin - Version 1.0-alpha-1 * [MVERSIONS-3] - display-plugin-updates does not identify the plugin version as not being provided when derived from the super-pom Enjoy, -The Mojo team
