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 <stephen.alan.conno...@gmail.com> 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 <bimargul...@gmail.com > <javascript:_e(%7B%7D,'cvml','bimargul...@gmail.com');>> 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 <bimargul...@gmail.com> >> 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 <bimargul...@gmail.com> >> 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 < >> bimargul...@gmail.com> wrote: >> >>> On Wed, Mar 9, 2016 at 3:20 PM, Stephen Connolly >> >>> <stephen.alan.conno...@gmail.com> wrote: >> >>>> On Wednesday, 9 March 2016, Benson Margulies <bimargul...@gmail.com> >> wrote: >> >>>> >> >>>>> On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák < >> ta...@cservenak.net >> >>>>> <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 < >> >>>>> > stephen.alan.conno...@gmail.com <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 < >> bimargul...@gmail.com >> >>>>> <javascript:;>> wrote: >> >>>>> >> >> >>>>> >> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly >> >>>>> >> > <stephen.alan.conno...@gmail.com <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 < >> garydgreg...@gmail.com >> >>>>> <javascript:;>> wrote: >> >>>>> >> > > >> >>>>> >> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B <ebenza...@gmail.com >> >>>>> <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 < >> >>>>> >> garydgreg...@gmail.com <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 < >> ebenza...@gmail.com >> >>>>> <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 < >> >>>>> >> > >> > > > stephen.alan.conno...@gmail.com <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 < >> raghunath...@yahoo.com >> >>>>> <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: garydgreg...@gmail.com <javascript:;> >> <javascript:;> | >> >>>>> >> ggreg...@apache.org <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: garydgreg...@gmail.com <javascript:;> >> <javascript:;> | >> >>>>> ggreg...@apache.org <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: users-unsubscr...@maven.apache.org >> >>>>> <javascript:;> >> >>>>> >> > For additional commands, e-mail: users-h...@maven.apache.org >> >>>>> <javascript:;> >> >>>>> >> > >> >>>>> >> > >> >>>>> >> >> >>>>> >> >>>>> >> --------------------------------------------------------------------- >> >>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> <javascript:;> >> >>>>> For additional commands, e-mail: users-h...@maven.apache.org >> >>>>> <javascript:;> >> >>>>> >> >>>>> >> >>>> >> >>>> -- >> >>>> Sent from my phone >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > -- > Sent from my phone > -- Sent from my phone