It's ${revision} or ${changelist} or a third one I cannot recall, ${rev} is
on the "moan and wail" listOn Wednesday 9 March 2016, Benson Margulies <[email protected]> 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 <[email protected] > <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 <[email protected] > <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 <[email protected] > <javascript:;>> wrote: > >>> On Wed, Mar 9, 2016 at 3:20 PM, Stephen Connolly > >>> <[email protected] <javascript:;>> wrote: > >>>> On Wednesday, 9 March 2016, Benson Margulies <[email protected] > <javascript:;>> wrote: > >>>> > >>>>> On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák <[email protected] > <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 < > >>>>> > [email protected] <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 <[email protected] > <javascript:;> > >>>>> <javascript:;>> wrote: > >>>>> >> > >>>>> >> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly > >>>>> >> > <[email protected] <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 <[email protected] > <javascript:;> > >>>>> <javascript:;>> wrote: > >>>>> >> > > > >>>>> >> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B <[email protected] > <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 < > >>>>> >> [email protected] <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 < > [email protected] <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 < > >>>>> >> > >> > > > [email protected] <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 < > [email protected] <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: [email protected] <javascript:;> > <javascript:;> <javascript:;> | > >>>>> >> [email protected] <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: [email protected] <javascript:;> > <javascript:;> <javascript:;> | > >>>>> [email protected] <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: [email protected] > <javascript:;> > >>>>> <javascript:;> > >>>>> >> > For additional commands, e-mail: [email protected] > <javascript:;> > >>>>> <javascript:;> > >>>>> >> > > >>>>> >> > > >>>>> >> > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: [email protected] > <javascript:;> <javascript:;> > >>>>> For additional commands, e-mail: [email protected] > <javascript:;> > >>>>> <javascript:;> > >>>>> > >>>>> > >>>> > >>>> -- > >>>> Sent from my phone > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] <javascript:;> > For additional commands, e-mail: [email protected] > <javascript:;> > > -- Sent from my phone
