variable doesn't work for version

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

variable doesn't work for version

Raghu
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
Reply | Threaded
Open this post in threaded view
|

Re: variable doesn't work for version

stephenconnolly
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: variable doesn't work for version

Eric B
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 <
[hidden email]> 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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: variable doesn't work for version

Gary Gregory-2
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 <[hidden email]> 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 <
> [hidden email]> 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 <[hidden email]> 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: [hidden email] | [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: variable doesn't work for version

Eric B
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 <[hidden email]> 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 <[hidden email]> 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 <
> > [hidden email]> 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 <[hidden email]>
> 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: [hidden email] | [hidden email]
> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: variable doesn't work for version

Gary Gregory-2
On Mon, Mar 7, 2016 at 6:53 PM, Eric B <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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 <
> > > [hidden email]> 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 <[hidden email]>
> > 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: [hidden email] | [hidden email]
> > 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: [hidden email] | [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: variable doesn't work for version

stephenconnolly
In the .mvn folder put an extension that contributes the ${rev} property
based on whatever you seem safe

Then just have the project version include the ${rev} at the appropriate
place

On Tuesday 8 March 2016, Gary Gregory <[hidden email]> wrote:

> On Mon, Mar 7, 2016 at 6:53 PM, Eric B <[hidden email] <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 <[hidden email]
> <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 <[hidden email]
> <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 <
> > > > [hidden email] <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 <[hidden email]>
> > > 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: [hidden email] <javascript:;> | [hidden email]
> <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: [hidden email] <javascript:;> | [hidden email]
> <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
Reply | Threaded
Open this post in threaded view
|

Re: variable doesn't work for version

Gary Gregory-2
On Tue, Mar 8, 2016 at 11:28 AM, Stephen Connolly <
[hidden email]> 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 <[hidden email]> wrote:
>
> > On Mon, Mar 7, 2016 at 6:53 PM, Eric B <[hidden email]
> <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 <[hidden email]
> > <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 <[hidden email]
> > <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 <
> > > > > [hidden email] <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 <[hidden email]>
> > > > 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: [hidden email] <javascript:;> | [hidden email]
> > <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: [hidden email] <javascript:;> | [hidden email]
> > <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: [hidden email] | [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

variable doesn't work for version

stephenconnolly
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 <[hidden email]
<javascript:_e(%7B%7D,'cvml','[hidden email]');>> wrote:

> On Tue, Mar 8, 2016 at 11:28 AM, Stephen Connolly <
> [hidden email]> 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 <[hidden email]> wrote:
> >
> > > On Mon, Mar 7, 2016 at 6:53 PM, Eric B <[hidden email]
> > <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 <[hidden email]
> > > <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 <[hidden email]
> > > <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 <
> > > > > > [hidden email] <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 <[hidden email]
> >
> > > > > 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: [hidden email] <javascript:;> |
> [hidden email]
> > > <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: [hidden email] <javascript:;> | [hidden email]
> > > <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: [hidden email] | [hidden email]
> 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
Reply | Threaded
Open this post in threaded view
|

Re: variable doesn't work for version

Benson Margulies
In reply to this post by stephenconnolly
On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
<[hidden email]> wrote:
> In the .mvn folder put an extension that contributes the ${rev} property
> based on whatever you seem safe

Stephen, can you please offer some details? Just what sort of
extension? An event spy that sees session start? Something else? Does
this require 3.3.x  or does it work with 3.2.5?

>
> Then just have the project version include the ${rev} at the appropriate
> place
>
> On Tuesday 8 March 2016, Gary Gregory <[hidden email]> wrote:
>
>> On Mon, Mar 7, 2016 at 6:53 PM, Eric B <[hidden email] <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 <[hidden email]
>> <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 <[hidden email]
>> <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 <
>> > > > [hidden email] <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 <[hidden email]>
>> > > 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: [hidden email] <javascript:;> | [hidden email]
>> <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: [hidden email] <javascript:;> | [hidden email]
>> <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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: variable doesn't work for version

stephenconnolly
I have no clue... that is a different question we should ask of the person
who implemented this functionality

On 9 March 2016 at 13:40, Benson Margulies <[hidden email]> wrote:

> On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
> <[hidden email]> wrote:
> > In the .mvn folder put an extension that contributes the ${rev} property
> > based on whatever you seem safe
>
> Stephen, can you please offer some details? Just what sort of
> extension? An event spy that sees session start? Something else? Does
> this require 3.3.x  or does it work with 3.2.5?
>
> >
> > Then just have the project version include the ${rev} at the appropriate
> > place
> >
> > On Tuesday 8 March 2016, Gary Gregory <[hidden email]> wrote:
> >
> >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B <[hidden email]
> <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 <[hidden email]
> >> <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 <[hidden email]
> >> <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 <
> >> > > > [hidden email] <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 <[hidden email]
> >
> >> > > 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: [hidden email] <javascript:;> | [hidden email]
> >> <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: [hidden email] <javascript:;> | [hidden email]
> >> <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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: variable doesn't work for version

Tamás Cservenák
I assume it should be this (instead of spy):
http://maven.apache.org/examples/maven-3-lifecycle-extensions.html

And instead of starting beer machine, it can inject the value into the
session that you got from whenever...

maven related changes merely laxed the validation to allow those three
expressions in version, but does not provide anything as "source" for those.

On Wed, Mar 9, 2016 at 2:44 PM Stephen Connolly <
[hidden email]> wrote:

> I have no clue... that is a different question we should ask of the person
> who implemented this functionality
>
> On 9 March 2016 at 13:40, Benson Margulies <[hidden email]> wrote:
>
> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
> > <[hidden email]> wrote:
> > > In the .mvn folder put an extension that contributes the ${rev}
> property
> > > based on whatever you seem safe
> >
> > Stephen, can you please offer some details? Just what sort of
> > extension? An event spy that sees session start? Something else? Does
> > this require 3.3.x  or does it work with 3.2.5?
> >
> > >
> > > Then just have the project version include the ${rev} at the
> appropriate
> > > place
> > >
> > > On Tuesday 8 March 2016, Gary Gregory <[hidden email]> wrote:
> > >
> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B <[hidden email]
> > <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 <
> [hidden email]
> > >> <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 <[hidden email]
> > >> <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 <
> > >> > > > [hidden email] <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 <[hidden email]
> .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: [hidden email] <javascript:;> |
> [hidden email]
> > >> <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: [hidden email] <javascript:;> | [hidden email]
> > >> <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
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: variable doesn't work for version

Benson Margulies
On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák <[hidden email]> wrote:
> I assume it should be this (instead of spy):
> http://maven.apache.org/examples/maven-3-lifecycle-extensions.html
>
> And instead of starting beer machine, it can inject the value into the
> session that you got from whenever...

I don't think this can work as a thing configured in the POM. Unless
these items can be dropped into the ext directory instead of
configured in the the pom as an extension. Is that the case in general
that the ext dir is the same thing as declaring in the POM as an
extension?


>
> maven related changes merely laxed the validation to allow those three
> expressions in version, but does not provide anything as "source" for those.
>
> On Wed, Mar 9, 2016 at 2:44 PM Stephen Connolly <
> [hidden email]> wrote:
>
>> I have no clue... that is a different question we should ask of the person
>> who implemented this functionality
>>
>> On 9 March 2016 at 13:40, Benson Margulies <[hidden email]> wrote:
>>
>> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
>> > <[hidden email]> wrote:
>> > > In the .mvn folder put an extension that contributes the ${rev}
>> property
>> > > based on whatever you seem safe
>> >
>> > Stephen, can you please offer some details? Just what sort of
>> > extension? An event spy that sees session start? Something else? Does
>> > this require 3.3.x  or does it work with 3.2.5?
>> >
>> > >
>> > > Then just have the project version include the ${rev} at the
>> appropriate
>> > > place
>> > >
>> > > On Tuesday 8 March 2016, Gary Gregory <[hidden email]> wrote:
>> > >
>> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B <[hidden email]
>> > <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 <
>> [hidden email]
>> > >> <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 <[hidden email]
>> > >> <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 <
>> > >> > > > [hidden email] <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 <[hidden email]
>> .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: [hidden email] <javascript:;> |
>> [hidden email]
>> > >> <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: [hidden email] <javascript:;> | [hidden email]
>> > >> <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
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> >
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: variable doesn't work for version

stephenconnolly
On Wednesday, 9 March 2016, Benson Margulies <[hidden email]> wrote:

> On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák <[hidden email]
> <javascript:;>> wrote:
> > I assume it should be this (instead of spy):
> > http://maven.apache.org/examples/maven-3-lifecycle-extensions.html
> >
> > And instead of starting beer machine, it can inject the value into the
> > session that you got from whenever...
>
> I don't think this can work as a thing configured in the POM. Unless
> these items can be dropped into the ext directory instead of
> configured in the the pom as an extension. Is that the case in general
> that the ext dir is the same thing as declaring in the POM as an
> extension?


That's where the .mvn folder as an extension loading mechanism kicks in


>
>
> >
> > maven related changes merely laxed the validation to allow those three
> > expressions in version, but does not provide anything as "source" for
> those.
> >
> > On Wed, Mar 9, 2016 at 2:44 PM Stephen Connolly <
> > [hidden email] <javascript:;>> wrote:
> >
> >> I have no clue... that is a different question we should ask of the
> person
> >> who implemented this functionality
> >>
> >> On 9 March 2016 at 13:40, Benson Margulies <[hidden email]
> <javascript:;>> wrote:
> >>
> >> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
> >> > <[hidden email] <javascript:;>> wrote:
> >> > > In the .mvn folder put an extension that contributes the ${rev}
> >> property
> >> > > based on whatever you seem safe
> >> >
> >> > Stephen, can you please offer some details? Just what sort of
> >> > extension? An event spy that sees session start? Something else? Does
> >> > this require 3.3.x  or does it work with 3.2.5?
> >> >
> >> > >
> >> > > Then just have the project version include the ${rev} at the
> >> appropriate
> >> > > place
> >> > >
> >> > > On Tuesday 8 March 2016, Gary Gregory <[hidden email]
> <javascript:;>> wrote:
> >> > >
> >> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B <[hidden email]
> <javascript:;>
> >> > <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 <
> >> [hidden email] <javascript:;>
> >> > >> <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 <[hidden email]
> <javascript:;>
> >> > >> <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 <
> >> > >> > > > [hidden email] <javascript:;>
> <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 <[hidden email]
> <javascript:;>
> >> .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: [hidden email] <javascript:;> <javascript:;> |
> >> [hidden email] <javascript:;>
> >> > >> <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: [hidden email] <javascript:;> <javascript:;> |
> [hidden email] <javascript:;>
> >> > >> <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
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: [hidden email]
> <javascript:;>
> >> > For additional commands, e-mail: [hidden email]
> <javascript:;>
> >> >
> >> >
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email] <javascript:;>
> For additional commands, e-mail: [hidden email]
> <javascript:;>
>
>

--
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

Re: variable doesn't work for version

Benson Margulies
On Wed, Mar 9, 2016 at 3:20 PM, Stephen Connolly
<[hidden email]> wrote:

> On Wednesday, 9 March 2016, Benson Margulies <[hidden email]> wrote:
>
>> On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák <[hidden email]
>> <javascript:;>> wrote:
>> > I assume it should be this (instead of spy):
>> > http://maven.apache.org/examples/maven-3-lifecycle-extensions.html
>> >
>> > And instead of starting beer machine, it can inject the value into the
>> > session that you got from whenever...
>>
>> I don't think this can work as a thing configured in the POM. Unless
>> these items can be dropped into the ext directory instead of
>> configured in the the pom as an extension. Is that the case in general
>> that the ext dir is the same thing as declaring in the POM as an
>> extension?
>
>
> That's where the .mvn folder as an extension loading mechanism kicks in

What version did that show up in? Prior, it has to be in a dir in the
maven home, right?

>
>
>>
>>
>> >
>> > maven related changes merely laxed the validation to allow those three
>> > expressions in version, but does not provide anything as "source" for
>> those.
>> >
>> > On Wed, Mar 9, 2016 at 2:44 PM Stephen Connolly <
>> > [hidden email] <javascript:;>> wrote:
>> >
>> >> I have no clue... that is a different question we should ask of the
>> person
>> >> who implemented this functionality
>> >>
>> >> On 9 March 2016 at 13:40, Benson Margulies <[hidden email]
>> <javascript:;>> wrote:
>> >>
>> >> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
>> >> > <[hidden email] <javascript:;>> wrote:
>> >> > > In the .mvn folder put an extension that contributes the ${rev}
>> >> property
>> >> > > based on whatever you seem safe
>> >> >
>> >> > Stephen, can you please offer some details? Just what sort of
>> >> > extension? An event spy that sees session start? Something else? Does
>> >> > this require 3.3.x  or does it work with 3.2.5?
>> >> >
>> >> > >
>> >> > > Then just have the project version include the ${rev} at the
>> >> appropriate
>> >> > > place
>> >> > >
>> >> > > On Tuesday 8 March 2016, Gary Gregory <[hidden email]
>> <javascript:;>> wrote:
>> >> > >
>> >> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B <[hidden email]
>> <javascript:;>
>> >> > <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 <
>> >> [hidden email] <javascript:;>
>> >> > >> <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 <[hidden email]
>> <javascript:;>
>> >> > >> <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 <
>> >> > >> > > > [hidden email] <javascript:;>
>> <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 <[hidden email]
>> <javascript:;>
>> >> .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: [hidden email] <javascript:;> <javascript:;> |
>> >> [hidden email] <javascript:;>
>> >> > >> <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: [hidden email] <javascript:;> <javascript:;> |
>> [hidden email] <javascript:;>
>> >> > >> <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
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: [hidden email]
>> <javascript:;>
>> >> > For additional commands, e-mail: [hidden email]
>> <javascript:;>
>> >> >
>> >> >
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email] <javascript:;>
>> For additional commands, e-mail: [hidden email]
>> <javascript:;>
>>
>>
>
> --
> Sent from my phone

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: variable doesn't work for version

Benson Margulies
I tried this and it didn't work, even a little.

See https://github.com/benson-basis/auto-version-maven-extension.

My extension is never called, whether I put it into .mvn or the maven
home lib/ext directory. (Proved by running mvnDebug, setting a
breakpoint, and attaching a debugger).



On Wed, Mar 9, 2016 at 3:24 PM, Benson Margulies <[hidden email]> wrote:

> On Wed, Mar 9, 2016 at 3:20 PM, Stephen Connolly
> <[hidden email]> wrote:
>> On Wednesday, 9 March 2016, Benson Margulies <[hidden email]> wrote:
>>
>>> On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák <[hidden email]
>>> <javascript:;>> wrote:
>>> > I assume it should be this (instead of spy):
>>> > http://maven.apache.org/examples/maven-3-lifecycle-extensions.html
>>> >
>>> > And instead of starting beer machine, it can inject the value into the
>>> > session that you got from whenever...
>>>
>>> I don't think this can work as a thing configured in the POM. Unless
>>> these items can be dropped into the ext directory instead of
>>> configured in the the pom as an extension. Is that the case in general
>>> that the ext dir is the same thing as declaring in the POM as an
>>> extension?
>>
>>
>> That's where the .mvn folder as an extension loading mechanism kicks in
>
> What version did that show up in? Prior, it has to be in a dir in the
> maven home, right?
>
>>
>>
>>>
>>>
>>> >
>>> > maven related changes merely laxed the validation to allow those three
>>> > expressions in version, but does not provide anything as "source" for
>>> those.
>>> >
>>> > On Wed, Mar 9, 2016 at 2:44 PM Stephen Connolly <
>>> > [hidden email] <javascript:;>> wrote:
>>> >
>>> >> I have no clue... that is a different question we should ask of the
>>> person
>>> >> who implemented this functionality
>>> >>
>>> >> On 9 March 2016 at 13:40, Benson Margulies <[hidden email]
>>> <javascript:;>> wrote:
>>> >>
>>> >> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
>>> >> > <[hidden email] <javascript:;>> wrote:
>>> >> > > In the .mvn folder put an extension that contributes the ${rev}
>>> >> property
>>> >> > > based on whatever you seem safe
>>> >> >
>>> >> > Stephen, can you please offer some details? Just what sort of
>>> >> > extension? An event spy that sees session start? Something else? Does
>>> >> > this require 3.3.x  or does it work with 3.2.5?
>>> >> >
>>> >> > >
>>> >> > > Then just have the project version include the ${rev} at the
>>> >> appropriate
>>> >> > > place
>>> >> > >
>>> >> > > On Tuesday 8 March 2016, Gary Gregory <[hidden email]
>>> <javascript:;>> wrote:
>>> >> > >
>>> >> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B <[hidden email]
>>> <javascript:;>
>>> >> > <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 <
>>> >> [hidden email] <javascript:;>
>>> >> > >> <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 <[hidden email]
>>> <javascript:;>
>>> >> > >> <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 <
>>> >> > >> > > > [hidden email] <javascript:;>
>>> <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 <[hidden email]
>>> <javascript:;>
>>> >> .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: [hidden email] <javascript:;> <javascript:;> |
>>> >> [hidden email] <javascript:;>
>>> >> > >> <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: [hidden email] <javascript:;> <javascript:;> |
>>> [hidden email] <javascript:;>
>>> >> > >> <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
>>> >> >
>>> >> > ---------------------------------------------------------------------
>>> >> > To unsubscribe, e-mail: [hidden email]
>>> <javascript:;>
>>> >> > For additional commands, e-mail: [hidden email]
>>> <javascript:;>
>>> >> >
>>> >> >
>>> >>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email] <javascript:;>
>>> For additional commands, e-mail: [hidden email]
>>> <javascript:;>
>>>
>>>
>>
>> --
>> Sent from my phone

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: variable doesn't work for version

