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