My solution was to extend the DefaultModelReader where the version is
overridden when a specific system property is set.
There are different possibilities how the version is generated, based on
${project.version} or given from external.
This means, the version in the pom.xml is still a SNAPSHOT version and
developers/eclipse are not affected at all.
To build a non-snapshot release maven is invoked like so: *mvn clean
install -Dversion.override*
This would generate a version like 0.0.1-S-15 where 0.0.1-S is the short
form of 0.0.1-SNAPSHOT and 15 is the ${env.BUILD_NUMBER} which is set by
Jenkins.
Code is here:
https://github.com/rotscher/emerging/blob/master/maven-core-extensions/src/main/java/ch/rotscher/mavenext/VersionOverrideModelReader.java
So far, the only known issue is to take care of the pom which gets
installed/deployed to the local/remote repository (but a solution is
available as well)
Cheers,
Roger
2014-04-17 19:24 GMT+02:00 Benson Margulies <[email protected]>:
> I'd like to arrange a system in which the automated builds stamp out
> releases (in the Maven sense), but that developers can use the usual
> IDE and command-line builds when just building on their particular
> machine at some particular instant. So I'd like to spare developers
> from 'passing in the version always.' The device discussed in your
> last paragraph could undoubtedly use some environmental hint to tell
> that it's just a dev's machine and either fill in a very unique
> qualifier or just use a snapshot.
>
>
> On Tue, Apr 15, 2014 at 12:09 PM, Jason van Zyl <[email protected]> wrote:
> > For the continuous delivery friendly versions I saw an issue in JIRA as
> well that tried to use snapshots.
> >
> > The version is always a release version, not a snapshot. Snapshots are
> definitively not CD friendly. In the system I'm working on that currently
> uses this feature it is always a Perforce changelist which is the version.
> All artifacts get deployed with this version. This is getting close, but we
> don't use snapshots or the release plugin which is the way I believe things
> will evolve in the Maven ecosystem. This is the generations stuff I've
> mentioned and while it is working in production right now, it's not
> complete but I'll likely have all the edge cases worked out in a few months.
> >
> > So the theory is with this mechanism that the release version is passed
> in externally always. I have another method I'm working on which is to have
> something like x.y.z.qualifier where the magic happens in the
> maven-aether-provider to do the necessary transformation based on the
> system you're running in: Git, P4, whatever.
> >
> > What are you trying to do? I can explain more if I know what you're
> playing with.
> >
> > On Apr 15, 2014, at 10:19 AM, Benson Margulies <[email protected]>
> wrote:
> >
> >> I've been thinking about how to exploit the 3.2.1 feature of
> >>
> >> <version>${something}</version>
> >>
> >> My idea is that an ordinary developer would end up with 'something'
> >> defined to be a good, old, -SNAPSHOT, while various automated builds
> >> would define it based on git commits.
> >>
> >> Is is intended that a POM could declare
> >>
> >> <something>44-SNAPSHOT</something>
> >>
> >> and then have the command-line override with -Dsomething=SOMETHING-else?
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [email protected]
> >> For additional commands, e-mail: [email protected]
> >>
> >
> > Thanks,
> >
> > Jason
> >
> > ----------------------------------------------------------
> > Jason van Zyl
> > Founder, Apache Maven
> > http://twitter.com/jvanzyl
> > http://twitter.com/takari_io
> > ---------------------------------------------------------
> >
> > A party which is not afraid of letting culture,
> > business, and welfare go to ruin completely can
> > be omnipotent for a while.
> >
> > -- Jakob Burckhardt
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
