On 6 Jun 07, at 11:28 PM 6 Jun 07, Brett Porter wrote:
On 07/06/2007, at 12:09 AM, Jason van Zyl wrote:
- we will have to retain runtime compatibility in 2.1, but not
necessarily API compatibility which is fine
For plugins yes, for sanity. Not any other APIs. Plugins using
older artifact APIs are not my concern for 2.1. Those plugins will
have to move forward if they want to take advantage of 2.1
features. Any of the project and artifact APIs should be
considered dead in 2.1 and work from the embedder api to improve
them.
A little confused about what you are saying. Are you saying they
won't be able to take advantage of 2.1, but will still run in 2.1
(using a 2.0.x execution context)? Or are you saying that they just
won't run in 2.1 and will have to be updated?
2.0.x plugins in the 2.0.x execution environment
2.1.x plugins in the 2.1.x execution environment
The execution of the plugins using the old components has to be
bridged for 2.0.x components. Plugin in 2.1.x to start will use the
embedder APIs. To contrast artifact resolution capabilities in both
major versions.
Given that, if Carlos has a use case for using the individual
packages instead of the embedder and can make incremental
improvements in line with that, I think we should look at it on a
case by case basis here and move forward.
But it's not in the card in the short term. As soon as we have
something we consider publicly consumable I'm all for it.
I'm not sure what you mean by "short term", but as I understood it
Carlos only wanted to ensure something was done for the 2.1 release.
Carlos alone will not be able to do it. Given all historical
precedent it's highly unlikely and as something we can offer the
community in terms of stability and usability the embedder API is the
most practical solution.
The only way we are going to get to something publicly consumable
is by working on it. If Carlos is able to propose and make
incremental changes towards that, then I don't see the problem. I
don't agree with the original changes made, but I do agree with the
need to move forward on a case by case basis towards the goals we
agree on from my previous mail.
As long as they are never supported publicly and that changes that
are made are not subject to compatibility concerns. Carlos alone
cannot decide and work on APIs which is why I suggest the embedder
API as the focus from which other APIs can fall out.
- 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]
