On Mon, Mar 7, 2016 at 6:53 PM, Eric B <ebenza...@gmail.com> 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>
> 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> 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> 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 | ggreg...@apache.org
> > Java Persistence with Hibernate, Second Edition
> > <http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > Spring Batch in Action <http://www.manning.com/templier/>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
> >
>
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
