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
