Versioning and Continuous Delivery

[podenski]

I just read this article and like the approach to versioning. This author stopped using the Maven release plugin and replaced it with a nice, simple approach:

<https://jamesbetteley.wordpress.com/2011/07/07/what-is-in-a-name-usually-a-version-number-actually/>

There was a previous discussion here and in the Maven forum regarding this topic that never really came down to anything near as simple as the article describes.

[Steve Smith]

Hi

It is indeed a good idea. I've been working on something similar to
James at http://code.google.com/p/conduit/wiki/VersioningInAPipeline

What I *really* like about taking version responsibility away from
Maven is that you can establish proper versioning boundaries - the VCS
knows about revision numbers, the CI/CD server knows about build
numbers, and the Release Manager knows about release versions. Maven
muddles the waters, as well as hindering Continuous Delivery

S

On Aug 20, 6:06 pm, podenski <pat.poden...@gmail.com> wrote:
> I just read this article and like the approach to versioning. This author
> stopped using the Maven release plugin and replaced it with a nice, simple
> approach:
>

> <https://jamesbetteley.wordpress.com/2011/07/07/what-is-in-a-name-usua...>

[podenski]

In following the Maven versioning approach recommended by James Betteley < https://jamesbetteley.wordpress.com/2011/07/07/what-is-in-a-name-usually-a-version-number-actually/ > I ran into a warning in Maven regarding the use of an expression for the project's version number. The build was still successful (on the command line at least, although I'm having issues in Jenkins).

Has anyone else reading this gone down the same path and dealt with the warning (see below)? Is this error likely to cause further problems in the future if Maven tightens its error handling scheme?

[INFO] Scanning for projects...

[WARNING]

[WARNING] Some problems were encountered while building the effective model for com.foo.library:continuous-delivery:jar:1.2.0-67936

[WARNING] 'version' contains an expression but should be a constant. @ com.foo.library:continuous-delivery:${main.version}-${build.number}, /export/home/patp/CONTINUOUS_DELIVERY/VERSION/continuous-delivery/pom.xml, line 13, column 11

[WARNING]

[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.

[WARNING]

[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.

[Steve Smith]

You're using Maven 3, I'm guessing?

Maven 2 doesn't produce that warning in my experience, Maven 3 does.

I prefer to think of that warning as "please give me back
responsibility for versioning", and I ignore it.

If future versions of Maven do not support dynamic versioning, I
wouldn't upgrade Maven to be honest.

On Jan 10, 3:59 pm, podenski <pat.poden...@gmail.com> wrote:
> In following the Maven versioning approach recommended by James Betteley <https://jamesbetteley.wordpress.com/2011/07/07/what-is-in-a-name-usua...>

[podenski]

Yes, I am using Maven 3.0.2

I agree that Maven should not prevent use of version expressions. The user is smart enough to ensure that the expression is correctly interpolated at all times and it's quite useful for enabling Maven for Continuous Delivery.

I have also posted on this subject over in the Maven user forum:

http://maven.40175.n5.nabble.com/Warning-when-using-expression-for-version-in-pom-xml-tp5134463p5134463.html

[Steve Smith]

It's the easiest way of enabling Continuous Delivery with Maven, I've
found. That and eliminating snapshots.

> http://maven.40175.n5.nabble.com/Warning-when-using-expression-for-ve...

[Banos]

There are other ways even without explicit versioning at build time,
but this does depend on your requirements. I've left the maven builds
producing snapshots as we are grabbing release candidates from the
snapshots at any given time. So the SNAPSHOTS remain just that,
release candidates are taken for integration testing and versioned as
a set of components as required.

Of course you need to be able to track back to component versions from
the release "labels" so you have to factor that into your processes.

But this is just a note to suggest you can leave Maven in the snapshot
world and still have solid release candidate labelled components.

Cheers,
Banos.

[Mike McGarr]

I would take a look at Axel Fontaines 3 part blog post on how to stop using the Maven Release plugin when building Maven projects:  http://www.axelfontaine.com/2011/01/maven-releases-on-steroids-adios.html

I personally had an issue with this approach on multi-module Maven projects and never solved the problem.  Here's my post on the issue: http://www.axelfontaine.com/2011/01/maven-releases-on-steroids-adios.html?showComment=1299692927843#c3064606838488457999 

I am now off to Gradle land, where my build script is code...and this is all so much easier.  I highly recommend Gradle.

[reardonm]

This approach does work well on my multi-module Maven project, and I’d
really like to use it. However, one problem I’ve encountered seems
tough to handle. Perhaps, it's what you ran into. If I want to run an
out-of-band plugin on a child module, I have to run it from the root
module. For example, the version variables will not be evaluated if I
did…
cd child-module; mvn dependency:list

However the version variables do evaluate correctly from the root
module, if you did…
mvn dependency:list -pl :child-module

This is fine for some, but will make adoption challenging for my
peers. Any suggested work-around would be welcome.

I'm growing weary of banging my head on Maven, and I'm also really
looking at Gradle.

Regards,
Mike

On Jan 14, 9:32 am, Mike McGarr <jmcg...@gmail.com> wrote:
> I would take a look at Axel Fontaines 3 part blog post on how to stop using

> the Maven Release plugin when building Maven projects:  http://www.axelfontaine.com/2011/01/maven-releases-on-steroids-adios....

>
> I personally had an issue with this approach on multi-module Maven projects

> and never solved the problem.  Here's my post on the issue:http://www.axelfontaine.com/2011/01/maven-releases-on-steroids-adios....

[podenski]

After more investigation with respect to the problem with multimodule projects I found that Maven (3.0.2) + Nexus were unable to resolve transitive module dependencies. That is, within the multimodule project, if one module has a dependency on another, the direct dependency is correctly resolved but any transitive dependencies aren't. In my current investigation I have a multimodule project with a parent and 7 child modules.

By adding any transitive dependent artifacts into the respective module with the dependency, I was able to get all of the dependency resolution to work correctly with Maven 3.0.2 and Nexus 1.9.2.2.

Although this isn't ideal, the number of dependencies for my case are small and manageable. With a larger number of modules this could quickly get out of hand. A better solution would be for Maven to put the interpolated value of the version expression (   ${main.version}-${build.number}   ) into the pom.xml that gets deployed to Nexus. Perhaps this could be done by modifying the maven-deploy-plugin?

[Steve Smith]

Axel Fontaine's approach is an elegant solution - no external
dependencies and manages the POM fiddling at the end quite nicely.

I'd like a cheap way of sharing this approach between projects without
resorting to a) copy and paste b) profiles, or c) inheriting a Super
POM - inheritance is not a good thing.

[Steve Smith]

James Betteley has blogged about how to establish a 100% Maven CD
pipeline, whether you use Maven or not it's an interesting read.

http://jamesbetteley.wordpress.com/2012/02/21/continuous-delivery-using-maven/