On 23 Jun 07, at 10:35 PM 23 Jun 07, Brett Porter wrote:
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.
For the branch if it was 100% non-invasive i.e did not interfere at
all with _anything_ setup currently, did not change the default
conflict resolver and was undetectable by the common user, and you
took responsibility and ownership of any problems that arise then I
would be fine with it going into the branch. If you are using the
existing APIs and not changing them _at all_ and just plugging in
your mechanism which works by altering your installation then I don't
see how this will affect any current 2.0.x users. You must also
express this new behavior with ITs and tests as the onus is on you to
make sure we can replicate the behavior but I don't think anyone can
promise anything vis-a-vis the code you use or the ultimate solution
in 2.1.
I can understand not wanting to use 2.1.x and that your solution gets
you where you need to be for 2.0.x. My only concern is that you don't
hose anything currently working. Any sort of conflict resolution
should be declarative and will be the case for 2.1.x. I don't think
it's overly useful in the trunk but put the code into both so they
stay in sync.
I'm fine with the additions as long as you take responsibility for
the changes. You'll have to wait a while as others may not be fine
with it so I'm sure you'll have a clear path this week sometime.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
