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]> 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]> > wrote: >> On Wed, Mar 9, 2016 at 3:20 PM, Stephen Connolly >> <[email protected]> wrote: >>> On Wednesday, 9 March 2016, Benson Margulies <[email protected]> wrote: >>> >>>> On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák <[email protected] >>>> <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:;>> 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:;>> wrote: >>>> >> >>>> >> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly >>>> >> > <[email protected] <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:;>> wrote: >>>> >> > > >>>> >> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B <[email protected] >>>> <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:;>> >>>> >> > >> > 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:;>> 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:;>> 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:;> >>>> >> .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:;> | >>>> >> [email protected] <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:;> | >>>> [email protected] <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:;> >>>> >> > For additional commands, e-mail: [email protected] >>>> <javascript:;> >>>> >> > >>>> >> > >>>> >> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] <javascript:;> >>>> For additional commands, e-mail: [email protected] >>>> <javascript:;> >>>> >>>> >>> >>> -- >>> Sent from my phone
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
