On 7 Sep 07, at 12:02 AM 7 Sep 07, [EMAIL PROTECTED] wrote:
Author: brett
Revision: 573485
Modified property: svn:log
Modified: svn:log at Fri Sep 7 00:02:24 2007
----------------------------------------------------------------------
--------
--- svn:log (original)
+++ svn:log Fri Sep 7 00:02:24 2007
@@ -1 +1,8 @@
move the wagon with the manager out to a branch
+
+As of this revision, the differences with the 1.x branch are:
+- API changes in the Wagon interface
+- resulting changes to events to add the repository parameters
+- inclusion of the wagon manager
+
+Ideally, the wagon manager would be ported to the Wagon 1.x trunk
without the breaking API changes
This is not ideally what should happen. I propose tossing the trunk
as the WagonManager should not be part of Wagon, here's my proposal
which I will post as part of next week. Wagon is far too complicated
and its concerns being mixed. It is sole for transport, not
management of the sources.
h3. Context
Wagon is starting to take on too much functionality, becoming too
complicated, and veering away from its intended goal of being a
simple transport provider.
These things should be in Wagon proper
* Mirrors
* Proxies (general proxies)
* WagonManager
* Authentication and Authorization should be abstract and should
really be the job of another system that is tied in
* Copying anything other then single files is not really the job of
Wagon. As we have found you need quite a bit of logic to actually
make directory copying
* Anything like stats should be taken from information provided by
events and should not be baked into Wagon
These things just make Wagon unmanageable and not what Wagon was
intended to be. These secondary concerns are not Wagon's concern and
should be dealt with in client code like Maven. Or even add-ons to
Wagon but not part of the core. The core is only concerned with
transport.
We should be focusing of things like:
* Session support for publishing and retrieval
* Pooling connections
* Betting event monitoring
* Integrity of transmission
* Proxy information should be localized to the provider. Knowledge of
SOCKs proxies for example is an HTTP thing primarily
* RepositoryPermissions is specific to file system based repositories
and is not applicable generally
h3. Solution
---------------------------------------------------------------------
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]
