maven-wagon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trygve Laugstøl <>
Subject Re: Support for Sessions and other planned changes in Wagon API
Date Tue, 17 Aug 2004 17:47:11 GMT
On Mon, Aug 16, 2004 at 10:39:06PM -0700, Michal Maczka wrote:
> Hey!
> I've seen the latest discussion regarding session in wagon. and ideas
> like "Plexus returning Map which hides the access to container".
> I've walk this path long ago in early days of wagon and I don't think it
> is a right way as it leads to nowhere
> There are three problems which we have to solve here:
> a) per lookup requires contextalizable lookup requires access to
> container and we don't want this

Why does a "per lookup" strategy require access to the container?

> b) how components are released (what  does " the magic Map" buy us here?)

I don't think anyone has been talking about needing the special map for
wagon. The biggest issue the special map is adding newly discovered
components to the existing map. I would like the map to have a release()
method on the map too for components that doesn't use the singleton
lifecycle. I don't know if a special plexus map would implement
java.util.Map but it would have about the same semantics.

> c) we need to support the concept of session in Wagon API

Indeed and thats the only problem that you are trying to solve, right?

> The simplest fix which I know is ... to come back to the old design
> which was used in
> Wagon before and was specially develop to  support all those
> requirements and to use WagonFactories
> Note that
> - not every class needs to be a component
> - Wagon is loosely modeled after JDBC API - Wagon corresponds to
> Connection, Wagon Factory to DataSource.
> Datasouce is the perfect candidate for component - connection is rather not.
> The same applies to WagonFactory and Wagon
> Once we have back WagonFactory classes (which will be plexus component)
> - any component willing to talk to repositories will
> use them for obtaining an instance of Wagon. They can be declared as any
> their dependencies - and WagonFactoryManager will give an access to all
> of them.

If you don't use plexus for discovery of wagons, how do you propose to
find all the available implementations?

> And a "Session" will be simply .....a wagon which stays connected to the
> repository until it is needed.
> Wagon (session) can  be closed at any place and any time without the
> whole problem of releasing it back to plexus.
> Wagon are by nature statefull and I think that any attempt which tries
> to decouple state from wagon is similar to an attempt
> to decouple state from JDBC connection - it is probably doable but it
> will result in something more complex then it needs to be.
> If somebody has  __simpler__ idea how to do this please let me know ASAP
> before I will go further will refactoring,
> Other thing which I already fixed is the way in which event dispatching
> was implemented.
> I needed to distinguish listeners which are active (can themselves
> generate evens and use wagon) and passive
> which are just consuming events and not changing the state.
> The idea is that "active" listeners can be only called once and they are
> not going to receive any notification about events
> which were generated by other listeners. So for example the listers
> which transfers MD5 Checksum file won't
> conflict with the listener which deploys SHA1 checksum and operation
> performed by both can be tracked down
> by third listener (e.g. "DEBUG" listener)
> Once I  am done with those change I will release wagon-alpha-2 which
> from my point of view will be
> feature complete. Then  I will  actualize docs and ... we can switch to
> beta release cycle
> Michal
> ----------------------------------------------------------------------
> Ateny 2004 w Internecie! >>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:


View raw message