You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brett Porter <br...@apache.org> on 2010/09/29 15:50:15 UTC
Release plugin snapshot dependency resolution
Hi,
The release plugin has a mode where it can assist you in updating snapshot dependencies at release time. A lot of this is better manipulated with the versions plugin now, but it seems a useful feature to have at release time if you can.
The previous behaviour was a bit weird, though. It would prompt you like this:
Resolve Project Dependency Snapshots.: 'test:MRELEASE-583' set to release? (yes/no) yes: :
What is the next development version? (2.1.3-SNAPSHOT) 2.1.3-SNAPSHOT: :
The first question was redundant - you'd already said you wanted to update snapshots and the other option is failure. The second one assumes you'll be setting the snapshot to the equivalent release, then automatically to the next dev't version. The inflexibility of the first part was pointed out in MRELEASE-583 and I applied a change similar to the patch provided.
However, I disagree with the default choice of updating the dependency to another snapshot - since this is outside of the reactor it's a better practice to pin to the release you just chose. I retained one exception for the use case where it was a more recent snapshot than the release you selected, and the original choice is restored.
As it's only interactive and the form of the questions change, I don't think this will catch anyone by surprise, and encourages better practices.
Does anyone see a downside?
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release plugin snapshot dependency resolution
Posted by Stephen Connolly <st...@gmail.com>.
+1
On 29 September 2010 14:50, Brett Porter <br...@apache.org> wrote:
> Hi,
>
> The release plugin has a mode where it can assist you in updating snapshot
> dependencies at release time. A lot of this is better manipulated with the
> versions plugin now, but it seems a useful feature to have at release time
> if you can.
>
> The previous behaviour was a bit weird, though. It would prompt you like
> this:
>
> Resolve Project Dependency Snapshots.: 'test:MRELEASE-583' set to release?
> (yes/no) yes: :
> What is the next development version? (2.1.3-SNAPSHOT) 2.1.3-SNAPSHOT: :
>
> The first question was redundant - you'd already said you wanted to update
> snapshots and the other option is failure. The second one assumes you'll be
> setting the snapshot to the equivalent release, then automatically to the
> next dev't version. The inflexibility of the first part was pointed out in
> MRELEASE-583 and I applied a change similar to the patch provided.
>
> However, I disagree with the default choice of updating the dependency to
> another snapshot - since this is outside of the reactor it's a better
> practice to pin to the release you just chose. I retained one exception for
> the use case where it was a more recent snapshot than the release you
> selected, and the original choice is restored.
>
> As it's only interactive and the form of the questions change, I don't
> think this will catch anyone by surprise, and encourages better practices.
>
> Does anyone see a downside?
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Release plugin snapshot dependency resolution
Posted by Dennis Lundberg <de...@apache.org>.
On 2010-09-29 15:50, Brett Porter wrote:
> Hi,
>
> The release plugin has a mode where it can assist you in updating snapshot dependencies at release time. A lot of this is better manipulated with the versions plugin now, but it seems a useful feature to have at release time if you can.
>
> The previous behaviour was a bit weird, though. It would prompt you like this:
>
> Resolve Project Dependency Snapshots.: 'test:MRELEASE-583' set to release? (yes/no) yes: :
> What is the next development version? (2.1.3-SNAPSHOT) 2.1.3-SNAPSHOT: :
>
> The first question was redundant - you'd already said you wanted to update snapshots and the other option is failure. The second one assumes you'll be setting the snapshot to the equivalent release, then automatically to the next dev't version. The inflexibility of the first part was pointed out in MRELEASE-583 and I applied a change similar to the patch provided.
>
> However, I disagree with the default choice of updating the dependency to another snapshot - since this is outside of the reactor it's a better practice to pin to the release you just chose. I retained one exception for the use case where it was a more recent snapshot than the release you selected, and the original choice is restored.
>
> As it's only interactive and the form of the questions change, I don't think this will catch anyone by surprise, and encourages better practices.
>
> Does anyone see a downside?
No. Keep the pinned down (release) version of the dependency. Anything
else is out of scope for the Release Plugin in my opinion.
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release plugin snapshot dependency resolution
Posted by Marshall Schor <ms...@schor.com>.
The part where you say:
>> I retained one exception for the use case where it was a more recent snapshot than the release you selected, and the original choice is restored.
I like (+1).
One use case I see for this is where the dependency is actually a parent pom.
Here's an example:
Consider a set of parent poms:
A (version 2-SNAPSHOT)
B (has parent A:2-SNAPSHOT) (version 2-SNAPSHOT)
C (has parent B:2-SNAPSHOT) (version 2-SNAPSHOT)
Furthermore, presume that
A has <modules><module>B</module></modules> and
B has <modules><module>C</module></modules>
to allow the release plugin to put all the children (recursively) of the thing
being released into the Reactor, and update all of the SNAPSHOT references to
non-SNAPSHOTs when a release is done.
Now consider B changes. To release B (not A - since it doesn't need to be
released):
B and all of its children have their versions updated to just "2", and the next
trunk version set to 3-SNAPSHOT.
B's parent, A, would need to be treated by the Release plugin by this proposed
mechanism, and the intended behavior is I think to have:
(in the release tag) B's parent (A) at version 1 (the last released version of
A), and
(in the next trunk) B's parent (A) at version 2-SNAPSHOT.
This I think is an example of a use-case for the "one exception" mentioned at
the top.
-Marshall Schor
On 9/29/2010 9:50 AM, Brett Porter wrote:
> Hi,
>
> The release plugin has a mode where it can assist you in updating snapshot dependencies at release time. A lot of this is better manipulated with the versions plugin now, but it seems a useful feature to have at release time if you can.
>
> The previous behaviour was a bit weird, though. It would prompt you like this:
>
> Resolve Project Dependency Snapshots.: 'test:MRELEASE-583' set to release? (yes/no) yes: :
> What is the next development version? (2.1.3-SNAPSHOT) 2.1.3-SNAPSHOT: :
>
> The first question was redundant - you'd already said you wanted to update snapshots and the other option is failure. The second one assumes you'll be setting the snapshot to the equivalent release, then automatically to the next dev't version. The inflexibility of the first part was pointed out in MRELEASE-583 and I applied a change similar to the patch provided.
>
> However, I disagree with the default choice of updating the dependency to another snapshot - since this is outside of the reactor it's a better practice to pin to the release you just chose. I retained one exception for the use case where it was a more recent snapshot than the release you selected, and the original choice is restored.
>
> As it's only interactive and the form of the questions change, I don't think this will catch anyone by surprise, and encourages better practices.
>
> Does anyone see a downside?
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release plugin snapshot dependency resolution
Posted by Brian Fox <br...@infinity.nu>.
> The first question was redundant - you'd already said you wanted to update snapshots and the other option is failure. The second one assumes you'll be setting the snapshot to the equivalent release, then automatically to the next dev't version. The inflexibility of the first part was pointed out in MRELEASE-583 and I applied a change similar to the patch provided.
>
> However, I disagree with the default choice of updating the dependency to another snapshot - since this is outside of the reactor it's a better practice to pin to the release you just chose.
I emphatically agree.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release plugin snapshot dependency resolution
Posted by Brett Porter <br...@apache.org>.
On 04/10/2010, at 10:36 PM, Marcus Linke wrote:
> Hi brett, of course it is. So should i open a new issue for this feature
> in the JIRA or will you do so? ;)
It's all yours.
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release plugin snapshot dependency resolution
Posted by Marcus Linke <li...@newsaktuell.de>.
Hi brett, of course it is. So should i open a new issue for this feature
in the JIRA or will you do so? ;)
"Maven Developers List" <de...@maven.apache.org> writes:
>On 04/10/2010, at 6:06 PM, Marcus Linke wrote:
>
>> OK accepted. But if this shouldn't be within the responsibility of the
>> release plugin but of the versions plugin, do you know a possibility to
>> hide this versions plugin goal execution from the users point of view?
>So
>> is there a way to hook in the versions plugin goal execution into the
>> release process to automate this? Maybe the release plugin should at
>least
>> be configurable to execute some goals AFTER the release creation phase
>as
>> this can be done with the '-Dgoals'
>>
>(http://maven.apache.org/plugins/maven-release-plugin/perform-mojo.html#goals)
>> option WHILE the release creation phase ? I think this should be a good
>> (because generic) solution. What do you think?
>
>I do agree with this - whether for this use case or not, I think a change
>to the release plugin to be able to run goals at the end of preparation
>would be useful to start breaking up some of the functionality into
>discreet tasks. That's a new issue for the release plugin though :)
>
>- Brett
>
>--
>Brett Porter
>brett@apache.org
>http://brettporter.wordpress.com/
>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release plugin snapshot dependency resolution
Posted by Brett Porter <br...@apache.org>.
On 04/10/2010, at 6:06 PM, Marcus Linke wrote:
> OK accepted. But if this shouldn't be within the responsibility of the
> release plugin but of the versions plugin, do you know a possibility to
> hide this versions plugin goal execution from the users point of view? So
> is there a way to hook in the versions plugin goal execution into the
> release process to automate this? Maybe the release plugin should at least
> be configurable to execute some goals AFTER the release creation phase as
> this can be done with the '-Dgoals'
> (http://maven.apache.org/plugins/maven-release-plugin/perform-mojo.html#goals)
> option WHILE the release creation phase ? I think this should be a good
> (because generic) solution. What do you think?
I do agree with this - whether for this use case or not, I think a change to the release plugin to be able to run goals at the end of preparation would be useful to start breaking up some of the functionality into discreet tasks. That's a new issue for the release plugin though :)
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release plugin snapshot dependency resolution
Posted by Marcus Linke <li...@newsaktuell.de>.
OK accepted. But if this shouldn't be within the responsibility of the
release plugin but of the versions plugin, do you know a possibility to
hide this versions plugin goal execution from the users point of view? So
is there a way to hook in the versions plugin goal execution into the
release process to automate this? Maybe the release plugin should at least
be configurable to execute some goals AFTER the release creation phase as
this can be done with the '-Dgoals'
(http://maven.apache.org/plugins/maven-release-plugin/perform-mojo.html#goals)
option WHILE the release creation phase ? I think this should be a good
(because generic) solution. What do you think?
"Maven Developers List" <de...@maven.apache.org> writes:
>On 30/09/2010, at 7:05 PM, Marcus Linke wrote:
>
>> For my own usecase where we have strongly coupled projects and usually
>> changes are made in both projects we desire behavior b) but other users
>> would like prefer behavior a).
>
>Understood, but we're talking about the default behaviour, and it seems
>clear that it should be discouraging strongly coupled projects. If they
>are released together all the time, you're much better off to put them in
>the same release unit and release in one move.
>
>> This depends on the project structure i
>> think. So this behavior should be configurable by the user (maybe as a
>> plugin?). This would give us the possibility to define the desired
>> behavior per project. One would argue that switching to the next
>snapshot
>> is not the responsibility of the release plugin but for my own usecase
>> manually switching the dependencies to the next development version is
>> tedious and error-prone. One solution could be to integrate
>functionality
>> of the maven-versions-plugin here that collects its version information
>> from the real repository and allows the user to define the desired
>> behavior.
>>
>> Any Comments?
>
>In that practice, it's probably best you use the versions plugin you've
>described as part of your release process. I think integrating it into
>the release plugin is probably overkill.
>
>Thanks for your contribution to the issues!
>
>- Brett
>
>--
>Brett Porter
>brett@apache.org
>http://brettporter.wordpress.com/
>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>For additional commands, e-mail: dev-help@maven.apache.org
>
>
Mit freundlichen Grüßen
Marcus Linke
--
Softwareentwicklung, IT
news aktuell GmbH - Ein Unternehmen der dpa-Gruppe
Mittelweg 144, 20148 Hamburg
Tel: +49 (0)40-4113-2588
Fax: +49 (0)40-4113-2595
www.newsaktuell.de
www.presseportal.de
www.newsaktuell.de/blog
www.twitter.com/newsaktuell
www.youtube.com/newsaktuell
www.facebook.com/pages/newsaktuell/152372075544
www.friendfeed.com/newsaktuell
--
Registergericht: Hamburg, Registernummer: HRB 42 738
Umsatzsteuer-Identifikationsnummer gemäß § 27 a Umsatzsteuergesetz:
DE118617411
Vertretungsberechtigte Personen: Carl-Eduard Meyer (Geschäftsführer),
Frank Stadthoewer (Geschäftsführer)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release plugin snapshot dependency resolution
Posted by Brett Porter <br...@apache.org>.
On 30/09/2010, at 7:05 PM, Marcus Linke wrote:
> For my own usecase where we have strongly coupled projects and usually
> changes are made in both projects we desire behavior b) but other users
> would like prefer behavior a).
Understood, but we're talking about the default behaviour, and it seems clear that it should be discouraging strongly coupled projects. If they are released together all the time, you're much better off to put them in the same release unit and release in one move.
> This depends on the project structure i
> think. So this behavior should be configurable by the user (maybe as a
> plugin?). This would give us the possibility to define the desired
> behavior per project. One would argue that switching to the next snapshot
> is not the responsibility of the release plugin but for my own usecase
> manually switching the dependencies to the next development version is
> tedious and error-prone. One solution could be to integrate functionality
> of the maven-versions-plugin here that collects its version information
> from the real repository and allows the user to define the desired
> behavior.
>
> Any Comments?
In that practice, it's probably best you use the versions plugin you've described as part of your release process. I think integrating it into the release plugin is probably overkill.
Thanks for your contribution to the issues!
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release plugin snapshot dependency resolution
Posted by Marcus Linke <li...@newsaktuell.de>.
The release plugin must avoid snapshot dependencies in the release of an
artifact. This is true. But the question is whether the dependency is
kicked to the next snapshot in the next development version of that
artifact or it stays at the release version. For example project A depends
on artifact B and we want release project A.
Before release of A (Have to release project B before. After that i got
B(0.0.2-SNAPSHOT) right?):
A(0.0.1-SNAPSHOT) depends on B(0.0.1-SNAPSHOT)
The release of A:
A(0.0.1) depends on B(0.0.1)
After the release of A:
a) A(0.0.2-SNAPSHOT) depends on B(0.0.1)
b) A(0.0.2-SNAPSHOT) depends on B(0.0.2-SNAPSHOT).
For my own usecase where we have strongly coupled projects and usually
changes are made in both projects we desire behavior b) but other users
would like prefer behavior a). This depends on the project structure i
think. So this behavior should be configurable by the user (maybe as a
plugin?). This would give us the possibility to define the desired
behavior per project. One would argue that switching to the next snapshot
is not the responsibility of the release plugin but for my own usecase
manually switching the dependencies to the next development version is
tedious and error-prone. One solution could be to integrate functionality
of the maven-versions-plugin here that collects its version information
from the real repository and allows the user to define the desired
behavior.
Any Comments?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release plugin snapshot dependency resolution
Posted by Olivier Lamy <ol...@apache.org>.
+1 too.
Personnally I'd like we fix MRELEASE-594 too.
IMHO it's not a "normal" practice and cause some issues when releasing childs.
We should at least ask user thru an interactive question "Are you sure
you want to release with SNAPSHOT declaration(s) in depMgmt ?" (or
something similar).
WDYT ?
2010/9/29 Benjamin Bentmann <be...@udo.edu>:
> Brett Porter wrote:
>
>> However, I disagree with the default choice of updating the dependency to
>> another snapshot - since this is outside of the reactor it's a better
>> practice to pin to the release you just chose. I retained one exception for
>> the use case where it was a more recent snapshot than the release you
>> selected, and the original choice is restored.
>>
>> As it's only interactive and the form of the questions change, I don't
>> think this will catch anyone by surprise, and encourages better practices.
>
> +1
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Olivier
http://twitter.com/olamy
http://www.linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release plugin snapshot dependency resolution
Posted by Benjamin Bentmann <be...@udo.edu>.
Brett Porter wrote:
> However, I disagree with the default choice of updating the dependency to another snapshot - since this is outside of the reactor it's a better practice to pin to the release you just chose. I retained one exception for the use case where it was a more recent snapshot than the release you selected, and the original choice is restored.
>
> As it's only interactive and the form of the questions change, I don't think this will catch anyone by surprise, and encourages better practices.
+1
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release plugin snapshot dependency resolution
Posted by Arnaud Héritier <ah...@gmail.com>.
>>>
>>
>> That's what it does - it still fails if there are snapshots. It gives you the option if it finds a snapshot to let you change that to a released version.
>
> What's the use case here? You have a snapshot of log4j and there's a release version you can use?
>
> POM says 2.0-SNAPSHOT but 2.0 is available?
>
Yes.
Imagine you have a release train to do for a product based on several projects with various versions.
Your product is composed of 2 projects B which depends on A, both of them are in SNAPSHOT
Either you release A, you update B to use A released version, and you release B
Either you ask to release plugin to update B deps and release it.
(For me the main problem is often that if you need to release each time all projects at the same time, probably it should be a unique project)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release plugin snapshot dependency resolution
Posted by Jason van Zyl <ja...@sonatype.com>.
On Sep 29, 2010, at 11:25 AM, Brett Porter wrote:
>
> On 29/09/2010, at 11:57 PM, Jason van Zyl wrote:
>
>>
>> On Sep 29, 2010, at 9:50 AM, Brett Porter wrote:
>>
>>> Hi,
>>>
>>> The release plugin has a mode where it can assist you in updating snapshot dependencies at release time. A lot of this is better manipulated with the versions plugin now, but it seems a useful feature to have at release time if you can.
>>>
>>
>> I honestly don't know why this was ever added. Allowing people to leave snapshots in releases just leads to bad things.
>>
>> Exactly how does this work? In order for it to be reproducible you not only have to flip the snapshots to releases but if you ever gave this to a user you need to have a tag for what you're including. I don't think the support is that sophisticated and let's someone do a half-assed release that is likely not to be reproducible.
>>
>> Why don't we just remove this capability and simplify the process. Release all dependencies or you don't release. End of story.
>
> That's what it does - it still fails if there are snapshots. It gives you the option if it finds a snapshot to let you change that to a released version.
What's the use case here? You have a snapshot of log4j and there's a release version you can use?
POM says 2.0-SNAPSHOT but 2.0 is available?
> So rather than puking out, making you go and adjust the snapshot, then coming back and trying again, you can do it at the time when you type in the other versions.
>
> The weird bit is that it used to then flip the dependency back to a snapshot after the release, even though it's outside the project. I'm suggesting it change the default to keep it as the release you just pinned it to.
>
>>
>>> The previous behaviour was a bit weird, though. It would prompt you like this:
>>>
>>> Resolve Project Dependency Snapshots.: 'test:MRELEASE-583' set to release? (yes/no) yes: :
>>> What is the next development version? (2.1.3-SNAPSHOT) 2.1.3-SNAPSHOT: :
>>>
>>> The first question was redundant - you'd already said you wanted to update snapshots and the other option is failure. The second one assumes you'll be setting the snapshot to the equivalent release, then automatically to the next dev't version. The inflexibility of the first part was pointed out in MRELEASE-583 and I applied a change similar to the patch provided.
>>>
>>> However, I disagree with the default choice of updating the dependency to another snapshot - since this is outside of the reactor it's a better practice to pin to the release you just chose. I retained one exception for the use case where it was a more recent snapshot than the release you selected, and the original choice is restored.
>>>
>>> As it's only interactive and the form of the questions change, I don't think this will catch anyone by surprise, and encourages better practices.
>>>
>>> Does anyone see a downside?
>>>
>>> - Brett
>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://brettporter.wordpress.com/
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>> What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people.
>>
>> -- Paul Graham
>>
>>
>>
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
A language that doesn’t affect the way you think about programming is not worth knowing.
-— Alan Perlis
Re: Release plugin snapshot dependency resolution
Posted by Brett Porter <br...@apache.org>.
On 29/09/2010, at 11:57 PM, Jason van Zyl wrote:
>
> On Sep 29, 2010, at 9:50 AM, Brett Porter wrote:
>
>> Hi,
>>
>> The release plugin has a mode where it can assist you in updating snapshot dependencies at release time. A lot of this is better manipulated with the versions plugin now, but it seems a useful feature to have at release time if you can.
>>
>
> I honestly don't know why this was ever added. Allowing people to leave snapshots in releases just leads to bad things.
>
> Exactly how does this work? In order for it to be reproducible you not only have to flip the snapshots to releases but if you ever gave this to a user you need to have a tag for what you're including. I don't think the support is that sophisticated and let's someone do a half-assed release that is likely not to be reproducible.
>
> Why don't we just remove this capability and simplify the process. Release all dependencies or you don't release. End of story.
That's what it does - it still fails if there are snapshots. It gives you the option if it finds a snapshot to let you change that to a released version. So rather than puking out, making you go and adjust the snapshot, then coming back and trying again, you can do it at the time when you type in the other versions.
The weird bit is that it used to then flip the dependency back to a snapshot after the release, even though it's outside the project. I'm suggesting it change the default to keep it as the release you just pinned it to.
>
>> The previous behaviour was a bit weird, though. It would prompt you like this:
>>
>> Resolve Project Dependency Snapshots.: 'test:MRELEASE-583' set to release? (yes/no) yes: :
>> What is the next development version? (2.1.3-SNAPSHOT) 2.1.3-SNAPSHOT: :
>>
>> The first question was redundant - you'd already said you wanted to update snapshots and the other option is failure. The second one assumes you'll be setting the snapshot to the equivalent release, then automatically to the next dev't version. The inflexibility of the first part was pointed out in MRELEASE-583 and I applied a change similar to the patch provided.
>>
>> However, I disagree with the default choice of updating the dependency to another snapshot - since this is outside of the reactor it's a better practice to pin to the release you just chose. I retained one exception for the use case where it was a more recent snapshot than the release you selected, and the original choice is restored.
>>
>> As it's only interactive and the form of the questions change, I don't think this will catch anyone by surprise, and encourages better practices.
>>
>> Does anyone see a downside?
>>
>> - Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://brettporter.wordpress.com/
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people.
>
> -- Paul Graham
>
>
>
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Release plugin snapshot dependency resolution
Posted by Jason van Zyl <ja...@sonatype.com>.
On Sep 29, 2010, at 9:50 AM, Brett Porter wrote:
> Hi,
>
> The release plugin has a mode where it can assist you in updating snapshot dependencies at release time. A lot of this is better manipulated with the versions plugin now, but it seems a useful feature to have at release time if you can.
>
I honestly don't know why this was ever added. Allowing people to leave snapshots in releases just leads to bad things.
Exactly how does this work? In order for it to be reproducible you not only have to flip the snapshots to releases but if you ever gave this to a user you need to have a tag for what you're including. I don't think the support is that sophisticated and let's someone do a half-assed release that is likely not to be reproducible.
Why don't we just remove this capability and simplify the process. Release all dependencies or you don't release. End of story.
> The previous behaviour was a bit weird, though. It would prompt you like this:
>
> Resolve Project Dependency Snapshots.: 'test:MRELEASE-583' set to release? (yes/no) yes: :
> What is the next development version? (2.1.3-SNAPSHOT) 2.1.3-SNAPSHOT: :
>
> The first question was redundant - you'd already said you wanted to update snapshots and the other option is failure. The second one assumes you'll be setting the snapshot to the equivalent release, then automatically to the next dev't version. The inflexibility of the first part was pointed out in MRELEASE-583 and I applied a change similar to the patch provided.
>
> However, I disagree with the default choice of updating the dependency to another snapshot - since this is outside of the reactor it's a better practice to pin to the release you just chose. I retained one exception for the use case where it was a more recent snapshot than the release you selected, and the original choice is restored.
>
> As it's only interactive and the form of the questions change, I don't think this will catch anyone by surprise, and encourages better practices.
>
> Does anyone see a downside?
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people.
-- Paul Graham