On Friday, 2 August 2013, Stephen Colebourne wrote:

> 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.


If you are going to do it on a regular basis you either script it or set up
a profile for doing it and then it's just

$ mvn -Pupdate-versions -DnewVersion=2.1-SNAPSHOT

Or if you want to have the profile auto-activated

$ mvn -Dupdated.version=2.1-SNAPSHOT

Where the profile has a defaultGoal of `validate` and you bind
`versions:set` to that phase and inject all the configured wildcards and
inject newVersion as ${updated.version}

That gives you a very error-proof repeated process.

The use of wildcard-like behaviour is not a good plan, so being slightly
more cumbersome on the CLI is a bonus from my PoV.

I prefer to encourage best practice by making non-best practice harder...
Making it impossible is not a good idea IMHO.

- Stephen



>
> 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.codehau



-- 
Sent from my phone

Reply via email to