Benson Margulies
Of course, as soon as I hit Send I found out what I screwed up.

On Wed, Mar 9, 2016 at 5:12 PM, Benson Margulies <[hidden email]> wrote:

> I tried this and it didn't work, even a little.
>
> See https://github.com/benson-basis/auto-version-maven-extension.
>
> My extension is never called, whether I put it into .mvn or the maven
> home lib/ext directory. (Proved by running mvnDebug, setting a
> breakpoint, and attaching a debugger).
>
>
>
> On Wed, Mar 9, 2016 at 3:24 PM, Benson Margulies <[hidden email]> wrote:
>> On Wed, Mar 9, 2016 at 3:20 PM, Stephen Connolly
>> <[hidden email]> wrote:
>>> On Wednesday, 9 March 2016, Benson Margulies <[hidden email]> wrote:
>>>
>>>> On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák <[hidden email]
>>>> <javascript:;>> wrote:
>>>> > I assume it should be this (instead of spy):
>>>> > http://maven.apache.org/examples/maven-3-lifecycle-extensions.html
>>>> >
>>>> > And instead of starting beer machine, it can inject the value into the
>>>> > session that you got from whenever...
>>>>
>>>> I don't think this can work as a thing configured in the POM. Unless
>>>> these items can be dropped into the ext directory instead of
>>>> configured in the the pom as an extension. Is that the case in general
>>>> that the ext dir is the same thing as declaring in the POM as an
>>>> extension?
>>>
>>>
>>> That's where the .mvn folder as an extension loading mechanism kicks in
>>
>> What version did that show up in? Prior, it has to be in a dir in the
>> maven home, right?
>>
>>>
>>>
>>>>
>>>>
>>>> >
>>>> > maven related changes merely laxed the validation to allow those three
>>>> > expressions in version, but does not provide anything as "source" for
>>>> those.
>>>> >
>>>> > On Wed, Mar 9, 2016 at 2:44 PM Stephen Connolly <
>>>> > [hidden email] <javascript:;>> wrote:
>>>> >
>>>> >> I have no clue... that is a different question we should ask of the
>>>> person
>>>> >> who implemented this functionality
>>>> >>
>>>> >> On 9 March 2016 at 13:40, Benson Margulies <[hidden email]
>>>> <javascript:;>> wrote:
>>>> >>
>>>> >> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
>>>> >> > <[hidden email] <javascript:;>> wrote:
>>>> >> > > In the .mvn folder put an extension that contributes the ${rev}
>>>> >> property
>>>> >> > > based on whatever you seem safe
>>>> >> >
>>>> >> > Stephen, can you please offer some details? Just what sort of
>>>> >> > extension? An event spy that sees session start? Something else? Does
>>>> >> > this require 3.3.x  or does it work with 3.2.5?
>>>> >> >
>>>> >> > >
>>>> >> > > Then just have the project version include the ${rev} at the
>>>> >> appropriate
>>>> >> > > place
>>>> >> > >
>>>> >> > > On Tuesday 8 March 2016, Gary Gregory <[hidden email]
>>>> <javascript:;>> wrote:
>>>> >> > >
>>>> >> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B <[hidden email]
>>>> <javascript:;>
>>>> >> > <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 <
>>>> >> [hidden email] <javascript:;>
>>>> >> > >> <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 <[hidden email]
>>>> <javascript:;>
>>>> >> > >> <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 <
>>>> >> > >> > > > [hidden email] <javascript:;>
>>>> <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 <[hidden email]
>>>> <javascript:;>
>>>> >> .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: [hidden email] <javascript:;> <javascript:;> |
>>>> >> [hidden email] <javascript:;>
>>>> >> > >> <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: [hidden email] <javascript:;> <javascript:;> |
>>>> [hidden email] <javascript:;>
>>>> >> > >> <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
>>>> >> >
>>>> >> > ---------------------------------------------------------------------
>>>> >> > To unsubscribe, e-mail: [hidden email]
>>>> <javascript:;>
>>>> >> > For additional commands, e-mail: [hidden email]
>>>> <javascript:;>
>>>> >> >
>>>> >> >
>>>> >>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email] <javascript:;>
>>>> For additional commands, e-mail: [hidden email]
>>>> <javascript:;>
>>>>
>>>>
>>>
>>> --
>>> Sent from my phone

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: variable doesn't work for version

