maven-wagon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trygve Laugstøl <trygv...@student.matnat.uio.no>
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! >>> http://link.interia.pl/f182d
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wagon-dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: wagon-dev-help@maven.apache.org
>

--
Trygve


Mime
View raw message