On Tue, Mar 8, 2016 at 11:28 AM, 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 > 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 <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 > -- 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