You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Al...@miranda.com on 2014/01/20 17:59:01 UTC
versions maven plugin
Not sure if this is the right list for codehaus plugins. If not I
apologize
I have a pom with this
<dependencies>
<dependency>
<groupId>foo.blah</groupId>
<artifactId>bar</artifactId>
<version>1.2.0-RC-7-SNAPSHOT</version>
</dependency>
</dependencies>
I want to run the versions plugin to replace 1.2.0-RC-7-SNAPSHOT with the
version we actually released of the code, which is 1.2.0-RC-6. Looking at
the available mojos, it seems like versions:use-latest-releases is the
right one to use. In the matrix here it says that this goal will modify
-SNAPSHOT dependencies. Well, it doesn't. If i instead set the version to
1.2.0-RC-3 (no snapshot), the mojo does update the dependency to
1.2.0-RC-6 so I don't know if this is just the documentation being wrong.
I also tried use-latest-versions without success
Any idea how to do this? I just want to change the dependencies (which are
currently SNAPSHOT due to the m-release-p) to the latest released versions
Thank you,
Alejandro Endo | Software Designer/Concepteur de logiciels
DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.
Re: versions maven plugin
Posted by Stephen Connolly <st...@gmail.com>.
It sounded like a single reactor release of everything to me... in which
case staging is fine
On 21 January 2014 11:07, James Nord (jnord) <jn...@cisco.com> wrote:
>
> > > Or to put a contrived (yet realistic) example on this - Consider a
> > > shared library Y. You have no auto testing of it so its only tested
> > > inside products (otherwise you know its good to go - and wouldn't
> > > release RCs).
> > > Library Y is in a stage at version 1.2.3 This library is picked up
> > > from the stage and placed into a product Z (inside say an RPM)
> > >
> >
> > If you are doing this then you are using staging wrong IMHO. A stage
> should
> > *only* be used for either testing the staged release *or* for where
> there is
> > a synchronized deliverable that must be built from a different machine,
> e.g.
> > the windows .DLL and the linux .so's
>
> But it did not sound like that was the original authors request as he was
> using RCs of dependencies (libraries).
> So I felt like the solution of staging here would leave to a somewhat
> similar example to that above.
>
> /James
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
RE: versions maven plugin
Posted by "James Nord (jnord)" <jn...@cisco.com>.
> > Or to put a contrived (yet realistic) example on this - Consider a
> > shared library Y. You have no auto testing of it so its only tested
> > inside products (otherwise you know its good to go - and wouldn't
> > release RCs).
> > Library Y is in a stage at version 1.2.3 This library is picked up
> > from the stage and placed into a product Z (inside say an RPM)
> >
>
> If you are doing this then you are using staging wrong IMHO. A stage should
> *only* be used for either testing the staged release *or* for where there is
> a synchronized deliverable that must be built from a different machine, e.g.
> the windows .DLL and the linux .so's
But it did not sound like that was the original authors request as he was using RCs of dependencies (libraries).
So I felt like the solution of staging here would leave to a somewhat similar example to that above.
/James
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: versions maven plugin
Posted by Stephen Connolly <st...@gmail.com>.
On 21 January 2014 09:41, James Nord (jnord) <jn...@cisco.com> wrote:
> I wouldn't have normally chimed in here against Stephen (He knows what he
> is on about) however...
>
> IMHO Staging only works with very small teams with dedicated
> infrastructure (in which case QC generally are ok with a rebuild!).
> If you have larger teams and share infrastructure (repo manager, CI)
> across projects (and binaries across teams) then that way will lead to
> madness.
>
> Or to put it another way Staging with any human intervention is evil.
> Staging without human intervention is doing things too late - you should
> know before hand that your code is good to go (if you use releases) - and
> if you are doing things without human intervention then you should know up
> front that the code is good to go - which means you don't need staging
> (apart form for an atomic deployment of a multi module build; but there are
> other ways to do that now).
>
> Or to put a contrived (yet realistic) example on this -
> Consider a shared library Y. You have no auto testing of it so its only
> tested inside products (otherwise you know its good to go - and wouldn't
> release RCs).
> Library Y is in a stage at version 1.2.3
> This library is picked up from the stage and placed into a product Z
> (inside say an RPM)
>
If you are doing this then you are using staging wrong IMHO. A stage should
*only* be used for either testing the staged release *or* for where there
is a synchronized deliverable that must be built from a different machine,
e.g. the windows .DLL and the linux .so's
The case of Z may be OK as Z may be an arch specific component... but you
are calling it a product, so if it is a product then you should have closed
and released the library Y stage *before* you consume from Z
Z is released into a stage
> The library is picked up in product X (inside say another RPM)
> QC start testing Z.
> QC test X and it reveals a bug in Y. Both stages (Y and X) are dropped
> QC finish testing Z from the stage and then promote it as its good.
> The Y developers re-spin 1.2.3...
>
Well the issue here is that you should only stage the last layer. In this
example Y cannot be tested on its own, so there is no point spinning RCs,
etc. You just have to bite the bullet and cut a release. It doesn't matter
whether you call the release 1.5-RC-1 or 1.5.0 because if you need to
respin, you'll be bumping another version anyway.
Where staging matters is at the last, publically visible, layer... i.e. Z.
You use staging for Z and just spin version numbers and releases for
everything else.
If Y and Z are in the same release root... then they both get staged. If
they are in separate release roots, then Y just bangs out releases and Z
has staging.
More complex is when both Y and Z are public... i.e. Y is the API client
that Z uses... well in that case how is a broken 1.5-RC-1 being out there
any different from a broken 1.5.0... the solution is obvious... you need
tests that you can trust... get those tests and then apply staging on Y
>
> Z is released into the field with a verison of Y that doesn't match what's
> at some point going to be in the repo.
> The build Z is unreproducible - this is the worst possible situation to be
> in,
>
> Now there are those that say - your staging rules on your MRM should check
> the dependencies - but now you are at the behest of your MRM.
> Nexus certainly can't do this without custom effort on your side - and
> then you will have to intimately have full knowledge of the inside of the
> build that produced this artifact - what groups on your MRM use, what
> version of maven.. You can't just unpack and look at the use the
> dependencies - what about shaded deps. To do all this work post build is
> IMHO nigh on impossible.
>
>
> /James
>
> > -----Original Message-----
> > From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> > Sent: 20 January 2014 19:40
> > To: Maven Users List
> > Subject: Re: versions maven plugin
> >
> > Consider staging support on your repo manager
> >
> > On Monday, 20 January 2014, <Al...@miranda.com> wrote:
> >
> > > I didn't. QA is not happy about rebuilding the system once it's been
> > > approved so we have to release the RC as approved.
> > >
> > > So all our versions are always RC-X-SNAPSHOT or RC-X
> > >
> > > Alejandro Endo | Software Designer/Concepteur de logiciels
> > >
> > >
> > >
> > >
> > > From: Stephen Connolly <stephen.alan.connolly@gmail.com
> > <javascript:;>>
> > > To: Maven Users List <users@maven.apache.org <javascript:;>>,
> > > Date: 2014-01-20 13:50
> > > Subject: Re: versions maven plugin
> > >
> > >
> > >
> > > How did you turn your RC into a released version? (I would do it with
> > > the release plugin and just verify the SCM changelog is unchanged)
> > >
> > > On Monday, 20 January 2014, <Alejandro.Endo@miranda.com
> > > <javascript:;>>
> > > wrote:
> > >
> > > > Thank you Stephen. Are there any other ways to stabilize my
> > > > dependencies then?
> > > >
> > > > i have > 300 poms all depending on the released+1 development
> version.
> > > > This must be a common use-case when using RCs, no? you increase all
> > > > your versions to your next RC-2-SNAPSHOT as soon as you create your
> > > > RC-1, but if that RC-1 happens to be released, then all your poms
> > > > will be
> > > depending
> > > > on the SNAPSHOT of an RC-2 that will never be made so you have to
> > > > "downgrade" your dependency versions
> > > >
> > > > Am I doing something out of the ordinary here?
> > > >
> > > >
> > > >
> > > >
> > > > Alejandro Endo | Software Designer/Concepteur de logiciels
> > > >
> > > >
> > > >
> > > > From: Stephen Connolly <stephen.alan.connolly@gmail.com
> > <javascript:;><javascript:
> > > ;>>
> > > > To: Maven Users List <users@maven.apache.org
> > <javascript:;><javascript:;>>,
> > > > Date: 2014-01-20 12:34
> > > > Subject: Re: versions maven plugin
> > > >
> > > >
> > > >
> > > > v-m-p does not roll back version numbers
> > > >
> > > >
> > > > On 20 January 2014 16:59, <Alejandro.Endo@miranda.com
> > > > <javascript:;><javascript:;>>
> > > > wrote:
> > > >
> > > > > Not sure if this is the right list for codehaus plugins. If not I
> > > > > apologize
> > > > >
> > > > > I have a pom with this
> > > > >
> > > > > <dependencies>
> > > > > <dependency>
> > > > > <groupId>foo.blah</groupId>
> > > > > <artifactId>bar</artifactId>
> > > > > <version>1.2.0-RC-7-SNAPSHOT</version>
> > > > > </dependency>
> > > > > </dependencies>
> > > > >
> > > > > I want to run the versions plugin to replace 1.2.0-RC-7-SNAPSHOT
> > > > > with
> > > > the
> > > > > version we actually released of the code, which is 1.2.0-RC-6.
> > > > > Looking
> > > > at
> > > > > the available mojos, it seems like versions:use-latest-releases is
> > > > > the right one to use. In the matrix here it says that this goal
> > > > > will
> > > modify
> > > > > -SNAPSHOT dependencies. Well, it doesn't. If i instead set the
> > > > > version
> > > > to
> > > > > 1.2.0-RC-3 (no snapshot), the mojo does update the dependency to
> > > > > 1.2.0-RC-6 so I don't know if this is just the documentation being
> > > > wrong.
> > > > > I also tried use-latest-versions without success
> > > > >
> > > > > Any idea how to do this? I just want to change the dependencies
> > > > > (which
> > > > are
> > > > > currently SNAPSHOT due to the m-release-p) to the latest released
> > > > versions
> > > > >
> > > > > Thank you,
> > > > > Alejandro Endo | Software Designer/Concepteur de logiciels
> > > > >
> > > > > DISCLAIMER:
> > > > > Privileged and/or Confidential information may be contained in
> > > > > this message. If you are not the addressee of this message, you
> > > > > may not copy, use or deliver this message to anyone. In such
> > > > > event, you should destroy the message and kindly notify the sender
> > > > > by reply e-mail. It is understood that opinions or conclusions
> > > > > that do not relate to the official business of the company are
> > > > > neither given nor endorsed by the company.
> > > > > Thank You.
> > > > >
> > > >
> > > >
> > > > DISCLAIMER:
> > > > Privileged and/or Confidential information may be contained in this
> > > > message. If you are not the addressee of this message, you may not
> > > > copy, use or deliver this message to anyone. In such event, you
> > > > should destroy the message and kindly notify the sender by reply
> > > > e-mail. It is understood that opinions or conclusions that do not
> > > > relate to the official business of the company are neither given nor
> > > > endorsed by the company.
> > > > Thank You.
> > > >
> > >
> > >
> > > --
> > > Sent from my phone
> > >
> > >
> > > DISCLAIMER:
> > > Privileged and/or Confidential information may be contained in this
> > > message. If you are not the addressee of this message, you may not
> > > copy, use or deliver this message to anyone. In such event, you should
> > > destroy the message and kindly notify the sender by reply e-mail. It
> > > is understood that opinions or conclusions that do not relate to the
> > > official business of the company are neither given nor endorsed by the
> > > company.
> > > Thank You.
> > >
> >
> >
> > --
> > Sent from my phone
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
RE: versions maven plugin
Posted by "James Nord (jnord)" <jn...@cisco.com>.
I wouldn't have normally chimed in here against Stephen (He knows what he is on about) however...
IMHO Staging only works with very small teams with dedicated infrastructure (in which case QC generally are ok with a rebuild!).
If you have larger teams and share infrastructure (repo manager, CI) across projects (and binaries across teams) then that way will lead to madness.
Or to put it another way Staging with any human intervention is evil.
Staging without human intervention is doing things too late - you should know before hand that your code is good to go (if you use releases) - and if you are doing things without human intervention then you should know up front that the code is good to go - which means you don't need staging (apart form for an atomic deployment of a multi module build; but there are other ways to do that now).
Or to put a contrived (yet realistic) example on this -
Consider a shared library Y. You have no auto testing of it so its only tested inside products (otherwise you know its good to go - and wouldn't release RCs).
Library Y is in a stage at version 1.2.3
This library is picked up from the stage and placed into a product Z (inside say an RPM)
Z is released into a stage
The library is picked up in product X (inside say another RPM)
QC start testing Z.
QC test X and it reveals a bug in Y. Both stages (Y and X) are dropped
QC finish testing Z from the stage and then promote it as its good.
The Y developers re-spin 1.2.3...
Z is released into the field with a verison of Y that doesn't match what's at some point going to be in the repo.
The build Z is unreproducible - this is the worst possible situation to be in,
Now there are those that say - your staging rules on your MRM should check the dependencies - but now you are at the behest of your MRM.
Nexus certainly can't do this without custom effort on your side - and then you will have to intimately have full knowledge of the inside of the build that produced this artifact - what groups on your MRM use, what version of maven.. You can't just unpack and look at the use the dependencies - what about shaded deps. To do all this work post build is IMHO nigh on impossible.
/James
> -----Original Message-----
> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> Sent: 20 January 2014 19:40
> To: Maven Users List
> Subject: Re: versions maven plugin
>
> Consider staging support on your repo manager
>
> On Monday, 20 January 2014, <Al...@miranda.com> wrote:
>
> > I didn't. QA is not happy about rebuilding the system once it's been
> > approved so we have to release the RC as approved.
> >
> > So all our versions are always RC-X-SNAPSHOT or RC-X
> >
> > Alejandro Endo | Software Designer/Concepteur de logiciels
> >
> >
> >
> >
> > From: Stephen Connolly <stephen.alan.connolly@gmail.com
> <javascript:;>>
> > To: Maven Users List <users@maven.apache.org <javascript:;>>,
> > Date: 2014-01-20 13:50
> > Subject: Re: versions maven plugin
> >
> >
> >
> > How did you turn your RC into a released version? (I would do it with
> > the release plugin and just verify the SCM changelog is unchanged)
> >
> > On Monday, 20 January 2014, <Alejandro.Endo@miranda.com
> > <javascript:;>>
> > wrote:
> >
> > > Thank you Stephen. Are there any other ways to stabilize my
> > > dependencies then?
> > >
> > > i have > 300 poms all depending on the released+1 development version.
> > > This must be a common use-case when using RCs, no? you increase all
> > > your versions to your next RC-2-SNAPSHOT as soon as you create your
> > > RC-1, but if that RC-1 happens to be released, then all your poms
> > > will be
> > depending
> > > on the SNAPSHOT of an RC-2 that will never be made so you have to
> > > "downgrade" your dependency versions
> > >
> > > Am I doing something out of the ordinary here?
> > >
> > >
> > >
> > >
> > > Alejandro Endo | Software Designer/Concepteur de logiciels
> > >
> > >
> > >
> > > From: Stephen Connolly <stephen.alan.connolly@gmail.com
> <javascript:;><javascript:
> > ;>>
> > > To: Maven Users List <users@maven.apache.org
> <javascript:;><javascript:;>>,
> > > Date: 2014-01-20 12:34
> > > Subject: Re: versions maven plugin
> > >
> > >
> > >
> > > v-m-p does not roll back version numbers
> > >
> > >
> > > On 20 January 2014 16:59, <Alejandro.Endo@miranda.com
> > > <javascript:;><javascript:;>>
> > > wrote:
> > >
> > > > Not sure if this is the right list for codehaus plugins. If not I
> > > > apologize
> > > >
> > > > I have a pom with this
> > > >
> > > > <dependencies>
> > > > <dependency>
> > > > <groupId>foo.blah</groupId>
> > > > <artifactId>bar</artifactId>
> > > > <version>1.2.0-RC-7-SNAPSHOT</version>
> > > > </dependency>
> > > > </dependencies>
> > > >
> > > > I want to run the versions plugin to replace 1.2.0-RC-7-SNAPSHOT
> > > > with
> > > the
> > > > version we actually released of the code, which is 1.2.0-RC-6.
> > > > Looking
> > > at
> > > > the available mojos, it seems like versions:use-latest-releases is
> > > > the right one to use. In the matrix here it says that this goal
> > > > will
> > modify
> > > > -SNAPSHOT dependencies. Well, it doesn't. If i instead set the
> > > > version
> > > to
> > > > 1.2.0-RC-3 (no snapshot), the mojo does update the dependency to
> > > > 1.2.0-RC-6 so I don't know if this is just the documentation being
> > > wrong.
> > > > I also tried use-latest-versions without success
> > > >
> > > > Any idea how to do this? I just want to change the dependencies
> > > > (which
> > > are
> > > > currently SNAPSHOT due to the m-release-p) to the latest released
> > > versions
> > > >
> > > > Thank you,
> > > > Alejandro Endo | Software Designer/Concepteur de logiciels
> > > >
> > > > DISCLAIMER:
> > > > Privileged and/or Confidential information may be contained in
> > > > this message. If you are not the addressee of this message, you
> > > > may not copy, use or deliver this message to anyone. In such
> > > > event, you should destroy the message and kindly notify the sender
> > > > by reply e-mail. It is understood that opinions or conclusions
> > > > that do not relate to the official business of the company are
> > > > neither given nor endorsed by the company.
> > > > Thank You.
> > > >
> > >
> > >
> > > DISCLAIMER:
> > > Privileged and/or Confidential information may be contained in this
> > > message. If you are not the addressee of this message, you may not
> > > copy, use or deliver this message to anyone. In such event, you
> > > should destroy the message and kindly notify the sender by reply
> > > e-mail. It is understood that opinions or conclusions that do not
> > > relate to the official business of the company are neither given nor
> > > endorsed by the company.
> > > Thank You.
> > >
> >
> >
> > --
> > Sent from my phone
> >
> >
> > DISCLAIMER:
> > Privileged and/or Confidential information may be contained in this
> > message. If you are not the addressee of this message, you may not
> > copy, use or deliver this message to anyone. In such event, you should
> > destroy the message and kindly notify the sender by reply e-mail. It
> > is understood that opinions or conclusions that do not relate to the
> > official business of the company are neither given nor endorsed by the
> > company.
> > Thank You.
> >
>
>
> --
> Sent from my phone
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: versions maven plugin
Posted by Stephen Connolly <st...@gmail.com>.
Consider staging support on your repo manager
On Monday, 20 January 2014, <Al...@miranda.com> wrote:
> I didn't. QA is not happy about rebuilding the system once it's been
> approved so we have to release the RC as approved.
>
> So all our versions are always RC-X-SNAPSHOT or RC-X
>
> Alejandro Endo | Software Designer/Concepteur de logiciels
>
>
>
>
> From: Stephen Connolly <stephen.alan.connolly@gmail.com <javascript:;>>
> To: Maven Users List <users@maven.apache.org <javascript:;>>,
> Date: 2014-01-20 13:50
> Subject: Re: versions maven plugin
>
>
>
> How did you turn your RC into a released version? (I would do it with the
> release plugin and just verify the SCM changelog is unchanged)
>
> On Monday, 20 January 2014, <Alejandro.Endo@miranda.com <javascript:;>>
> wrote:
>
> > Thank you Stephen. Are there any other ways to stabilize my dependencies
> > then?
> >
> > i have > 300 poms all depending on the released+1 development version.
> > This must be a common use-case when using RCs, no? you increase all your
> > versions to your next RC-2-SNAPSHOT as soon as you create your RC-1, but
> > if that RC-1 happens to be released, then all your poms will be
> depending
> > on the SNAPSHOT of an RC-2 that will never be made so you have to
> > "downgrade" your dependency versions
> >
> > Am I doing something out of the ordinary here?
> >
> >
> >
> >
> > Alejandro Endo | Software Designer/Concepteur de logiciels
> >
> >
> >
> > From: Stephen Connolly <stephen.alan.connolly@gmail.com <javascript:;><javascript:
> ;>>
> > To: Maven Users List <users@maven.apache.org <javascript:;><javascript:;>>,
> > Date: 2014-01-20 12:34
> > Subject: Re: versions maven plugin
> >
> >
> >
> > v-m-p does not roll back version numbers
> >
> >
> > On 20 January 2014 16:59, <Alejandro.Endo@miranda.com <javascript:;><javascript:;>>
> > wrote:
> >
> > > Not sure if this is the right list for codehaus plugins. If not I
> > > apologize
> > >
> > > I have a pom with this
> > >
> > > <dependencies>
> > > <dependency>
> > > <groupId>foo.blah</groupId>
> > > <artifactId>bar</artifactId>
> > > <version>1.2.0-RC-7-SNAPSHOT</version>
> > > </dependency>
> > > </dependencies>
> > >
> > > I want to run the versions plugin to replace 1.2.0-RC-7-SNAPSHOT with
> > the
> > > version we actually released of the code, which is 1.2.0-RC-6. Looking
> > at
> > > the available mojos, it seems like versions:use-latest-releases is the
> > > right one to use. In the matrix here it says that this goal will
> modify
> > > -SNAPSHOT dependencies. Well, it doesn't. If i instead set the version
> > to
> > > 1.2.0-RC-3 (no snapshot), the mojo does update the dependency to
> > > 1.2.0-RC-6 so I don't know if this is just the documentation being
> > wrong.
> > > I also tried use-latest-versions without success
> > >
> > > Any idea how to do this? I just want to change the dependencies (which
> > are
> > > currently SNAPSHOT due to the m-release-p) to the latest released
> > versions
> > >
> > > Thank you,
> > > Alejandro Endo | Software Designer/Concepteur de logiciels
> > >
> > > DISCLAIMER:
> > > Privileged and/or Confidential information may be contained in this
> > > message. If you are not the addressee of this message, you may not
> > > copy, use or deliver this message to anyone. In such event, you
> > > should destroy the message and kindly notify the sender by reply
> > > e-mail. It is understood that opinions or conclusions that do not
> > > relate to the official business of the company are neither given
> > > nor endorsed by the company.
> > > Thank You.
> > >
> >
> >
> > DISCLAIMER:
> > Privileged and/or Confidential information may be contained in this
> > message. If you are not the addressee of this message, you may not
> > copy, use or deliver this message to anyone. In such event, you
> > should destroy the message and kindly notify the sender by reply
> > e-mail. It is understood that opinions or conclusions that do not
> > relate to the official business of the company are neither given
> > nor endorsed by the company.
> > Thank You.
> >
>
>
> --
> Sent from my phone
>
>
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
> Thank You.
>
--
Sent from my phone
Re: versions maven plugin
Posted by Al...@miranda.com.
I didn't. QA is not happy about rebuilding the system once it's been
approved so we have to release the RC as approved.
So all our versions are always RC-X-SNAPSHOT or RC-X
Alejandro Endo | Software Designer/Concepteur de logiciels
From: Stephen Connolly <st...@gmail.com>
To: Maven Users List <us...@maven.apache.org>,
Date: 2014-01-20 13:50
Subject: Re: versions maven plugin
How did you turn your RC into a released version? (I would do it with the
release plugin and just verify the SCM changelog is unchanged)
On Monday, 20 January 2014, <Al...@miranda.com> wrote:
> Thank you Stephen. Are there any other ways to stabilize my dependencies
> then?
>
> i have > 300 poms all depending on the released+1 development version.
> This must be a common use-case when using RCs, no? you increase all your
> versions to your next RC-2-SNAPSHOT as soon as you create your RC-1, but
> if that RC-1 happens to be released, then all your poms will be
depending
> on the SNAPSHOT of an RC-2 that will never be made so you have to
> "downgrade" your dependency versions
>
> Am I doing something out of the ordinary here?
>
>
>
>
> Alejandro Endo | Software Designer/Concepteur de logiciels
>
>
>
> From: Stephen Connolly <stephen.alan.connolly@gmail.com <javascript:
;>>
> To: Maven Users List <users@maven.apache.org <javascript:;>>,
> Date: 2014-01-20 12:34
> Subject: Re: versions maven plugin
>
>
>
> v-m-p does not roll back version numbers
>
>
> On 20 January 2014 16:59, <Alejandro.Endo@miranda.com <javascript:;>>
> wrote:
>
> > Not sure if this is the right list for codehaus plugins. If not I
> > apologize
> >
> > I have a pom with this
> >
> > <dependencies>
> > <dependency>
> > <groupId>foo.blah</groupId>
> > <artifactId>bar</artifactId>
> > <version>1.2.0-RC-7-SNAPSHOT</version>
> > </dependency>
> > </dependencies>
> >
> > I want to run the versions plugin to replace 1.2.0-RC-7-SNAPSHOT with
> the
> > version we actually released of the code, which is 1.2.0-RC-6. Looking
> at
> > the available mojos, it seems like versions:use-latest-releases is the
> > right one to use. In the matrix here it says that this goal will
modify
> > -SNAPSHOT dependencies. Well, it doesn't. If i instead set the version
> to
> > 1.2.0-RC-3 (no snapshot), the mojo does update the dependency to
> > 1.2.0-RC-6 so I don't know if this is just the documentation being
> wrong.
> > I also tried use-latest-versions without success
> >
> > Any idea how to do this? I just want to change the dependencies (which
> are
> > currently SNAPSHOT due to the m-release-p) to the latest released
> versions
> >
> > Thank you,
> > Alejandro Endo | Software Designer/Concepteur de logiciels
> >
> > DISCLAIMER:
> > Privileged and/or Confidential information may be contained in this
> > message. If you are not the addressee of this message, you may not
> > copy, use or deliver this message to anyone. In such event, you
> > should destroy the message and kindly notify the sender by reply
> > e-mail. It is understood that opinions or conclusions that do not
> > relate to the official business of the company are neither given
> > nor endorsed by the company.
> > Thank You.
> >
>
>
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
> Thank You.
>
--
Sent from my phone
DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.
Re: versions maven plugin
Posted by Stephen Connolly <st...@gmail.com>.
How did you turn your RC into a released version? (I would do it with the
release plugin and just verify the SCM changelog is unchanged)
On Monday, 20 January 2014, <Al...@miranda.com> wrote:
> Thank you Stephen. Are there any other ways to stabilize my dependencies
> then?
>
> i have > 300 poms all depending on the released+1 development version.
> This must be a common use-case when using RCs, no? you increase all your
> versions to your next RC-2-SNAPSHOT as soon as you create your RC-1, but
> if that RC-1 happens to be released, then all your poms will be depending
> on the SNAPSHOT of an RC-2 that will never be made so you have to
> "downgrade" your dependency versions
>
> Am I doing something out of the ordinary here?
>
>
>
>
> Alejandro Endo | Software Designer/Concepteur de logiciels
>
>
>
> From: Stephen Connolly <stephen.alan.connolly@gmail.com <javascript:;>>
> To: Maven Users List <users@maven.apache.org <javascript:;>>,
> Date: 2014-01-20 12:34
> Subject: Re: versions maven plugin
>
>
>
> v-m-p does not roll back version numbers
>
>
> On 20 January 2014 16:59, <Alejandro.Endo@miranda.com <javascript:;>>
> wrote:
>
> > Not sure if this is the right list for codehaus plugins. If not I
> > apologize
> >
> > I have a pom with this
> >
> > <dependencies>
> > <dependency>
> > <groupId>foo.blah</groupId>
> > <artifactId>bar</artifactId>
> > <version>1.2.0-RC-7-SNAPSHOT</version>
> > </dependency>
> > </dependencies>
> >
> > I want to run the versions plugin to replace 1.2.0-RC-7-SNAPSHOT with
> the
> > version we actually released of the code, which is 1.2.0-RC-6. Looking
> at
> > the available mojos, it seems like versions:use-latest-releases is the
> > right one to use. In the matrix here it says that this goal will modify
> > -SNAPSHOT dependencies. Well, it doesn't. If i instead set the version
> to
> > 1.2.0-RC-3 (no snapshot), the mojo does update the dependency to
> > 1.2.0-RC-6 so I don't know if this is just the documentation being
> wrong.
> > I also tried use-latest-versions without success
> >
> > Any idea how to do this? I just want to change the dependencies (which
> are
> > currently SNAPSHOT due to the m-release-p) to the latest released
> versions
> >
> > Thank you,
> > Alejandro Endo | Software Designer/Concepteur de logiciels
> >
> > DISCLAIMER:
> > Privileged and/or Confidential information may be contained in this
> > message. If you are not the addressee of this message, you may not
> > copy, use or deliver this message to anyone. In such event, you
> > should destroy the message and kindly notify the sender by reply
> > e-mail. It is understood that opinions or conclusions that do not
> > relate to the official business of the company are neither given
> > nor endorsed by the company.
> > Thank You.
> >
>
>
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
> Thank You.
>
--
Sent from my phone
Re: versions maven plugin
Posted by Thomas Broyer <t....@gmail.com>.
Possibly using 1.0-SNAPSHOT instead of 1.0-RC-SNAPSHOT as your naming rule
would make it easier: you're working towards 1.0 and on the path to this
release you cut a few RCs: 1.0-RC-1, 1.0-RC-2, etc.
Le 20 janv. 2014 19:34, <Al...@miranda.com> a écrit :
> Thank you Stephen. Are there any other ways to stabilize my dependencies
> then?
>
> i have > 300 poms all depending on the released+1 development version.
> This must be a common use-case when using RCs, no? you increase all your
> versions to your next RC-2-SNAPSHOT as soon as you create your RC-1, but
> if that RC-1 happens to be released, then all your poms will be depending
> on the SNAPSHOT of an RC-2 that will never be made so you have to
> "downgrade" your dependency versions
>
> Am I doing something out of the ordinary here?
>
>
>
>
> Alejandro Endo | Software Designer/Concepteur de logiciels
>
>
>
> From: Stephen Connolly <st...@gmail.com>
> To: Maven Users List <us...@maven.apache.org>,
> Date: 2014-01-20 12:34
> Subject: Re: versions maven plugin
>
>
>
> v-m-p does not roll back version numbers
>
>
> On 20 January 2014 16:59, <Al...@miranda.com> wrote:
>
> > Not sure if this is the right list for codehaus plugins. If not I
> > apologize
> >
> > I have a pom with this
> >
> > <dependencies>
> > <dependency>
> > <groupId>foo.blah</groupId>
> > <artifactId>bar</artifactId>
> > <version>1.2.0-RC-7-SNAPSHOT</version>
> > </dependency>
> > </dependencies>
> >
> > I want to run the versions plugin to replace 1.2.0-RC-7-SNAPSHOT with
> the
> > version we actually released of the code, which is 1.2.0-RC-6. Looking
> at
> > the available mojos, it seems like versions:use-latest-releases is the
> > right one to use. In the matrix here it says that this goal will modify
> > -SNAPSHOT dependencies. Well, it doesn't. If i instead set the version
> to
> > 1.2.0-RC-3 (no snapshot), the mojo does update the dependency to
> > 1.2.0-RC-6 so I don't know if this is just the documentation being
> wrong.
> > I also tried use-latest-versions without success
> >
> > Any idea how to do this? I just want to change the dependencies (which
> are
> > currently SNAPSHOT due to the m-release-p) to the latest released
> versions
> >
> > Thank you,
> > Alejandro Endo | Software Designer/Concepteur de logiciels
> >
> > DISCLAIMER:
> > Privileged and/or Confidential information may be contained in this
> > message. If you are not the addressee of this message, you may not
> > copy, use or deliver this message to anyone. In such event, you
> > should destroy the message and kindly notify the sender by reply
> > e-mail. It is understood that opinions or conclusions that do not
> > relate to the official business of the company are neither given
> > nor endorsed by the company.
> > Thank You.
> >
>
>
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
> Thank You.
>
Re: versions maven plugin
Posted by Al...@miranda.com.
Thank you Stephen. Are there any other ways to stabilize my dependencies
then?
i have > 300 poms all depending on the released+1 development version.
This must be a common use-case when using RCs, no? you increase all your
versions to your next RC-2-SNAPSHOT as soon as you create your RC-1, but
if that RC-1 happens to be released, then all your poms will be depending
on the SNAPSHOT of an RC-2 that will never be made so you have to
"downgrade" your dependency versions
Am I doing something out of the ordinary here?
Alejandro Endo | Software Designer/Concepteur de logiciels
From: Stephen Connolly <st...@gmail.com>
To: Maven Users List <us...@maven.apache.org>,
Date: 2014-01-20 12:34
Subject: Re: versions maven plugin
v-m-p does not roll back version numbers
On 20 January 2014 16:59, <Al...@miranda.com> wrote:
> Not sure if this is the right list for codehaus plugins. If not I
> apologize
>
> I have a pom with this
>
> <dependencies>
> <dependency>
> <groupId>foo.blah</groupId>
> <artifactId>bar</artifactId>
> <version>1.2.0-RC-7-SNAPSHOT</version>
> </dependency>
> </dependencies>
>
> I want to run the versions plugin to replace 1.2.0-RC-7-SNAPSHOT with
the
> version we actually released of the code, which is 1.2.0-RC-6. Looking
at
> the available mojos, it seems like versions:use-latest-releases is the
> right one to use. In the matrix here it says that this goal will modify
> -SNAPSHOT dependencies. Well, it doesn't. If i instead set the version
to
> 1.2.0-RC-3 (no snapshot), the mojo does update the dependency to
> 1.2.0-RC-6 so I don't know if this is just the documentation being
wrong.
> I also tried use-latest-versions without success
>
> Any idea how to do this? I just want to change the dependencies (which
are
> currently SNAPSHOT due to the m-release-p) to the latest released
versions
>
> Thank you,
> Alejandro Endo | Software Designer/Concepteur de logiciels
>
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
> Thank You.
>
DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.
Re: versions maven plugin
Posted by Stephen Connolly <st...@gmail.com>.
v-m-p does not roll back version numbers
On 20 January 2014 16:59, <Al...@miranda.com> wrote:
> Not sure if this is the right list for codehaus plugins. If not I
> apologize
>
> I have a pom with this
>
> <dependencies>
> <dependency>
> <groupId>foo.blah</groupId>
> <artifactId>bar</artifactId>
> <version>1.2.0-RC-7-SNAPSHOT</version>
> </dependency>
> </dependencies>
>
> I want to run the versions plugin to replace 1.2.0-RC-7-SNAPSHOT with the
> version we actually released of the code, which is 1.2.0-RC-6. Looking at
> the available mojos, it seems like versions:use-latest-releases is the
> right one to use. In the matrix here it says that this goal will modify
> -SNAPSHOT dependencies. Well, it doesn't. If i instead set the version to
> 1.2.0-RC-3 (no snapshot), the mojo does update the dependency to
> 1.2.0-RC-6 so I don't know if this is just the documentation being wrong.
> I also tried use-latest-versions without success
>
> Any idea how to do this? I just want to change the dependencies (which are
> currently SNAPSHOT due to the m-release-p) to the latest released versions
>
> Thank you,
> Alejandro Endo | Software Designer/Concepteur de logiciels
>
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
> Thank You.
>