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
