On Thu, Mar 10, 2016 at 3:04 AM, Stephen Connolly
<stephen.alan.conno...@gmail.com> wrote:
> Also I suspect this doesn't fully include logic to ensure that the
'this' = my code, or 'this' = the core implementation for properties
in the version?
> substitution resolved pom is installed/deployed, so may cause issues for
> out-of-reactor consumption as a dependency, or GPG signature validation if
> you try to "fix" with a hack
>
> On Thursday 10 March 2016, Stephen Connolly <stephen.alan.conno...@gmail.com>
> wrote:
>
>> It's ${revision} or ${changelist} or a third one I cannot recall, ${rev}
>> is on the "moan and wail" list
>>
>> On Wednesday 9 March 2016, Benson Margulies <bimargul...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','bimargul...@gmail.com');>> wrote:
>>
>>> 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 <bimargul...@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 <bimargul...@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 <
>>> bimargul...@gmail.com> wrote:
>>> >>> On Wed, Mar 9, 2016 at 3:20 PM, Stephen Connolly
>>> >>> <stephen.alan.conno...@gmail.com> wrote:
>>> >>>> On Wednesday, 9 March 2016, Benson Margulies <bimargul...@gmail.com>
>>> wrote:
>>> >>>>
>>> >>>>> On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák <
>>> ta...@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.conno...@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 <
>>> bimargul...@gmail.com
>>> >>>>> <javascript:;>> wrote:
>>> >>>>> >>
>>> >>>>> >> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
>>> >>>>> >> > <stephen.alan.conno...@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 <
>>> garydgreg...@gmail.com
>>> >>>>> <javascript:;>> wrote:
>>> >>>>> >> > >
>>> >>>>> >> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B <ebenza...@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 <
>>> >>>>> >> garydgreg...@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 <
>>> ebenza...@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.conno...@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...@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: garydgreg...@gmail.com <javascript:;>
>>> <javascript:;> |
>>> >>>>> >> ggreg...@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: garydgreg...@gmail.com <javascript:;>
>>> <javascript:;> |
>>> >>>>> ggreg...@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-unsubscr...@maven.apache.org
>>> >>>>> <javascript:;>
>>> >>>>> >> > For additional commands, e-mail: users-h...@maven.apache.org
>>> >>>>> <javascript:;>
>>> >>>>> >> >
>>> >>>>> >> >
>>> >>>>> >>
>>> >>>>>
>>> >>>>>
>>> ---------------------------------------------------------------------
>>> >>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> <javascript:;>
>>> >>>>> For additional commands, e-mail: users-h...@maven.apache.org
>>> >>>>> <javascript:;>
>>> >>>>>
>>> >>>>>
>>> >>>>
>>> >>>> --
>>> >>>> Sent from my phone
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
>>
>> --
>> Sent from my phone
>>
>
>
> --
> Sent from my phone
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
