My bad, the properties allowed are:
${revision}
${changelist}
${sha1}
See https://maven.apache.org/docs/3.2.1/release-notes.html
Then look at https://maven.apache.org/docs/3.3.1/release-notes.html for the
core extension loading mechanism
On Tuesday 8 March 2016, Gary Gregory <[email protected]
<javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote:
> On Tue, Mar 8, 2016 at 11:28 AM, Stephen Connolly <
> [email protected]> wrote:
>
> > In the .mvn folder put an extension that contributes the ${rev} property
> > based on whatever you seem safe
> >
>
> Where does this mystical .mvn folder reside, oh knowing one?
>
> Is ${rev} a built in name?
>
> Gary
>
>
> >
> > Then just have the project version include the ${rev} at the appropriate
> > place
> >
> > On Tuesday 8 March 2016, Gary Gregory <[email protected]> wrote:
> >
> > > On Mon, Mar 7, 2016 at 6:53 PM, Eric B <[email protected]
> > <javascript:;>>
> > > wrote:
> > >
> > > > The first question I have to ask is what you are trying to accomplish
> > > with
> > > > your continuous-delivery?
> > >
> > >
> > > We have a Maven multi-module build which has thousands of unit tests.
> We
> > > use Bamboo for CI and if we get a green build that means that all the
> > tests
> > > pass of course and that we successfully deployed the build to our repo
> > (we
> > > use Artifactory). We use the Maven's deploy to deploy, not the release
> > > plugin.
> > >
> > > At this point anyone can use the built product out of Bamboo's saved
> > > artifacts or Artifactory: our internal/external consultants, sales
> > > engineers, formal QA, other downstream, products, and so on. It's up to
> > the
> > > PO to decide when to slap a new major or minor version label and he/she
> > can
> > > do at anytime.
> > >
> > > From development's POV, a green build is a released product, with a
> > version
> > > for example 3.1.201601070101 (3.1.YYYYMMDDHHMM). We used to have the
> SVN
> > > version number as the maintenance version part but we are switching to
> > Git
> > > soon, hence the move to timestamps.
> > >
> > > Our parent POM contains what is considered a Maven "hack":
> > >
> > > <properties>
> > >
> > >
> <maven.build.timestamp.format>yyyyMMddHHmm</maven.build.timestamp.format>
> > > <version.major>3</version.major>
> > > <version.minor>1</version.minor>
> > > <version.main>${version.major}.${version.minor}</version.main>
> > > <revision>${maven.build.timestamp}</revision>
> > > <dv.version>${version.main}.${revision}</dv.version>
> > >
> > > Each module then has:
> > >
> > > <version>${dv.version}</version>
> > >
> > > What is the Maven way to achieve this goal?
> > >
> > > Gary
> > >
> > >
> > >
> > > > 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 <[email protected]
> > > <javascript:;>>
> > > > 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 <[email protected]
> > > <javascript:;>> 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 <
> > > > > > [email protected] <javascript:;>> 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 <[email protected]
> >
> > > > > 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: [email protected] <javascript:;> |
> [email protected]
> > > <javascript:;>
> > > > > 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
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > E-Mail: [email protected] <javascript:;> | [email protected]
> > > <javascript:;>
> > > 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
> > >
> >
> >
> > --
> > Sent from my phone
> >
>
>
>
> --
> E-Mail: [email protected] | [email protected]
> 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
>
--
Sent from my phone
