On Fri, 2003-12-05 at 04:22, Paul Hammant wrote:
> Stephen,
>
> >>>
> >> I like the style I have done as it reduces the jar bloat of a for
> >> users of teh frameworks in question. For example, Pico users would
> >> not like to see avalon-framework.jar as a requirement for using
> >> directory/ldapd
> >
> >
> >
> > This is a function of the container - for example, Merlin users don't
> > see avalon or merlin - they see services.
> >
> No sorry, I don;t understand. Could you elaborate a little. I am
> talking of using a directry component directly, without container (that
> Pico facilitatates) :
>
> class Foo {
> public static void main(string[] args) {
> Backend be = new PicoStyleDirectoryBackend( . . . . );
> be.doSomething().
> }
> }
>
> I'd rather not have Avalon-framework jars in the classpath (or those
> from merlin or phoenx, or loom etc).
I too would like to embed Eve inside Plexus but I don't mind having
other stuff on the classpath. I think you can take what I would call a
metadata rich component and wrap it so that it can easily be embedded as
a bean.
For me this need has arisen because I'm converting Werkflow into a set
of Plexus components but I realize others will want to embed it easily.
For me changing things on the fly is a requirement (the current hotswap
thing in pico doesn't help me) so using a container with the stuff I
need allows me to use Werkflow in Plexus but allows someone who didn't
require much sophistication to use it as a pico component.
I'm not convinced that pico is a solution that would ever be useful for
me and I don't think asking there be nothing on the class is reasonable.
As long as you can use Eve, Werkflow or anything else as an embeddable
bean I don't see a problem.
> - Paul
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
|