In our case, we don't want the original range back exactly, we want the current version of that, ie, higher lower bound to currently released things.
Do not forget the transient ranges that need to be locked in our modified pom, either. Without this any tooling would be severely limited in use. Fred. On Tue, Oct 27, 2015 at 11:02 AM, Stephen Connolly < [email protected]> wrote: > The idea I had in versions-m-p was to put XML PI with the original range > beside the resolved value so that the range can be set back post prepare > (see completionGoals) > > Oh where is my elusive time > > On Monday 26 October 2015, Bernd Eckenfels <[email protected]> wrote: > > > Am Mon, 26 Oct 2015 13:03:03 -0400 > > schrieb Benson Margulies <[email protected] <javascript:;>>: > > > Do we have any tooling for this? In my imagination, the top pom for a > > > product to be released could be auto-decorated with > > > dependencyManagement locks. > > > > I think besides the release-with-pom from the release plugin but also > > versions:resolve-ranges: > > > > http://www.mojohaus.org/versions-maven-plugin/resolve-ranges-mojo.html > > > > Gruss > > Bernd > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] <javascript:;> > > For additional commands, e-mail: [email protected] > <javascript:;> > > > > > > -- > Sent from my phone >
