maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
Date Thu, 01 Aug 2013 23:10:36 GMT
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.connolly@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.connolly@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.connolly@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 <scolebourne@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.connolly@gmail.com> wrote:
>> >> >> > first
>> o---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> --
> Sent from my phone
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message