On 20 Jun 07, at 11:47 AM 20 Jun 07, Joakim Erdfelt wrote:
Jason van Zyl wrote:
On 20 Jun 07, at 10:13 AM 20 Jun 07, Joakim Erdfelt wrote:
Be sure that this doesn't break forward compatibility too.
That approach would not allow for proper mirroring,
authentication propagation, network proxy usage, and short-
circuits the whole wagon manager approach of wagon 2.x
Why is there any concept of mirroring in Wagon.
You are basically deciding all this stuff on your own and making
changes based on what you need in Archiva.
That's nice.
But there's no mirroring in Archiva. Nor is there any need for it.
Archiva actually uses wagon 1.x, not wagon 2.x or the wagon-manager.
There's pretty much zero discussion surrounding all the changes
you are making and if you expect that to be absorbed into Maven
you're going to have a hard sell after what happened the last time
it was attempted. If the APIs are not compatible while the code is
improved I will be -1 on its inclusion in any version of Maven.
There is no reason the changes cannot be more gradual, and made to
work with 1.x, 2.0.x, 2.1.x.
Zero? Hardly.
The discussion for those changes were made in irc a full 5+ months
ago.
No it wasn't. I use IRC all the time and that doesn't bother me. You
talked in vague terms and then touched a ton of files. Like I told, I
wouldn't have cared at all if it worked. But it created a huge mess
because many things stopped working and not just for IDE integration
and the C Builds but some basic things like the listeners not being
attached at all which was a result of making radical changes that
didn't mesh at all with how it was being used. This is why I'm
worried about the changes.
Regrettably it was not discussed in an archived format, like here
in the mailing list.
We've all got this disease. We all have to resolve to change this
behavior.
I'm honestly not in favor of using something so divergent as it's
being driven by the use of one application, we'll have a hard time
getting it to work right in Maven and we're going to very much
screw Maven 1.x because we're yet again going to change/fix
everything on something completely different then what they using.
This is especially important now that Maven 1.1 is imminent.
The decision was made to ...
a) Consolidate the myriad of usages for wagon into a single point.
b) Not duplicate code within maven client + wagon + plugins to
accomplish the same task.
c) Give everyone a consistent interface, to get the full benefits
of authentication + mirroring + network proxying (which currently
is implemented differently with every usage of wagon)
d) Fix the numerous bugs present in wagon.
Direct usage of the wagon, not through the wagon manager, means a
lot less functionality than desired.
This is what Wagon was made for which is why the WagonManager was
always in Maven itself. The manager capability is nice, I agree,
but is not of prime importance in Wagon. The prime important is a
simple API for transport that works well for each of the
providers. I fear the API is going to get out of control like many
of our other APIs because the complexity of having this to work in
something like Archiva is going to pull in another kitchen sink.
I never proposed eliminating the direct wagon impl usage / use case.
Just make everyone that decides to use it that way aware that they
have *MORE* work ahead of themselves in order to be consistent with
wagon usage everywhere else in maven client.
- Joakim
---------------------------------------------------------------------
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]
