On 15/05/2008, at 12:22 AM, Benjamin Bentmann wrote:
If I don't misunderstand things, the same problems could arise some
day for
the AbstractMojo from the maven-plugin-api.
Yeah, though in that case there's a more direct tie between the
version of Maven and the plugin API than in this case. Need new API =
need new Maven. Also, Wagon has a lot more functionality in
AbstractWagon than AbstractMojo - but you're right that the scenario
is the same.
Anyway, +1 on decoupling implementation classes from the version of
the
Maven core. Keeping interfaces stable is hard enough, doing the same
for utility/convenience classes is not easier and may slow down
improvements.
Ok, I'll take a look at this after I'm done with the other 60 issues :)
On 15/05/2008, at 12:32 AM, Brian E. Fox wrote:
If we are filtering the interface from classloading...and the
interface
has changed, how does that enable the wagons to work with old Mavens?
Are you saying that the changes are backwards compatible already?
Yes - and Maven doesn't use the introduced APIs (yet). The main
concern is that fixed in the abstract wagon will not be exposed to new
wagons under the old one.
On 15/05/2008, at 12:56 AM, John Casey wrote:
I thought he said it was AbstractWagon that had changed, which may
provide protected methods, etc. that aren't in the interfaces...
Both changed, but that's the one that's clashing in the classloader,
yes.
At any rate, I think I agree with Benjamin, that we should try to
limit (or reduce) the number of AbstractThing super-classes that are
forced into the system by Maven. IMO, AbstractMojo is a problem
waiting to happen...I believe this to the point where, when I write
new plugins, they almost always implement Mojo instead of extending
AbstractMojo, just to try to future-proof them. These abstract
classes have been a real problem lately (thinking about the 2.0.9
release and maven reporting, specifically).
There are benefits to using AbstractThingy (you can add to the
interface without breaking implementations since you can provide a
default implementation), but having been reminded of these I agree
it's best they get kept out of Maven's core classloader.
In short, I'm +1 for separating them into -api and -impl, and
keeping abstract classes meant for third-party extension out of maven.
Cool, thanks for the second :)
Cheers,
Brett
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