Benson Margulies
Almost really working. The only gripe is that it is still warning me
that I have an expression in <version/>, even when I use 'rev' as
cited. Is that poor choice?

[INFO] rev 0.0.1.20160309172035
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective
model for com.basistech:auto-version-maven-extension-test:jar:0.0.1.20160309172035
[WARNING] 'version' contains an expression but should be a constant. @
com.basistech:auto-version-maven-extension-test:${rev},
/Users/benson/x/auto-version-maven-extension/src/it/basic/pom.xml,
line 7, column 14
[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.
[WARNING]



On Wed, Mar 9, 2016 at 5:14 PM, Benson Margulies <[hidden email]> wrote:

> Of course, as soon as I hit Send I found out what I screwed up.
>
> On Wed, Mar 9, 2016 at 5:12 PM, Benson Margulies <[hidden email]> wrote:
>> I tried this and it didn't work, even a little.
>>
>> See https://github.com/benson-basis/auto-version-maven-extension.
>>
>> My extension is never called, whether I put it into .mvn or the maven
>> home lib/ext directory. (Proved by running mvnDebug, setting a
>> breakpoint, and attaching a debugger).
>>
>>
>>
>> On Wed, Mar 9, 2016 at 3:24 PM, Benson Margulies <[hidden email]> wrote:
>>> On Wed, Mar 9, 2016 at 3:20 PM, Stephen Connolly
>>> <[hidden email]> wrote:
>>>> On Wednesday, 9 March 2016, Benson Margulies <[hidden email]> wrote:
>>>>
>>>>> On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák <[hidden email]
>>>>> <javascript:;>> wrote:
>>>>> > I assume it should be this (instead of spy):
>>>>> > http://maven.apache.org/examples/maven-3-lifecycle-extensions.html
>>>>> >
>>>>> > And instead of starting beer machine, it can inject the value into the
>>>>> > session that you got from whenever...
>>>>>
>>>>> I don't think this can work as a thing configured in the POM. Unless
>>>>> these items can be dropped into the ext directory instead of
>>>>> configured in the the pom as an extension. Is that the case in general
>>>>> that the ext dir is the same thing as declaring in the POM as an
>>>>> extension?
>>>>
>>>>
>>>> That's where the .mvn folder as an extension loading mechanism kicks in
>>>
>>> What version did that show up in? Prior, it has to be in a dir in the
>>> maven home, right?
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> >
>>>>> > maven related changes merely laxed the validation to allow those three
>>>>> > expressions in version, but does not provide anything as "source" for
>>>>> those.
>>>>> >
>>>>> > On Wed, Mar 9, 2016 at 2:44 PM Stephen Connolly <
>>>>> > [hidden email] <javascript:;>> wrote:
>>>>> >
>>>>> >> I have no clue... that is a different question we should ask of the
>>>>> person
>>>>> >> who implemented this functionality
>>>>> >>
>>>>> >> On 9 March 2016 at 13:40, Benson Margulies <[hidden email]
>>>>> <javascript:;>> wrote:
>>>>> >>
>>>>> >> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
>>>>> >> > <[hidden email] <javascript:;>> wrote:
>>>>> >> > > In the .mvn folder put an extension that contributes the ${rev}
>>>>> >> property
>>>>> >> > > based on whatever you seem safe
>>>>> >> >
>>>>> >> > Stephen, can you please offer some details? Just what sort of
>>>>> >> > extension? An event spy that sees session start? Something else? Does
>>>>> >> > this require 3.3.x  or does it work with 3.2.5?
>>>>> >> >
>>>>> >> > >
>>>>> >> > > Then just have the project version include the ${rev} at the
>>>>> >> appropriate
>>>>> >> > > place
>>>>> >> > >
>>>>> >> > > On Tuesday 8 March 2016, Gary Gregory <[hidden email]
>>>>> <javascript:;>> wrote:
>>>>> >> > >
>>>>> >> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B <[hidden email]
>>>>> <javascript:;>
>>>>> >> > <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 <
>>>>> >> [hidden email] <javascript:;>
>>>>> >> > >> <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 <[hidden email]
>>>>> <javascript:;>
>>>>> >> > >> <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 <
>>>>> >> > >> > > > [hidden email] <javascript:;>
>>>>> <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 <[hidden email]
>>>>> <javascript:;>
>>>>> >> .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: [hidden email] <javascript:;> <javascript:;> |
>>>>> >> [hidden email] <javascript:;>
>>>>> >> > >> <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: [hidden email] <javascript:;> <javascript:;> |
>>>>> [hidden email] <javascript:;>
>>>>> >> > >> <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
>>>>> >> >
>>>>> >> > ---------------------------------------------------------------------
>>>>> >> > To unsubscribe, e-mail: [hidden email]
>>>>> <javascript:;>
>>>>> >> > For additional commands, e-mail: [hidden email]
>>>>> <javascript:;>
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email] <javascript:;>
>>>>> For additional commands, e-mail: [hidden email]
>>>>> <javascript:;>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Sent from my phone

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: variable doesn't work for version

