Mailing-List: contact directory-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List"
 <directory-dev@incubator.apache.org>
Subject: Re: SPAM[RBL] Re: SystemBackend.java Picoification
From: Jason van Zyl <jvanzyl@maven.org>
To: Apache Directory Developers List <directory-dev@incubator.apache.org>
In-Reply-To: <3FD04E58.4090802@ThoughtWorks.net>
References: <DKEHLBLNMNHHCEEIIIGOMEKGCAAA.vtence@pyxis-tech.com>
	 <3FCF1D7C.60803@ThoughtWorks.net> <3FCFA79B.8010302@apache.org>
	 <3FD04E58.4090802@ThoughtWorks.net>
Content-Type: text/plain
Organization: 
Message-Id: <1070644457.13047.288.camel@localhost.localdomain>
Mime-Version: 1.0
Date: 05 Dec 2003 12:14:17 -0500
Content-Transfer-Encoding: 7bit

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