SPAM[RBL] Re: SystemBackend.java Picoification

[Paul Hammant <Pa...@ThoughtWorks.net>]

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).

- Paul


-- 
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...

Re: SPAM[RBL] Re: SystemBackend.java Picoification

[Jason van Zyl <jv...@maven.org>]

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

SPAM[RBL] Re: SPAM[RBL] Re: SystemBackend.java Picoification

[Paul Hammant <Pa...@ThoughtWorks.net>]

> If you post your question on dev@avalon I'll be more than
> happy to provide details.

Oh well we'll leave it then.

- Paul

-- 
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...

Re: SPAM[RBL] Re: SystemBackend.java Picoification

[Stephen McConnell <mc...@apache.org>]

Paul:

If you post your question on dev@avalon I'll be more than
happy to provide details.

Cheers, Steve.


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).
>
> - Paul
>
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org

|------------------------------------------------|
| Magic by Merlin                                |
| Production by Avalon                           |
|                                                |
| http://avalon.apache.org/merlin                |
| http://dpml.net/                               |
|------------------------------------------------|