Mark Hobson wrote:
On 22/06/07, Brett Porter <[EMAIL PROTECTED]> wrote:
It's never been an alternative, but it was implemented as "newest
wins" in an early alpha.
Curse the person who switched to nearest! ;)
:)
It should be nearest though, with a fallback to newest if there are 2
nodes at the same depth. I think it's random right now.
> How would anyone select a different strategy? This would require a
> change to the POM to even turn on any alternatives. Even if the API
> for the resolution was completely hidden something fundamental
> would have to change i.e. the POM in order to activate it. No?
Yes, I think it'd require a POM change to activate, so I'm more in
favour of it being a starting point in 2.1.
As mentioned above, this requires a change in the Maven installation
rather than the POM. Obviously far from ideal, but I'm happy to live
with this for the huge gain in productivity.
Yup, you don't need to change the pom, you can just use either extensions
to plug in alternatives, or use the plugin framework, which is _the_ way
to configure builds, though it doesn't allow for pre-reactor execution atm,
but that could be made to work without pom changes, though i'd favour some
plugin
configuration outside the <build> tag for that since this effects resolution
and is not necessarily used by maven to build stuff, but can be used by other
applications
to compute a graph.
Basically, use <extensions><extension> and add a <configuration> section to it
would work?
Btw, since plugging in alternatives affects the entire graph, I wonder what will
happen if some random module changes the defaults... they're obviously not
meant to
apply to the entire graph, but a sub-graph. I can imagine that some transitive
dep
would specify a conflicting resolution scheme, and I wonder if that could cause
problems.
Perhaps this should/could be reactor-global - add some special commandline
parameters to tune
maven, much like the -javaagent args that 'tune' the jvm.
For instance, '--dep-version-conflict-resolution nearest,newest',
which looks for an artifact in a predefined groupId with
dep-version-conflict-resolution-<XXX> ?
Or, if we do this in 2.1, we can use the api/impl mechanism in a pom/reactor
global way,
outside of build.
Just throwing this out here - it's been discussed offline now and then and
we've got
a place reserved for this in the wiki, but there are too much options to choose
from
to really write something ;)
-- Kenney
[snip]
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
