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 Thu, 10 Mar 2016 17:04:02 GMT
the core

On 10 March 2016 at 16:43, Benson Margulies <bimargulies@gmail.com> wrote:

> On Thu, Mar 10, 2016 at 3:04 AM, Stephen Connolly
> <stephen.alan.connolly@gmail.com> wrote:
> > Also I suspect this doesn't fully include logic to ensure that the
>
> 'this' = my code, or 'this' = the core implementation for properties
> in the version?
>
> > substitution resolved pom is installed/deployed, so may cause issues for
> > out-of-reactor consumption as a dependency, or GPG signature validation
> if
> > you try to "fix" with a hack
> >
> > On Thursday 10 March 2016, Stephen Connolly <
> stephen.alan.connolly@gmail.com>
> > wrote:
> >
> >> It's ${revision} or ${changelist} or a third one I cannot recall, ${rev}
> >> is on the "moan and wail" list
> >>
> >> On Wednesday 9 March 2016, Benson Margulies <bimargulies@gmail.com
> >> <javascript:_e(%7B%7D,'cvml','bimargulies@gmail.com');>> wrote:
> >>
> >>> Almost really working. The only gripe is that it is still warning me
> >>> that I have an expression in <version/>, even when I use 'rev' as
> >>> cited. Is that poor choice?
> >>>
> >>> [INFO] rev 0.0.1.20160309172035
> >>> [INFO] Scanning for projects...
> >>> [WARNING]
> >>> [WARNING] Some problems were encountered while building the effective
> >>> model for
> >>>
> com.basistech:auto-version-maven-extension-test:jar:0.0.1.20160309172035
> >>> [WARNING] 'version' contains an expression but should be a constant. @
> >>> com.basistech:auto-version-maven-extension-test:${rev},
> >>> /Users/benson/x/auto-version-maven-extension/src/it/basic/pom.xml,
> >>> line 7, column 14
> >>> [WARNING]
> >>> [WARNING] It is highly recommended to fix these problems because they
> >>> threaten the stability of your build.
> >>> [WARNING]
> >>> [WARNING] For this reason, future Maven versions might no longer
> >>> support building such malformed projects.
> >>> [WARNING]
> >>>
> >>>
> >>>
> >>> On Wed, Mar 9, 2016 at 5:14 PM, Benson Margulies <
> bimargulies@gmail.com>
> >>> wrote:
> >>> > 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 <
> bimargulies@gmail.com>
> >>> 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 <
> >>> bimargulies@gmail.com> wrote:
> >>> >>> On Wed, Mar 9, 2016 at 3:20 PM, Stephen Connolly
> >>> >>> <stephen.alan.connolly@gmail.com> wrote:
> >>> >>>> 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
> >>> >>>
> >>> >>> 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.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
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: users-help@maven.apache.org
> >>>
> >>>
> >>
> >> --
> >> Sent from my phone
> >>
> >
> >
> > --
> > Sent from my phone
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

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