Maven versions plugin - Questions regarding updating versions in branches

[Børge Haugsdal]

---------- Forwarded message ----------
From: Børge Haugsdal <borge.haugsdal@...>
Date: 2009/10/30
Subject: Maven versions plugin - Questions regarding updating versions in branches
To: user@...

We have now more that 50 multi-module projects to manage each with 2-10 sub-modules.

The list is growing fast.

In out project we have a lot of dependencies between projects, so tagging and version management makes a lot of work, and creates a lot of hassle.

And we have right now 4 complete branches to manage at the same time.

I have tried now making scripts (shell and .bat) to handle the tagging process. And it works.

I must say that the versions plugin has saved us for a lot of work.

All version information is stored in properties like <logging.version>33.1.1</logging.version> in each multimodule pom.xml
All groupIds in our internal projects is made in the format <groupId>no.mycompany.area</groupId>

Tagging TRUNK using scripts - solved

When we tag the TRUNK we always tag all code if changes has been made in a module, and updates all modules to the latest versions of our internal dependencies.

So, we are able to automate the process just by listing the projects to tag in a given order, and then calling scripts to tag and update versions dependencies.

So the TRUNK is no problem anymore, much thanks to the maven versions plugin.

Tagging BRANCHES using scripts - still a problem

When it comes to the BRANCHES we still have problems.
I know that in the versions plugin it is possible to update to the newest versions using ranges defined in the poms.
But it seems to me like have to change each pom for each time we create a branch with range information, and add our dependencies twice in the pom, once in dependency list and once in the plugin def. itself.

As far as I have understood the process...
So the pom grows and it becomes more work to manage it. .
I hope I can do this without doing a lot of changes in the poms.

I hope I can script tagging of branches too.
When we are working in trunk we have the same majorVersion and minorVersion in all projects. Like 33.1.X

When we create a new branch from trunk, we update the versions in the TRUNK poms. Like 34.1.0

So in our branch coming from the trunk version 33.1.X we want to always use the latest release or snapshot versions in the range 33.1.0.0 to 34.0.0

So (finally) my question is:
Is there a way that I from a script/command-line can specify that for a given groupId I want to update all versions stored in the pom (in <properties>) for all of our dependencies, with versions higher that 33.1.0.0 and less that 34.0.0

Example update to latest RELEASE version of all our artifacts in the branch:
mvn versions:update-properties -DGroupId=no.<mycompany> -DVersionRange=[33.1.0.0,34.0.0)

Example update to latest SNAPSHOT version of all our artifacts in the branch:
mvn versions:update-properties -DGroupId=no.<mycompany> -DVersionRange=[33.1.0,34.0.0) -DallowSnapshot -DexcludePeroperties="XX.version,YY.version"

Is something like this possible?
What is the best solution for this?

I hope you can help me out here.

Another, and less important question.

It would be nice to have a command like this:
mvn versions:update-properties -DGroupId=no.<mycompany> -DVersionRange=[33.1.0,33.2.0) -DallowSnapshots -DexcludeGroupIds="no-<mycompany>.common"

Right now the excludeProterties is growing fast.

All of our modules always in stable versions has a common groupId like above. The list with dependencies to exclude is growing, so I hope for an easier way.

I hope you have time for my questions...

Best Regards

Børge Haugsdal

--
Hilsen

Børge Haugsdal

--
Hilsen

Børge Haugsdal

[Stephen Connolly-2]

2009/10/30 Børge Haugsdal <borge.haugsdal@...>:

>
>
> ---------- Forwarded message ----------
> From: Børge Haugsdal <borge.haugsdal@...>
> Date: 2009/10/30
> Subject: Maven versions plugin - Questions regarding updating versions in
> branches
> To: user@...
>
>
> We have now more that 50 multi-module projects to manage each with 2-10
> sub-modules.
> The list is growing fast.
>
> In out project we have a lot of dependencies between projects, so tagging
> and version management makes a lot of work, and creates a lot of hassle.
>
> And we have right now 4 complete branches to manage at the same time.
>
> I have tried now making scripts (shell and .bat) to handle the tagging
> process. And it works.
> I must say that the versions plugin has saved us for a lot of work.
> All version information is stored in properties like
> <logging.version>33.1.1</logging.version> in each multimodule pom.xml

the main use-case for properties defining versions is where you have a
suite of dependencies which must have their version aligned.

If you are not in that use-case I would use the
http://mojo.codehaus.org/versions-maven-plugin/examples/advancing-dependency-versions.html
goals
as they support filtering exactly which groupId/artifactIds to
advance, and can limit advancing to minor updates only

> All groupIds in our internal projects is made in the format
> <groupId>no.mycompany.area</groupId>
>
> Tagging TRUNK using scripts - solved
> When we tag the TRUNK we always tag all code if changes has been made in a
> module, and updates all modules to the latest versions of our internal
> dependencies.
> So, we are able to automate the process just by listing the projects to tag
> in a given order, and then calling scripts to tag and update versions
> dependencies.
> So the TRUNK is no problem anymore, much thanks to the maven versions
> plugin.
>
> Tagging BRANCHES using scripts - still a problem
> When it comes to the BRANCHES we still have problems.
> I know that in the versions plugin it is possible to update to the newest
> versions using ranges defined in the poms.
> But it seems to me like have to change each pom for each time we create a
> branch with range information, and add our dependencies twice in the pom,
> once in dependency list and once in the plugin def. itself.
> As far as I have understood the process...
> So the pom grows and it becomes more work to manage it. .
> I hope I can do this without doing a lot of changes in the poms.
>
> I hope I can script tagging of branches too.
> When we are working in trunk we have the same majorVersion and minorVersion
> in all projects. Like 33.1.X
> When we create a new branch from trunk, we update the versions in the TRUNK
> poms. Like 34.1.0
>
> So in our branch coming from the trunk version 33.1.X we want to always use
> the latest release or snapshot versions in the range 33.1.0.0 to 34.0.0
>
> So (finally) my question is:
> Is there a way that I from a script/command-line can specify that for a
> given groupId I want to update all versions stored in the pom (in
> <properties>) for all of our dependencies, with versions higher that
> 33.1.0.0 and less that 34.0.0
>
> Example update to latest RELEASE version of all our artifacts in the branch:
> mvn versions:update-properties -DGroupId=no.<mycompany>
> -DVersionRange=[33.1.0.0,34.0.0)
>
> Example update to latest SNAPSHOT version of all our artifacts in the
> branch:
> mvn versions:update-properties -DGroupId=no.<mycompany>
> -DVersionRange=[33.1.0,34.0.0) -DallowSnapshot
> -DexcludePeroperties="XX.version,YY.version"
>
> Is something like this possible?
> What is the best solution for this?
>
> I hope you can help me out here.
>
> Another, and less important question.
> It would be nice to have a command like this:
> mvn versions:update-properties -DGroupId=no.<mycompany>
> -DVersionRange=[33.1.0,33.2.0) -DallowSnapshots
> -DexcludeGroupIds="no-<mycompany>.common"
> Right now the excludeProterties is growing fast.
> All of our modules always in stable versions has a common groupId like
> above. The list with dependencies to exclude is growing, so I hope for an
> easier way.
>
> I hope you have time for my questions...
>
> Best Regards
>
> Børge Haugsdal
>
>
>
>
> --
> Hilsen
>
> Børge Haugsdal
>
>
>
> --
> Hilsen
>
> Børge Haugsdal
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email