Re: [picocontainer-dev] annotations and comments on Pico2

Erik,
> Except the conceptual problem, not sure how much of a problem this  
> is in many systems. Just look at all the other projects that do  
> have annotations... EJB3, Hibernate, JSF, etc. I have not heard  
> this issue once. This dependency is no more than a classpath issue.
>

It is true that it is common.  Lots of my consulting in real life is  
about taking a client from one place to another with an existing  
codebase.  The story in http://paulhammant.com/blog/ 
branch_by_abstraction.html could be Hibernate to iBatis or iBatis to  
Hibernate.  Either way the path is more difficult the more of the  
framework that you have to implement/extend/throw. The further from  
POJO you are the greater the lockin.  PicoContainer pledges to lock  
in the smallest possible degree.  We have a Lifecycle interface from  
1.0 that has start and stop as methods. They amount to lock in and  
we're kinda regretful of that. But until Sun gives us  
java.lang.Lifecycle we can't drop our own one. Nor can container  
makers converge on it.

We find that people have more components themselves than logic that  
is container/framework glue to assemble/compose them.

Thus Annotations are another form of lock-in and we're not about  
that :-) We want to make it easy for people to ditch PicoContainer,  
not curse our parentage as they try to do so for another framework.

> I'd be interested to know in real systems what kind of use case  
> would show a real problem with such a classpath dependency.
>
>> They are compiled into classes and can not be
>> changed afterwards. This can be solved by second
>> externalisable configuration system - and what value
>> do they have afterwards?
> Less typing + declarative configuration. What I care the most in  
> the end is the code quality. If I can have something easy to  
> maintain, test and understand then it saves me time. It seemed  
> quite obvious to me that having something like @Singleton (and  
> other class level annotations):
> - you don't even need to know about ComponentAdapters (I don't find  
> this an obvious concept when you start with pico)

CAs are irrelevant to most users of PicoContainer.

> - you can have that element of configuration attached to the class  
> instead of a configuration "block" somewhere else in the code
> Yes in the end you need to attach a jar file to your code and  
> always have it in your project. You also will need to deal with  
> classloading. Other projects such as Tapestry IoC have solved most  
> of these issues and they achieve IMO very nice end user code.



>
> All this annotation stuff make my work easier - many other people  
> seem to believe so but I somehow feel I'm wasting my time trying to  
> contribute.

We'll I've pushed in annotations support...

    pico = new DefaultPicoContainer(new  
AnnotationsComponentAdapterFactory());
    pico.addComponent(Foo.class, FooImpl.class);
    pico.addComponent(Bar.class, BarImpl.class);

I chatted with Peter Royal* last night about adding (optional) the  
follow syntax for any injection type (incl constructor / setter as we  
always used to have it)....

    pico.addComponent(Foo.class, FooImpl.class).with(HIDING);
    pico.addComponent(Bar.class, BarImpl.class).as(SINGLETON);

So we're getting close to targets for low lines of code, without  
mandatory annotations and lock in.

* Unfortunately drink was involved in one of San Francisco's few  
English bars, so much has been forgotten from the conversation.

And you've not wasted your time, you've pushed us to do more to  
please more :)

- Paul


>
> Erik.
>


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email