stephenconnolly
It's ${revision} or ${changelist} or a third one I cannot recall, ${rev} is
on the "moan and wail" list

On Wednesday 9 March 2016, Benson Margulies <[hidden email]> wrote:

> Almost really working. The only gripe is that it is still warning me
> that I have an expression in <version/>, even when I use 'rev' as
> cited. Is that poor choice?
>
> [INFO] rev 0.0.1.20160309172035
> [INFO] Scanning for projects...
> [WARNING]
> [WARNING] Some problems were encountered while building the effective
> model for
> com.basistech:auto-version-maven-extension-test:jar:0.0.1.20160309172035
> [WARNING] 'version' contains an expression but should be a constant. @
> com.basistech:auto-version-maven-extension-test:${rev},
> /Users/benson/x/auto-version-maven-extension/src/it/basic/pom.xml,
> line 7, column 14
> [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.
> [WARNING]
>
>
>
> On Wed, Mar 9, 2016 at 5:14 PM, Benson Margulies <[hidden email]
> <javascript:;>> wrote:
> > Of course, as soon as I hit Send I found out what I screwed up.
> >
> > On Wed, Mar 9, 2016 at 5:12 PM, Benson Margulies <[hidden email]
> <javascript:;>> wrote:
> >> I tried this and it didn't work, even a little.
> >>
> >> See https://github.com/benson-basis/auto-version-maven-extension.
> >>
> >> My extension is never called, whether I put it into .mvn or the maven
> >> home lib/ext directory. (Proved by running mvnDebug, setting a
> >> breakpoint, and attaching a debugger).
> >>
> >>
> >>
> >> On Wed, Mar 9, 2016 at 3:24 PM, Benson Margulies <[hidden email]
> <javascript:;>> wrote:
> >>> On Wed, Mar 9, 2016 at 3:20 PM, Stephen Connolly
> >>> <[hidden email] <javascript:;>> wrote:
> >>>> On Wednesday, 9 March 2016, Benson Margulies <[hidden email]
> <javascript:;>> wrote:
> >>>>
> >>>>> On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák <[hidden email]
> <javascript:;>
> >>>>> <javascript:;>> wrote:
> >>>>> > I assume it should be this (instead of spy):
> >>>>> > http://maven.apache.org/examples/maven-3-lifecycle-extensions.html
> >>>>> >
> >>>>> > And instead of starting beer machine, it can inject the value into
> the
> >>>>> > session that you got from whenever...
> >>>>>
> >>>>> I don't think this can work as a thing configured in the POM. Unless
> >>>>> these items can be dropped into the ext directory instead of
> >>>>> configured in the the pom as an extension. Is that the case in
> general
> >>>>> that the ext dir is the same thing as declaring in the POM as an
> >>>>> extension?
> >>>>
> >>>>
> >>>> That's where the .mvn folder as an extension loading mechanism kicks
> in
> >>>
> >>> What version did that show up in? Prior, it has to be in a dir in the
> >>> maven home, right?
> >>>
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>> >
> >>>>> > maven related changes merely laxed the validation to allow those
> three
> >>>>> > expressions in version, but does not provide anything as "source"
> for
> >>>>> those.
> >>>>> >
> >>>>> > On Wed, Mar 9, 2016 at 2:44 PM Stephen Connolly <
> >>>>> > [hidden email] <javascript:;> <javascript:;>>
> wrote:
> >>>>> >
> >>>>> >> I have no clue... that is a different question we should ask of
> the
> >>>>> person
> >>>>> >> who implemented this functionality
> >>>>> >>
> >>>>> >> On 9 March 2016 at 13:40, Benson Margulies <[hidden email]
> <javascript:;>
> >>>>> <javascript:;>> wrote:
> >>>>> >>
> >>>>> >> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
> >>>>> >> > <[hidden email] <javascript:;>
> <javascript:;>> wrote:
> >>>>> >> > > In the .mvn folder put an extension that contributes the
> ${rev}
> >>>>> >> property
> >>>>> >> > > based on whatever you seem safe
> >>>>> >> >
> >>>>> >> > Stephen, can you please offer some details? Just what sort of
> >>>>> >> > extension? An event spy that sees session start? Something
> else? Does
> >>>>> >> > this require 3.3.x  or does it work with 3.2.5?
> >>>>> >> >
> >>>>> >> > >
> >>>>> >> > > Then just have the project version include the ${rev} at the
> >>>>> >> appropriate
> >>>>> >> > > place
> >>>>> >> > >
> >>>>> >> > > On Tuesday 8 March 2016, Gary Gregory <[hidden email]
> <javascript:;>
> >>>>> <javascript:;>> wrote:
> >>>>> >> > >
> >>>>> >> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B <[hidden email]
> <javascript:;>
> >>>>> <javascript:;>
> >>>>> >> > <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 <
> >>>>> >> [hidden email] <javascript:;> <javascript:;>
> >>>>> >> > >> <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 <
> [hidden email] <javascript:;>
> >>>>> <javascript:;>
> >>>>> >> > >> <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 <
> >>>>> >> > >> > > > [hidden email] <javascript:;>
> <javascript:;>
> >>>>> <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 <
> [hidden email] <javascript:;>
> >>>>> <javascript:;>
> >>>>> >> .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: [hidden email] <javascript:;>
> <javascript:;> <javascript:;> |
> >>>>> >> [hidden email] <javascript:;> <javascript:;>
> >>>>> >> > >> <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: [hidden email] <javascript:;>
> <javascript:;> <javascript:;> |
> >>>>> [hidden email] <javascript:;> <javascript:;>
> >>>>> >> > >> <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
> >>>>> >> >
> >>>>> >> >
> ---------------------------------------------------------------------
> >>>>> >> > To unsubscribe, e-mail: [hidden email]
> <javascript:;>
> >>>>> <javascript:;>
> >>>>> >> > For additional commands, e-mail: [hidden email]
> <javascript:;>
> >>>>> <javascript:;>
> >>>>> >> >
> >>>>> >> >
> >>>>> >>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: [hidden email]
> <javascript:;> <javascript:;>
> >>>>> For additional commands, e-mail: [hidden email]
> <javascript:;>
> >>>>> <javascript:;>
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Sent from my phone
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email] <javascript:;>
> For additional commands, e-mail: [hidden email]
> <javascript:;>
>
>

