On 22/06/2007, at 8:15 PM, 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! ;)
Sorry :(
At the time, the repository data (mostly converted from m1) wasn't
suited to it and you got things you didn't expect. I always expected
you'd be able to turn it on and manage the dependencies properly but
the implementation of that didn't happen.
> 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.
Can you pull this off through the <extensions> tag in the POM as
Kenney suggested? It seems reasonable, and if so, then I feel a
little more comfortable with it.
I don't really want to expose any functionality that requires a
customised Maven to run a project, though - that seems like we're
putting something in that will only be used by you :) It'll likely
break building other projects using that installation, or not being
able to build the projects on a different installation (Without hints
to help). If you're happy using a customised Maven, maybe you're best
building your own branch off the latest 2.0.x that includes the patch?
I'm still all for rolling it onto trunk and putting in example
projects that let us see this in action and help drive the use cases
for it going forward.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
