On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
<stephen.alan.conno...@gmail.com> 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 <garydgreg...@gmail.com> wrote:
>
>> On Mon, Mar 7, 2016 at 6:53 PM, Eric B <ebenza...@gmail.com <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 <garydgreg...@gmail.com
>> <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 <ebenza...@gmail.com
>> <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 <
>> > > > stephen.alan.conno...@gmail.com <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 <raghunath...@yahoo.com.invalid>
>> > > wrote:
>> > > > >
>> > > > > > I have a POM with parent node as below: <parent>
>> > > > > > <groupId>com.test</groupId> <artifactId>pom.parent</artifactId>
>> > > > > > <version>${test.version}</version>
>> > > > > > <relativePath>../scripts/pom.xml</relativePath> </parent>
>> > > > > > This used to work till maven 3.3.3 version - mvn clean install.
>> > > > However,
>> > > > > > the version 3.3.9 throws error though. When I change the version
>> > to a
>> > > > > value
>> > > > > > instead of the variable, it works fine.
>> > > > > > Won't maven support variable for version? Or is it a bug with
>> > 3.3.9?
>> > > > > > Appreciate your response...
>> > > > > > - regards,raghu
>> > > > >
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > E-Mail: garydgreg...@gmail.com <javascript:;> | ggreg...@apache.org
>> <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: garydgreg...@gmail.com <javascript:;> | ggreg...@apache.org
>> <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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
