maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric B <ebenza...@gmail.com>
Subject Re: variable doesn't work for version
Date Tue, 08 Mar 2016 02:53:12 GMT
The first question I have to ask is what you are trying to accomplish with
your continuous-delivery?  Are you trying to put snapshot versions into a
production/release state?

The biggest issue I have noticed with teams is the misunderstanding of how
SNAPSHOTs work, or their purpose in the development process.  Either teams
want to release applications in SNAPSHOT mode, or release code that is
essentially in SNAPSHOT (ie: development) mode, but with fixed version
numbers.  But instead of changing version numbers, they use something like
a timestamp to increment version numbers automatically.  But at the end of
it all, it kind of contravenes maven's versioning concept.

Normally, if your artifact is a work in progress, you should just be using
a SNAPSHOT.  If you are looking to make a real release, then you should be
promoting your code from a SNAPSHOT to a fixed version.  Generally, the
concept of continuous-delivery should only apply when in a SNAPSHOT mode,
since anything else isn't changing (ie: a fixed release doesn't need to be
re-delivered).

So then that begs the question why you need to constantly change your
version numbers during your development phase?

And if the goal is truly to have fixed versions for some other team to have
access to a "stable" version of your artifact (ie: they can be guaranteed
that it isn't going to change as you continue to develop), you could always
use something like the maven-release-plugin to promote from SNAPSHOT to a
fixed version, and then re-open the next version as a SNAPSHOT.  (Although
I know there are many dissenters against the release-plugin).

Thanks,

Eric



On Mon, Mar 7, 2016 at 7:15 PM, Gary Gregory <garydgregory@gmail.com> wrote:

> Is there a Maven-way to do continuous delivery then? As opposed
> to continuous integration.
>
> Our current hack is to use the date as the maintenance version as a
> variable for example 3.1.20160102
>
> G
>
> On Mon, Mar 7, 2016 at 11:18 AM, Eric B <ebenzacar@gmail.com> wrote:
>
> > I personally have a pet-peeve of using system variables to define version
> > numbers; I find it is counter productive to the building of maven
> > artifacts.  There is no traceability to determine  the actual version of
> an
> > artifact once it has been built.  At least having a fixed version number
> in
> > the <version> element shows up in the META-INF/maven/../pom.* files.
> >
> > Is using a variable for the version even a good idea?
> >
> > Thanks,
> >
> > Eric
> >
> >
> > On Mon, Mar 7, 2016 at 4:04 AM, Stephen Connolly <
> > stephen.alan.connolly@gmail.com> wrote:
> >
> > > only specific properties are permitted for expansion in XPath paths
> that
> > > match the following regex
> /project/(parent/)?(groupId|artifactId|version)
> > >
> > > On 2 March 2016 at 05:39, Raghu <raghunath_ku@yahoo.com.invalid>
> wrote:
> > >
> > > > I have a POM with parent node as below: <parent>
> > > > <groupId>com.test</groupId> <artifactId>pom.parent</artifactId>
> > > > <version>${test.version}</version>
> > > > <relativePath>../scripts/pom.xml</relativePath> </parent>
> > > > This used to work till maven 3.3.3 version - mvn clean install.
> > However,
> > > > the version 3.3.9 throws error though. When I change the version to a
> > > value
> > > > instead of the variable, it works fine.
> > > > Won't maven support variable for version? Or is it a bug with 3.3.9?
> > > > Appreciate your response...
> > > > - regards,raghu
> > >
> >
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

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