maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: variable doesn't work for version
Date Wed, 09 Mar 2016 20:20:43 GMT
On Wednesday, 9 March 2016, Benson Margulies <bimargulies@gmail.com> wrote:

> On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák <tamas@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


>
>
> >
> > 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.connolly@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 <bimargulies@gmail.com
> <javascript:;>> wrote:
> >>
> >> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
> >> > <stephen.alan.connolly@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 <garydgregory@gmail.com
> <javascript:;>> wrote:
> >> > >
> >> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B <ebenzacar@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 <
> >> garydgregory@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 <ebenzacar@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.connolly@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_ku@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: garydgregory@gmail.com <javascript:;>
<javascript:;> |
> >> ggregory@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: garydgregory@gmail.com <javascript:;> <javascript:;>
|
> ggregory@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-unsubscribe@maven.apache.org
> <javascript:;>
> >> > For additional commands, e-mail: users-help@maven.apache.org
> <javascript:;>
> >> >
> >> >
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: users-help@maven.apache.org
> <javascript:;>
>
>

-- 
Sent from my phone

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message