You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brett Porter <br...@apache.org> on 2008/05/14 14:29:15 UTC
wagon API upgrades
Hi,
I'm running through the issues in Wagon to get towards another
release. On trunk there are already a couple of changes to the
AbstractWagon. In doxia-like fashion, this prevents being able to use
a new wagon with existing versions of Maven, because they use code in
AbstractWagon (which is hidden by Maven via provider-api).
The options then are
- to push these implementation changes into a new module (thinning the
API down do just the interfaces) that is not filtered by Maven
- require a new version of Maven that updates the wagon api and/or
filters only the interfaces from classloading
Given that the first is a bit of an obtuse separation for this
purpose, and that the current providers have been stable for a year
and a half - I'm opting for the second one.
Any other thoughts on this?
- Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: wagon API upgrades
Posted by John Casey <jd...@commonjava.org>.
I thought he said it was AbstractWagon that had changed, which may
provide protected methods, etc. that aren't in the interfaces...
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).
In short, I'm +1 for separating them into -api and -impl, and keeping
abstract classes meant for third-party extension out of maven.
-john
On May 14, 2008, at 10: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?
>
> -----Original Message-----
> From: Brett Porter [mailto:brett@apache.org]
> Sent: Wednesday, May 14, 2008 8:29 AM
> To: Maven Developers List
> Subject: wagon API upgrades
>
> Hi,
>
> I'm running through the issues in Wagon to get towards another
> release. On trunk there are already a couple of changes to the
> AbstractWagon. In doxia-like fashion, this prevents being able to use
> a new wagon with existing versions of Maven, because they use code in
> AbstractWagon (which is hidden by Maven via provider-api).
>
> The options then are
> - to push these implementation changes into a new module (thinning the
> API down do just the interfaces) that is not filtered by Maven
> - require a new version of Maven that updates the wagon api and/or
> filters only the interfaces from classloading
>
> Given that the first is a bit of an obtuse separation for this
> purpose, and that the current providers have been stable for a year
> and a half - I'm opting for the second one.
>
> Any other thoughts on this?
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
RE: wagon API upgrades
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
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?
-----Original Message-----
From: Brett Porter [mailto:brett@apache.org]
Sent: Wednesday, May 14, 2008 8:29 AM
To: Maven Developers List
Subject: wagon API upgrades
Hi,
I'm running through the issues in Wagon to get towards another
release. On trunk there are already a couple of changes to the
AbstractWagon. In doxia-like fashion, this prevents being able to use
a new wagon with existing versions of Maven, because they use code in
AbstractWagon (which is hidden by Maven via provider-api).
The options then are
- to push these implementation changes into a new module (thinning the
API down do just the interfaces) that is not filtered by Maven
- require a new version of Maven that updates the wagon api and/or
filters only the interfaces from classloading
Given that the first is a bit of an obtuse separation for this
purpose, and that the current providers have been stable for a year
and a half - I'm opting for the second one.
Any other thoughts on this?
- Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: wagon API upgrades
Posted by Jason van Zyl <ja...@maven.org>.
On 14-May-08, at 5:29 AM, Brett Porter wrote:
> Hi,
>
> I'm running through the issues in Wagon to get towards another
> release. On trunk there are already a couple of changes to the
> AbstractWagon. In doxia-like fashion, this prevents being able to
> use a new wagon with existing versions of Maven, because they use
> code in AbstractWagon (which is hidden by Maven via provider-api).
>
> The options then are
> - to push these implementation changes into a new module (thinning
> the API down do just the interfaces) that is not filtered by Maven
> - require a new version of Maven that updates the wagon api and/or
> filters only the interfaces from classloading
>
What about maintaing binary compatibility? You've made changes as
opposed to pure additions?
> Given that the first is a bit of an obtuse separation for this
> purpose, and that the current providers have been stable for a year
> and a half - I'm opting for the second one.
>
> Any other thoughts on this?
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
We all have problems. How we deal with them is a measure of our worth.
-- Unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: wagon API upgrades
Posted by Brett Porter <br...@apache.org>.
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
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: wagon API upgrades
Posted by Benjamin Bentmann <be...@udo.edu>.
Brett Porter wrote:
> In doxia-like fashion, this prevents being able to use a new wagon with
> existing versions of Maven, because they use code in AbstractWagon (which
> is hidden by Maven via provider-api).
If I don't misunderstand things, the same problems could arise some day for
the AbstractMojo from the maven-plugin-api.
> - to push these implementation changes into a new module (thinning the
> API down do just the interfaces) that is not filtered by Maven
Such as separation exists already for maven-reporting-api and
maven-reporting-impl so this approach doesn't seem that odd.
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.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org