maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <scolebou...@joda.org>
Subject Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
Date Thu, 01 Aug 2013 17:20:19 GMT
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 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</artifactId>
>> >   <version>2.1-SNAPSHOT</version>
>> > </project>
>> >
>> > from the root of the project you type
>> >
>> > $ mvn versions:set -f B/pom.xml -DnewVersion=2.2-SNAPSHOT
>> >
>> > What happens is that the goal's groupId defaults (as no property was set)
>> > to the groupId of B, the artifactId defaults to the artifactId of B, the
>> > oldVersion defaults to the current version of B and the plugin starts
>> > building up its list of changes.
>> >
>> > Initial list:
>> >
>> > 1. B:2.1-SNAPSHOT -> B:2.2-SNAPSHOT
>> >
>> > Now it starts looking to see if it can grow the effective reactor... the
>> > parent directory has a pom and the pom has <module>B</module> so
it can
>> > grow the effective reactor adding A and all the modules referenced by A
>> > into it's list of poms to check. In A's parent directory there is no pom
>> > with a <module>A</module> so it stops growing the reactor. It now
has the
>> > following list of poms to check:
>> >
>> > A,B,C,D,E,F,G
>> >
>> > It looks to see what the effect of changing B's version is on that set of
>> > poms....
>> >
>> > A -> no change
>> > B -> no new changes
>> > C -> inherits version from parent => add C to list of changes and start
>> > again
>> >
>> > List of changes:
>> >
>> > 1. B:2.1-SNAPSHOT -> B:2.2-SNAPSHOT
>> > 2. C:2.1-SNAPSHOT -> C:2.2-SNAPSHOT
>> >
>> > A -> no change
>> > B -> no new changes
>> > C -> no new changes
>> > D -> parent changes, but D also explicitly sets version -> leave D's
>> > version unchanged
>> > E -> no change
>> > F -> dependency on C has changed -> update dependency
>> > G -> no change
>> >
>> > The list of changes has not been mutated this time, so we now have the
>> > complete final models to apply
>> >
>> > Then the poms get updated.
>> >
>> > So if you start with everything at 2.1-SNAPSHOT, you will end up with
>> >
>> > A:2.1-SNAPSHOT
>> > B:2.2-SNAPSHOT
>> > C:2.2-SNAPSHOT
>> > D:2.1-SNAPSHOT
>> > E:2.1-SNAPSHOT
>> > F:2.1-SNAPSHOT
>> > G:2.1-SNAPSHOT
>> >
>> > *and* the reactor maintains its intra module reationships as the
>> > dependencies have been updated.
>> >
>> > If you want to achieve the same result without the -f or changing working
>> > directory, you can tell it the groupId and artifactId of the change to
>> > make, e.g.
>> >
>> > $ mvn -DgroupId=... -DartifactId=B -DoldVersion=2.2-SNAPSHOT
>> > -DnewVersion=2.1-SNAPSHOT
>> >
>> > from the directory with A in it will undo all those changes
>> >
>> >
>> >
>> >
>> >
>> >
>> > On 1 August 2013 14:17, Stephen Colebourne <scolebourne@joda.org> wrote:
>> >
>> >> The problem is that as it currently stands, the plugin gives the
>> >> appearance of randomly choosing when to change versions. If you
>> >> consider the second example, the set goal changes R, A, B, D and E,
>> >> but not C, despite C being a child of A and in A's aggregator. Its
>> >> hard to not describe that as a bug.
>> >>
>> >> Thus, I'm sure you can see the logic of what it is trying to do, but
>> >> as a user I just want it to change x to y wherever it sees it in the
>> >> whole aggregator build. If that needs a separate goal, then so be it.
>> >>
>> >> I'm not sure how to proceed. The current plugin is useless for my
>> >> scenario without a separate script file to manually loop around the
>> >> structure. Its clearly useless for other people using aggregators.
>> >> You're wildcard suggestion might be an OK solution, but I'd have no
>> >> idea to implement it.
>> >>
>> >> I simply want a goal that allows a multi-module build, where the
>> >> modules are versioned in lock-step, to be updated. Is that too much to
>> >> hope for?
>> >>
>> >> Stephen
>> >>
>> >>
>> >> On 1 August 2013 13:50, Stephen Connolly
>> >> <stephen.alan.connolly@gmail.com> wrote:
>> >> > the correct way I see to handle this is to support wildcards in
>> >> > versions:set, e.g.
>> >> >
>> >> > mvn versions:set -DgroupId=* -DartifactId=* -DoldVersion=*
>> >> > -DnewVersion=1.2-SNAPSHOT
>> >> >
>> >> > which would therefore match not just the invoked project but all
>> projects
>> >> > in the reactor.
>> >> >
>> >> > The changes in MVERSIONS-131 go against the original spirit of the
>> goal
>> >> > (namely you cd to the module you want to change and ask for it to be
>> >> > changed... the effective reactor is grown and all references
>> down-stream
>> >> of
>> >> > that module's version change are updated accordingly.
>> >> >
>> >> > If C does not have a parent effected by the change you are making
>> then C
>> >> > should not be changed by versions:set (without wildcard support)
>> >> >
>> >> >
>> >> > On 1 August 2013 13:25, Stephen Colebourne <scolebourne@joda.org>
>> wrote:
>> >> >
>> >> >> I think this is perhaps related to problems I am seeing right now
as
>> >> well.
>> >> >>
>> >> >> Basically, the versions:set goal is buggy except in the classic
case
>> >> >> where the hierarchy of aggregation matches the hierarchy of
>> >> >> inheritance.
>> >> >>
>> >> >> See
>> >> >> http://jira.codehaus.org/browse/MVERSIONS-131
>> >> >> and
>> >> >> http://jira.codehaus.org/browse/MVERSIONS-184
>> >> >>
>> >> >> For example, given a tree:
>> >> >> A (pom only)
>> >> >> - B
>> >> >> - C (pom only)
>> >> >> - - D
>> >> >> - - E
>> >> >> where B and C are children of A
>> >> >> and D and E are children of C
>> >> >> and A aggregates B and C
>> >> >> and C aggregates D and E
>> >> >> In this case, versions:set plugin will work fine
>> >> >>
>> >> >> Now consider adding a new root R which aggregates A, but is not
the
>> >> parent
>> >> >> of A.
>> >> >> If you run versions:set on R it will only update R, and not A/B/C/D/E
>> >> >>
>> >> >> If you manually set the version of A, and then run versions:set
on R,
>> >> >> projects R/A/B/D/E will be updated, but not C. (which is pretty
>> weird)
>> >> >>
>> >> >> The patch in MVERSIONS-131 sounds reasonable. Could it be evaluated?
>> >> >>
>> >> >> Stephen
>> >> >>
>> >> >>
>> >> >>
>> >> >> On 1 August 2013 09:55, Stephen Connolly
>> >> >> <stephen.alan.connolly@gmail.com> wrote:
>> >> >> > How I want this to work is to have versions-maven-plugin have
a
>> way to
>> >> >> undo
>> >> >> > versions:resolve-ranges (
>> >> >> >
>> >> http://mojo.codehaus.org/versions-maven-plugin/resolve-ranges-mojo.html
>> )
>> >> >> -
>> >> >> > it would need to ensure that the lower bound of any unresolved
>> range
>> >> is
>> >> >> the
>> >> >> > resolved version... [see below]
>> >> >> >
>> >> >> > We'd need to split preparationGoals in the release plugin...
either
>> >> into
>> >> >> > preparationGoals + verificationGoals or into initiationGoals
+
>> >> >> > preparationGoals (I favour the latter as it preserves the
>> semantics of
>> >> >> > preparationGoals... but the first one maps more correctly
with what
>> >> each
>> >> >> > set should be doing)
>> >> >> >
>> >> >> > Then this would become super easy...
>> >> >> >
>> >> >> > You develop with version ranges for your dependencies...
>> >> >> >
>> >> >> > The release plugin would have
>> >> >> >     initiationGoals = versions:resolve-ranges versions:commit
>> >> >> >     preparationGoals = clean verify
>> >> >> >     completionGoals = versions:unresolve-ranges versions:commit
>> >> >> >
>> >> >> > So say your development pom has
>> >> >> >
>> >> >> > <dependency>
>> >> >> >   ...
>> >> >> >   <artifactId>foo</artifactId>
>> >> >> >   <version>[1.0,2.0)</version>
>> >> >> > </dependency>
>> >> >> >
>> >> >> > and the latest version of foo is 1.2
>> >> >> >
>> >> >> > When you kick off the release, the range gets resolved to
>> >> >> >
>> >> >> > <dependency>
>> >> >> >   ...
>> >> >> >   <artifactId>foo</artifactId>
>> >> >> >   <version>1.2<?versions range="[1.0,2.0)"?></version>
>> >> >> > </dependency>
>> >> >> >
>> >> >> > (My current thought is to use an XML PI to stash the old range)
>> >> >> >
>> >> >> > Then we invoke Maven again (because Maven doesn't re-read
the poms)
>> >> and
>> >> >> do
>> >> >> > a "clean verify" to make sure that this all builds
>> >> >> >
>> >> >> > Then we tag the release
>> >> >> >
>> >> >> > Then we run completionGoals and versions:unresolve-ranges
puts the
>> >> >> version
>> >> >> > range back, but upping the lower bound
>> >> >> >
>> >> >> > <dependency>
>> >> >> >   ...
>> >> >> >   <artifactId>foo</artifactId>
>> >> >> >   <version>[1.2,2.0)</version>
>> >> >> > </dependency>
>> >> >> >
>> >> >> > Maven ups the pom version to next development snapshot and
commits
>> the
>> >> >> pom
>> >> >> >
>> >> >> > That will give you the ability to develop on ranges (which
is nice
>> and
>> >> >> > flexible) but release on pinned versions (which is exactly
what you
>> >> >> should
>> >> >> > be doing)
>> >> >> >
>> >> >> > If we cannot deliver something like that, then I think we
should
>> just
>> >> >> drop
>> >> >> > ranges from the next major version of Maven.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On 1 August 2013 06:19, Nestor Urquiza <nestor.urquiza@gmail.com>
>> >> wrote:
>> >> >> >
>> >> >> >> Hi,
>> >> >> >>
>> >> >> >> Let me give more information,
>> >> >> >>
>> >> >> >> I use an aggregator project for war1 project:
>> >> >> >>     <modules>
>> >> >> >>         <module>../jar1</module>
>> >> >> >>         <module>../jar2</module>
>> >> >> >>         <module>../war-inc</module>
>> >> >> >>         <module>../war1</module>
>> >> >> >>     </modules>
>> >> >> >>
>> >> >> >> Another aggregator project for war2 project:
>> >> >> >>     <modules>
>> >> >> >>         <module>../jar1</module>
>> >> >> >>         <module>../war-inc</module>
>> >> >> >>         <module>../war1</module>
>> >> >> >>     </modules>
>> >> >> >>
>> >> >> >> Notice they both depend on jar1. The jar2 project in fact
depends
>> >> also
>> >> >> on
>> >> >> >> jar1. The war-inc project is used to keep common web resources
for
>> >> war1
>> >> >> and
>> >> >> >> war2. We use maven overlay to marge those shared resources
in a
>> final
>> >> >> war
>> >> >> >> for each project.
>> >> >> >>
>> >> >> >> This is working like a charm. It has been working in fact
now for
>> 3
>> >> >> years.
>> >> >> >> However everytime we need a release we need to start updating
>> version
>> >> >> >> unmbers in dependencies, doing prepare, then perform,
you know the
>> >> >> story.
>> >> >> >> This is great when the team releases every once in a while.
This
>> is
>> >> an
>> >> >> >> issue
>> >> >> >> if you want to release several times a day. About resources
needed
>> >> and
>> >> >> so
>> >> >> >> on
>> >> >> >> that is something we are tackling via idempotent scripts
so we are
>> >> >> >> literally
>> >> >> >> ready to make sure we increase the version number for
all
>> projects at
>> >> >> once
>> >> >> >> every time new code is committed to the version control
server. We
>> >> can
>> >> >> >> handle that last part with jenkins, that is not a problem
either.
>> The
>> >> >> only
>> >> >> >> problem is how can I leverage on an existing tool (without
>> building
>> >> it
>> >> >> >> myself) that would allow to release all modules from just
one
>> >> command.
>> >> >> >>
>> >> >> >> So back to Roger suggestion I added the version override
>> dependency
>> >> as
>> >> >> per
>> >> >> >> the github project, updated the version tag to point to
0.2.0 and
>> run
>> >> >> the
>> >> >> >> below command (including actually the very same example
from
>> github):
>> >> >> >> mvn clean install -Dversion.override=1.2.3-RC-5
>> >> >> >>
>> >> >> >> However none of the modules were changed including no
change to
>> the
>> >> >> >> aggregator project either.
>> >> >> >>
>> >> >> >> Roger, have you used this plugin with aggregator projects
as I am
>> >> >> trying?
>> >> >> >> Could you provide some further guidance?
>> >> >> >>
>> >> >> >> My option is looking more and more like I will need to
do
>> something
>> >> >> like:
>> >> >> >> foreach module
>> >> >> >>   replace module version
>> >> >> >>   for each dependency
>> >> >> >>     if it is a module
>> >> >> >>       replace module version
>> >> >> >>
>> >> >> >> Then find out if mvn:prepare and mvn:perform will work
after from
>> the
>> >> >> >> aggregator project releasing all necessary projects correctly.
At
>> >> this
>> >> >> >> point
>> >> >> >> I am already facing another issue. Let us suppose I update
my two
>> war
>> >> >> >> multi-pom aggregator projects, all the modules and the
>> dependencies
>> >> to
>> >> >> be
>> >> >> >> version 2.2000.0-SNAPSHOT.
>> >> >> >>
>> >> >> >> I would expect a command line the below to change the
version
>> number
>> >> in
>> >> >> all
>> >> >> >> modules to 2.2000.0, tag it preparing it for release as
well as
>> >> setting
>> >> >> the
>> >> >> >> next development version to be 2.2000.1-SNAPSHOT for all
modules
>> as
>> >> >> well.
>> >> >> >> Finally each dependency that is a module itself should
also be
>> >> changed
>> >> >> to
>> >> >> >> 2.2000.1-SNAPSHOT. But that does not work either:
>> >> >> >> mvn clean --batch-mode release:prepare -DdryRun=true
>> >> >> >> -DautoVersionSubmodules=true -DreleaseVersion=2.2000.0
>> >> >> >> -DdevelopmentVersion=2.2000.1-SNAPSHOT
>> >> >> >>
>> >> >> >> The resulting pom.xml.tag gets updated even dependencies
but the
>> >> >> >> pom.xml.next gets updated (2.2000.1-SNAPSHOT) only for
the version
>> >> >> number
>> >> >> >> of
>> >> >> >> each project, nor for the dependencies which do stay the
same
>> >> >> >> (2.2000.0-SNAPSHOT). Will this be considered a bug?
>> >> >> >>
>> >> >> >> I hope it is clear now what I need and also what the current
>> issues
>> >> are:
>> >> >> >> Not
>> >> >> >> only versions:set and release:update-version do not work
for
>> >> >> >> multipom-aggregator projects but in addition release:prepare
>> together
>> >> >> with
>> >> >> >> all the flags above which according to the documentation
should be
>> >> >> allowing
>> >> >> >> to fix a version for a release.
>> >> >> >>
>> >> >> >> I guess an alternative question could be "how to provide
>> continuous
>> >> >> >> delivery
>> >> >> >> with multi-pom aggregator maven projects". To be honest
I do not
>> like
>> >> >> the
>> >> >> >> idea of forcing all versions, it just looked the logical
approach
>> >> after
>> >> >> we
>> >> >> >> decided we really did not care for internal versions,
they could
>> be
>> >> >> handled
>> >> >> >> ideally automatically. However thinking twice about this
I would
>> like
>> >> >> >> better
>> >> >> >> maven to accept a pattern to set part of the snapshot
version
>> number
>> >> >> while
>> >> >> >> changing another part of it, for example with a mask:
>> >> >> >>
>> >> >> >> -DversionNumberIncrementalMask=x.1.0
>> >> >> >>
>> >> >> >> which would translate to:
>> >> >> >> Leave first digit as is
>> >> >> >> Increase by 1 second digit
>> >> >> >> set to zero third digit
>> >> >> >>
>> >> >> >> Of course I would expect this to be applied to all snapshots.
>> >> >> >>
>> >> >> >> Thanks for the answers so far,
>> >> >> >>
>> >> >> >> - Nestor
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> View this message in context:
>> >> >> >>
>> >> >>
>> >>
>> http://maven.40175.n5.nabble.com/continuous-releasing-versions-set-and-or-release-update-version-to-release-an-aggregator-project-tp5766275p5766461.html
>> >> >> >> Sent from the Maven - Users mailing list archive at Nabble.com.
>> >> >> >>
>> >> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> >> >> >> For additional commands, e-mail: users-help@maven.apache.org
>> >> >> >>
>> >> >> >>
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> >> >> For additional commands, e-mail: users-help@maven.apache.org
>> >> >>
>> >> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: users-help@maven.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>

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


Mime
View raw message