|
»
»
»
wagon API upgrades
|
View:
New views
6 Messages
—
Rating Filter:
Alert me
|
 |
wagon API upgrades
by brettporter
::
Rate this Message:
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@... http://blogs.exist.com/bporter/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: wagon API upgrades
by Benjamin Bentmann
::
Rate this Message:
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@... For additional commands, e-mail: dev-help@... |
|
|
RE: wagon API upgrades
by Brian E Fox
::
Rate this Message:
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@...] 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@... http://blogs.exist.com/bporter/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: wagon API upgrades
by John Casey-5
::
Rate this Message:
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@...] > 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@... > http://blogs.exist.com/bporter/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --- 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
by Jason van Zyl-2
::
Rate this Message:
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@... > http://blogs.exist.com/bporter/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > 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@... For additional commands, e-mail: dev-help@... |
|
|
Re: wagon API upgrades
by brettporter
::
Rate this Message:
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@... http://blogs.exist.com/bporter/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
| Free Forum Powered by Nabble | Forum Help |