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 <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
>> wrote:
>>> On Wed, Mar 9, 2016 at 3:20 PM, Stephen Connolly
>>> <[email protected]> wrote:
>>>> On Wednesday, 9 March 2016, Benson Margulies <[email protected]> wrote:
>>>>
>>>>> On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák <[email protected]
>>>>> <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 <
>>>>> > [email protected] <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 <[email protected]
>>>>> <javascript:;>> wrote:
>>>>> >>
>>>>> >> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
>>>>> >> > <[email protected] <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 <[email protected]
>>>>> <javascript:;>> wrote:
>>>>> >> > >
>>>>> >> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B <[email protected]
>>>>> <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 <
>>>>> >> [email protected] <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 <[email protected]
>>>>> <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 <
>>>>> >> > >> > > > [email protected] <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 <[email protected]
>>>>> <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: [email protected] <javascript:;> <javascript:;> |
>>>>> >> [email protected] <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: [email protected] <javascript:;> <javascript:;> |
>>>>> [email protected] <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: [email protected]
>>>>> <javascript:;>
>>>>> >> > For additional commands, e-mail: [email protected]
>>>>> <javascript:;>
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected] <javascript:;>
>>>>> For additional commands, e-mail: [email protected]
>>>>> <javascript:;>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Sent from my phone
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
