Here's a question:
Could we specify the wagon-webdav in the super-POM as a build
extension? Even if there are no project POMs in the current build,
the super POM should be built, right? Also, I would think (though I'd
have to investigate to be sure) that respecifying the wagon-webdav
build extension with a new version would override through
inheritance, working similarly to the way the pinned-down plugin
stuff is meant to work.
Obviously, the webdav stuff as it is today may not be a great
candidate for this sort of inclusion, but maybe this would be a
decent approach for the next release.
I'm still reading through this thread, but this just occurred to me
and I wanted to bring it up.
-john
On Mar 27, 2008, at 8:11 PM, Brian E. Fox wrote:
The other problem with dropping it into the distribution is that when
we find out there is a bug in it you can't simply specify a new
version of the provider, you would have to go replace the provider
and
all its deps, or make your own shaded JAR which would be a pain in
the
ass.
(see full thread here:
http://www.nabble.com/Wagon-changes-and-WebDAV-td15743343s177.html)
So the above captures exactly the problem we are seeing now. James has
an issue with webdav that may require a fix. This is probably an
existing issue and is not core so it shouldn't hold up the 2.0.9
release. The issue is that even if he finds and fixes it, there's
no way
to upgrade the extension until we do 2.0.10. This seems like it
could be
a bigger issue than what we've tried to solve, which is make
deploy:deploy-file slightly easier to use for one specific protocol.
Reading back over the thread, there seemed to be general consensus
that
this isn't the direction we wanted to go with the trunk, but that
2.0.x
wasn't as much of a concern. I think it should be still a concern
given
the potential to really lock people in. Furthermore this has a big
potential to cause regressions because now we just forced everyone to
upgrade their webdav even if they didn't want to...and there's nothing
they can do about it. That's not cool and I vote we take this out
before
minting 2.0.9. (I'm leaving it in for RC4 to allow time for discussion
and time for more testing of the RC)
--Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
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
