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 20:15:29 GMT
On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák <tamas@cservenak.net> 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 <
> stephen.alan.connolly@gmail.com> 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> wrote:
>>
>> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
>> > <stephen.alan.connolly@gmail.com> 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> wrote:
>> > >
>> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B <ebenzacar@gmail.com
>> > <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:;>>
>> > >> > 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:;>> 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:;>>
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
>> .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:;> |
>> ggregory@apache.org
>> > >> <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:;> | ggregory@apache.org
>> > >> <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
>> > For additional commands, e-mail: users-help@maven.apache.org
>> >
>> >
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message