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:22:22 GMT
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


Mime
View raw message