Re: variable doesn't work for version
Almost really working. The only gripe is that it is still warning me
that I have an expression in , 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 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
> 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
>> wrote:
>>> On Wed, Mar 9, 2016 at 3:20 PM, Stephen Connolly
>>> wrote:
On Wednesday, 9 March 2016, Benson Margulies wrote:
> On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák > 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.conno...@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 > wrote:
> >>
> >> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
> >> > > 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 > wrote:
> >> > >
> >> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B
> >> > >
> >> > >> 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.MMDDHHMM). We used to have
> the
> >> SVN
> >> > >> version nu
Re: variable doesn't work for version
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 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
> wrote:
>> On Wed, Mar 9, 2016 at 3:20 PM, Stephen Connolly
>> wrote:
>>> On Wednesday, 9 March 2016, Benson Margulies wrote:
>>>
On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák >>> > 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.conno...@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 >>> > wrote:
>>
>> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
>> > > 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 >>> > wrote:
>> > >
>> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B >>>
>> > >
>> > >> 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.MMDDHHMM). 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":
>> > >>
>> > >>
>> > >>
>> > >>
>> >
MMddHHmm
>> > >> 3
>> > >> 1
>> > >> ${version.major}.${version.minor}
>> > >> ${maven.build.timestamp}
>> > >> ${version.main}.${revision}
>> > >>
>> > >> Each module then has:
>> > >>
>> > >> ${dv.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
>> > >> t
Re: variable doesn't work for version
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 wrote:
> On Wed, Mar 9, 2016 at 3:20 PM, Stephen Connolly
> wrote:
>> On Wednesday, 9 March 2016, Benson Margulies wrote:
>>
>>> On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák >> > 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.conno...@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 >> > wrote:
>>> >>
>>> >> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
>>> >> > > 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 >> > wrote:
>>> >> > >
>>> >> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B >>
>>> >> > >
>>> >> > >> 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.MMDDHHMM). 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":
>>> >> > >>
>>> >> > >>
>>> >> > >>
>>> >> > >>
>>> >> >
>>> MMddHHmm
>>> >> > >> 3
>>> >> > >> 1
>>> >> > >> ${version.major}.${version.minor}
>>> >> > >> ${maven.build.timestamp}
>>> >> > >> ${version.main}.${revision}
>>> >> > >>
>>> >> > >> Each module then has:
>>> >> > >>
>>> >> > >> ${dv.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
>>> >> somethin
Re: variable doesn't work for version
On Wed, Mar 9, 2016 at 3:20 PM, Stephen Connolly
wrote:
> On Wednesday, 9 March 2016, Benson Margulies wrote:
>
>> On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák > > 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.conno...@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 > > wrote:
>> >>
>> >> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
>> >> > > 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 > > wrote:
>> >> > >
>> >> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B >
>> >> > >
>> >> > >> 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.MMDDHHMM). 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":
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >>
>> >> >
>> MMddHHmm
>> >> > >> 3
>> >> > >> 1
>> >> > >> ${version.major}.${version.minor}
>> >> > >> ${maven.build.timestamp}
>> >> > >> ${version.main}.${revision}
>> >> > >>
>> >> > >> Each module then has:
>> >> > >>
>> >> > >> ${dv.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.
>> Gener
Re: variable doesn't work for version
On Wednesday, 9 March 2016, Benson Margulies wrote:
> On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák > 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
>
>
> >
> > 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.conno...@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 > wrote:
> >>
> >> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
> >> > > 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 > wrote:
> >> > >
> >> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B
> >> > >
> >> > >> 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.MMDDHHMM). 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":
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> >
> MMddHHmm
> >> > >> 3
> >> > >> 1
> >> > >> ${version.major}.${version.minor}
> >> > >> ${maven.build.timestamp}
> >> > >> ${version.main}.${revision}
> >> > >>
> >> > >> Each module then has:
> >> > >>
> >> > >> ${dv.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 yo
Re: variable doesn't work for version
On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák 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.conno...@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 wrote:
>>
>> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
>> > 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 wrote:
>> > >
>> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B > > >
>> > >> 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.MMDDHHMM). 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":
>> > >>
>> > >>
>> > >>
>> > >>
>> > MMddHHmm
>> > >> 3
>> > >> 1
>> > >> ${version.major}.${version.minor}
>> > >> ${maven.build.timestamp}
>> > >> ${version.main}.${revision}
>> > >>
>> > >> Each module then has:
>> > >>
>> > >> ${dv.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
Re: variable doesn't work for version
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...
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.conno...@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 wrote:
>
> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
> > 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 wrote:
> > >
> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B > >
> > >> 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.MMDDHHMM). 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":
> > >>
> > >>
> > >>
> > >>
> > MMddHHmm
> > >> 3
> > >> 1
> > >> ${version.major}.${version.minor}
> > >> ${maven.build.timestamp}
> > >> ${version.main}.${revision}
> > >>
> > >> Each module then has:
> > >>
> > >> ${dv.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 <
> garydgreg...@gmail.com
> > >> >
> > >> > wrote:
> > >> >
> > >> > > Is there a Maven-way to do continuous delivery then? As opposed
> > >> > > to continuous integrat
Re: variable doesn't work for version
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 wrote:
> On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
> 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 wrote:
> >
> >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B >
> >> 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.MMDDHHMM). 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":
> >>
> >>
> >>
> >>
> MMddHHmm
> >> 3
> >> 1
> >> ${version.major}.${version.minor}
> >> ${maven.build.timestamp}
> >> ${version.main}.${revision}
> >>
> >> Each module then has:
> >>
> >> ${dv.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 >> >
> >> > 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 >> > 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 element shows up in the META-INF/maven/../pom.*
> files.
> >> > > >
> >> > > > Is using a variable for the version even a good idea?
> >> > > >
> >> >
Re: variable doesn't work for version
On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
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 wrote:
>
>> On Mon, Mar 7, 2016 at 6:53 PM, Eric B >
>> 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.MMDDHHMM). 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":
>>
>>
>>
>> MMddHHmm
>> 3
>> 1
>> ${version.major}.${version.minor}
>> ${maven.build.timestamp}
>> ${version.main}.${revision}
>>
>> Each module then has:
>>
>> ${dv.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 > >
>> > 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 > > 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 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.conno...@gmail.com > 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
>> > > wrote:
>> > > > >
>> > > > > > I have a POM
