On 21 Jun 07, at 2:55 AM 21 Jun 07, Mark Hobson wrote:
On 18/05/07, Brett Porter <[EMAIL PROTECTED]> wrote:
As it turned out, we didn't talk about the artifact resolution
mechanism in great detail. Jason told us he is working on a paper to
describe how it might be re-implemented in 2.1.
Jason, any chance you could push what you have into SVN so we can
provide some feedback and see how it might line up with Mark's work?
If it is compatible, and the patch is good, then we could apply that
to trunk now.
Either way, I don't think applying this on 2.0.x is a good move. We
have to draw the line about new features getting added there.
I'd like to reach a consensus on whether we can include MNG-612 in
2.0.8. It's currently scheduled for 2.1.x, which means that it will
be superseded by the dependency graph code we've been discussing on
another thread. It's also a long way off, since this is still in the
specification stage and no code has been committed yet.
I don't think this makes sense to add to 2.0.x as we have to 1)
provide a way to load these strategies which is taken care of in 2.1,
and 2) people will implement them in 2.0.x and then expect them to
work in 2.1 which they won't because it will be graph-based in 2.1. I
think everyone agrees that will happen. And though the issue has been
voted on, how many people are desperate for this now that MNG-1577
has been implemented.
The patch attached to MNG-612 works with the current 2.0.x
architecture and simply makes the conflict resolver pluggable, rather
than hardcoded as it is now.
Technically this is not a problem. The problem is exposing the API
near the end of 2.0.x active development and then having to support
this later on.
This issue has 13 votes which, if
targeted for 2.0.x, would make it the third most voted for issue for
2.0.x. Seeing as the patch is pretty non-destructive and the work is
ready to go, are there any good reasons to veto MNG-612 being included
in 2.0.8?
API exposure, and mechanism for loading the strategies are problems.
I don't think it would be wise to promote this at this point in 2.0.x.
Cheers,
Mark
---------------------------------------------------------------------
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]
