No, I didn't use the wildcards (they are very unatural UI for solving
what seems like a normal case)
With wildcards I got NPE:
[ERROR] Failed to execute goal org.codehaus.mojo:versions-maven-plugin:2.2-SNAPS
HOT:set (default-cli) on project london-dev: Execution default-cli of goal org.c
odehaus.mojo:versions-maven-plugin:2.2-SNAPSHOT:set failed. NullPointerException
-> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal o
rg.codehaus.mojo:versions-maven-plugin:2.2-SNAPSHOT:set (default-cli) on project
london-dev: Execution default-cli of goal org.codehaus.mojo:versions-maven-plug
in:2.2-SNAPSHOT:set failed.
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor
.java:225)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor
.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor
.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje
ct(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje
ct(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBu
ild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(Lifecycl
eStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Laun
cher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.jav
a:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(La
uncher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:
352)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-c
li of goal org.codehaus.mojo:versions-maven-plugin:2.2-SNAPSHOT:set failed.
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Default
BuildPluginManager.java:110)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor
.java:209)
... 19 more
Caused by: java.lang.NullPointerException
at org.codehaus.mojo.versions.SetMojo.applyChange(SetMojo.java:258)
at org.codehaus.mojo.versions.SetMojo.execute(SetMojo.java:233)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Default
BuildPluginManager.java:101)
... 20 more
Stephen
On 1 August 2013 18:25, Stephen Connolly
<stephen.alan.conno...@gmail.com> wrote:
> Yeah I need to write some tests...
>
> You did use wildcards by the way? ie
>
> $ mvn versions:set -DgroupId=\* -DartifactId=\* -DoldVersion=\*
> -Dversion=...
>
> Keep in mind you need to escape the wildcard appropriate for your shell or
> it will replace with a glob that can never match
>
>
> On Thursday, 1 August 2013, Stephen Colebourne wrote:
>
>> I pulled svn and tried it, and it didn't work in my case. It didn't
>> even set the root aggregator pom.
>>
>> My set-aggregated goal is here and does work:
>> https://gist.github.com/jodastephen/6133391
>>
>> Unfortunately, half my test project is private so its hard to
>> describe/publish logs.
>>
>> Stephen
>>
>>
>>
>> On 1 August 2013 16:25, Stephen Connolly
>> <stephen.alan.conno...@gmail.com> wrote:
>> > Please try 2.2-SNAPSHOT
>> >
>> > It may or may have wildcard support that works and doesn't cause any
>> > regressions...
>> >
>> > I need to write some tests for the wildcard stuff.
>> >
>> >
>> > On 1 August 2013 15:39, Stephen Colebourne <scolebou...@joda.org> wrote:
>> >
>> >> Thanks for the detailed description, which I hope your making a web page
>> >> out of.
>> >>
>> >> Here is the current description "Sets the current projects version,
>> >> updating the details of any child modules as necessary." From that I
>> >> conclude it will set the current project version and any child modules
>> >> necessary to make it all match.
>> >>
>> >> It also says "The set goal can be used to update the version of the
>> >> current module. It will automatically climb up local directories to
>> >> find the aggregation root. It will automatically update explicitly
>> >> referenced dependencies"
>> >>
>> >> Again, the expectation is that it will correctly set all the versions
>> >> I want it to set. From oldVersion to newVersion.
>> >>
>> >> Basically, it seems to be being too clever for its own good.
>> >>
>> >> As it is, even a batch script cnanot achieve my goal. I have projects
>> like
>> >> this:
>> >>
>> >> A
>> >> B
>> >> C
>> >> - D
>> >> - E
>> >> F
>> >>
>> >> where A and B are children of C, but not within the aggregator of C
>> >> (unlike D and E which are children and are within the aggregator). I
>> >> have a separate overall aggregator R that runs A, B and C.
>> >>
>> >> If I set the version of C, and then try to set the version of A or B,
>> >> the plugin fails with "Project version is inherited from parent".
>> >>
>> >> So, I get that I'm trying to use the plugin for something you didn't
>> >> intend, but there isn't an alternative here that does do what I want,
>> >> right?
>> >>
>> >> So, we really need a new goal - versions:set-aggregated - which sets
>> >> every matching version within an aggregated pom structure when called
>> >> from the root.
>> >>
>> >> Would you want such a thing included in the versions plugin? Or does
>> >> it need to be a separate plugin?
>> >>
>> >> I have to have something, as the alternative is stupid amounts of manual
>> >> work.
>> >>
>> >> Stephen
>> >>
>> >>
>> >>
>> >> On 1 August 2013 14:36, Stephen Connolly
>> >> <stephen.alan.conno...@gmail.com> wrote:
>> >> > first off versions:set is a @aggregator mojo. That means it only
>> operates
>> >> > on the -f specified pom file or the pom file in the working directory.
>> >> >
>> >> > The goal is to update *that one project's version* it is not trying to
>> >> > update other project versions.
>> >> >
>> >> > So if you have
>> >> >
>> >> > A
>> >> > +B
>> >> > |+C
>> >> > |+D
>> >> > +E
>> >> > |+F
>> >> > \G
>> >> >
>> >> > where C and D inherits from B, F inherits from E and depends on C, A
>> is
>> >> an
>> >> > aggregator with no parent-child relationship and G is a standalone
>> >> project
>> >> > that depends on F directly
>> >> >
>> >> > Further we have in C
>> >> >
>> >> > <project>
>> >> > <parent>
>> >> > ...
>> >> > <artifactId>B</artifactId>
>> >> > <version>2.1-SNAPSHOT</version>
>> >> > </parent>
>> >> > <artifactId>C</artifactId>
>> >> > <!-- no version tag -->
>> >> > </project>
>> >> >
>> >> > and in D
>> >> >
>> >> > <project>
>> >> > <parent>
>> >> > ...
>> >> > <artifactId>B</artifactId>
>> >> > <version>2.1-SNAPSHOT</version>
>> >> > </parent>
>> >> > <artifactId>D</artifactI
>
>
>
> --
> Sent from my phone
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
