Issue Subscription
Filter: Design & Best Practices (24 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
> 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 poi
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
+1
On 29 September 2010 14: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 y
+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
