I'll try and test it tomorrow.

However, I'd encourage you to take a step back and think if the use of
three extra arguments to the plugin, which is primarily intended for
command line use, is a pleasant UI. I'd also encourage you to consider
whether updating a single GAV wherever it is found is really the same
concept as updating a tree (potentially with filtering to reduce its
scope).

Using
 mvn versions:set-aggregated
is a lot more pleasant than
 mvn versions:set -DgroupId=* -DartifactId=* -Dversion=*
particularly when the use cases are pretty different.

I don't think I'm asking to throw away today's changes, just to
repackage them in a more friendly way.

Stephen


On 2 August 2013 00:10, Stephen Connolly
<stephen.alan.conno...@gmail.com> wrote:
> Fixed in r18607 and I've redeployed a 2.2-SNAPSHOT
>
> I now have test cases and I have verified that there are no regressions.
>
> Just have to decide if there is anything else I will add before cutting a
> release
>
>
> On 1 August 2013 18:54, Stephen Connolly 
> <stephen.alan.conno...@gmail.com>wrote:
>
>>
>>
>> On Thursday, 1 August 2013, Stephen Colebourne wrote:
>>
>>> 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:
>>
>>
>> I'll have a look
>>
>>
>>>
>>> [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
>>> o---------------------------------------------------------------------
>>>
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
>>
>> --
>> Sent from my phone
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Reply via email to