--
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

Re: variable doesn't work for version

stephenconnolly
Also I suspect this doesn't fully include logic to ensure that the
substitution resolved pom is installed/deployed, so may cause issues for
out-of-reactor consumption as a dependency, or GPG signature validation if
you try to "fix" with a hack

On Thursday 10 March 2016, Stephen Connolly <[hidden email]>
wrote:

> It's ${revision} or ${changelist} or a third one I cannot recall, ${rev}
> is on the "moan and wail" list
>
> On Wednesday 9 March 2016, Benson Margulies <[hidden email]
> <javascript:_e(%7B%7D,'cvml','[hidden email]');>> wrote:
>
>> Almost really working. The only gripe is that it is still warning me
>> that I have an expression in <version/>, even when I use 'rev' as
>> cited. Is that poor choice?
>>
>> [INFO] rev 0.0.1.20160309172035
>> [INFO] Scanning for projects...
>> [WARNING]
>> [WARNING] Some problems were encountered while building the effective
>> model for
>> com.basistech:auto-version-maven-extension-test:jar:0.0.1.20160309172035
>> [WARNING] 'version' contains an expression but should be a constant. @
>> com.basistech:auto-version-maven-extension-test:${rev},
>> /Users/benson/x/auto-version-maven-extension/src/it/basic/pom.xml,
>> line 7, column 14
>> [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.
>> [WARNING]
>>
>>
>>
>> On Wed, Mar 9, 2016 at 5:14 PM, Benson Margulies <[hidden email]>
>> wrote:
>> > Of course, as soon as I hit Send I found out what I screwed up.
>> >
>> > On Wed, Mar 9, 2016 at 5:12 PM, Benson Margulies <[hidden email]>
>> wrote:
>> >> I tried this and it didn't work, even a little.
>> >>
>> >> See https://github.com/benson-basis/auto-version-maven-extension.
>> >>
>> >> My extension is never called, whether I put it into .mvn or the maven
>> >> home lib/ext directory. (Proved by running mvnDebug, setting a
>> >> breakpoint, and attaching a debugger).
>> >>
>> >>
>> >>
>> >> On Wed, Mar 9, 2016 at 3:24 PM, Benson Margulies <
>> [hidden email]> wrote:
>> >>> On Wed, Mar 9, 2016 at 3:20 PM, Stephen Connolly
>> >>> <[hidden email]> wrote:
>> >>>> On Wednesday, 9 March 2016, Benson Margulies <[hidden email]>
>> wrote:
>> >>>>
>> >>>>> On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák <
>> [hidden email]
>> >>>>> <javascript:;>> wrote:
>> >>>>> > I assume it should be this (instead of spy):
>> >>>>> >
>> http://maven.apache.org/examples/maven-3-lifecycle-extensions.html
>> >>>>> >
>> >>>>> > And instead of starting beer machine, it can inject the value
>> into the
>> >>>>> > session that you got from whenever...
>> >>>>>
>> >>>>> I don't think this can work as a thing configured in the POM. Unless
>> >>>>> these items can be dropped into the ext directory instead of
>> >>>>> configured in the the pom as an extension. Is that the case in
>> general
>> >>>>> that the ext dir is the same thing as declaring in the POM as an
>> >>>>> extension?
>> >>>>
>> >>>>
>> >>>> That's where the .mvn folder as an extension loading mechanism kicks
>> in
>> >>>
>> >>> What version did that show up in? Prior, it has to be in a dir in the
>> >>> maven home, right?
>> >>>
>> >>>>
>> >>>>
>> >>>>>
>> >>>>>
>> >>>>> >
>> >>>>> > maven related changes merely laxed the validation to allow those
>> three
>> >>>>> > expressions in version, but does not provide anything as "source"
>> for
>> >>>>> those.
>> >>>>> >
>> >>>>> > On Wed, Mar 9, 2016 at 2:44 PM Stephen Connolly <
>> >>>>> > [hidden email] <javascript:;>> wrote:
>> >>>>> >
>> >>>>> >> I have no clue... that is a different question we should ask of
>> the
>> >>>>> person
>> >>>>> >> who implemented this functionality
>> >>>>> >>
>> >>>>> >> On 9 March 2016 at 13:40, Benson Margulies <
>> [hidden email]
>> >>>>> <javascript:;>> wrote:
>> >>>>> >>
>> >>>>> >> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
>> >>>>> >> > <[hidden email] <javascript:;>> wrote:
>> >>>>> >> > > In the .mvn folder put an extension that contributes the
>> ${rev}
>> >>>>> >> property
>> >>>>> >> > > based on whatever you seem safe
>> >>>>> >> >
>> >>>>> >> > Stephen, can you please offer some details? Just what sort of
>> >>>>> >> > extension? An event spy that sees session start? Something
>> else? Does
>> >>>>> >> > this require 3.3.x  or does it work with 3.2.5?
>> >>>>> >> >
>> >>>>> >> > >
>> >>>>> >> > > Then just have the project version include the ${rev} at the
>> >>>>> >> appropriate
>> >>>>> >> > > place
>> >>>>> >> > >
>> >>>>> >> > > On Tuesday 8 March 2016, Gary Gregory <
>> [hidden email]
>> >>>>> <javascript:;>> wrote:
>> >>>>> >> > >
>> >>>>> >> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B <[hidden email]
>> >>>>> <javascript:;>
>> >>>>> >> > <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 <
>> >>>>> >> [hidden email] <javascript:;>
>> >>>>> >> > >> <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 <
>> [hidden email]
>> >>>>> <javascript:;>
>> >>>>> >> > >> <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 <
>> >>>>> >> > >> > > > [hidden email] <javascript:;>
>> >>>>> <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 <
>> [hidden email]
>> >>>>> <javascript:;>
>> >>>>> >> .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: [hidden email] <javascript:;>
>> <javascript:;> |
>> >>>>> >> [hidden email] <javascript:;>
>> >>>>> >> > >> <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: [hidden email] <javascript:;>
>> <javascript:;> |
>> >>>>> [hidden email] <javascript:;>
>> >>>>> >> > >> <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
>> >>>>> >> >
>> >>>>> >> >
>> ---------------------------------------------------------------------
>> >>>>> >> > To unsubscribe, e-mail: [hidden email]
>> >>>>> <javascript:;>
>> >>>>> >> > For additional commands, e-mail: [hidden email]
>> >>>>> <javascript:;>
>> >>>>> >> >
>> >>>>> >> >
>> >>>>> >>
>> >>>>>
>> >>>>>
>> ---------------------------------------------------------------------
>> >>>>> To unsubscribe, e-mail: [hidden email]
>> <javascript:;>
>> >>>>> For additional commands, e-mail: [hidden email]
>> >>>>> <javascript:;>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>> --
>> >>>> Sent from my phone
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> --
> Sent from my phone
>


--
Sent from my phone
12