maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: variable doesn't work for version
Date Wed, 09 Mar 2016 22:14:19 GMT
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


Mime
View raw message