Leo,
I think you worry too much. There would be no use of the word Pico in the codebase of
exCornerstone. PicoContainer does not need .xinfo, so no changes there.
"avalon-interop" not needed. There is no automanted tool in teh works. This will be a
hand crafted
effort.
I don't think you need to worry about Avalon users using the constructor directly.
Pico users will
have to just accept that there might be changes.
- Paul
--- Leo Simons <[EMAIL PROTECTED]> wrote: > Paul Hammant wrote:
> > Would anyone mind if I added PicoContainer compatability to the ConnectionManager,
> ThreadManager
> > etc components formerly known as Cornerstone?
>
> you mean addition of various classes like
>
> ConnectionManagerBean extends DefaultConnectionManager
> {
> public PicoConnectionManager( /* ... stuff goes here ... */ )
> {
> /** ... stuff goes here ... */
> }
> }
>
> right?
>
> No problem with that per se. I think its an elegant idea and providing
> some support for it would be nice, but there some potential issues to
> remove first. IIUC, adding a new dependendency to
> DefaultConnectionManager would mean that this ConnectionManagerBean its
> constructor would need to change too. Which means we should be willing
> to maintain it. Makes one wonder:
>
> - Who is going to maintain that? (only possible good answer: the same
> people that work on cornerstone)
>
> - Is it possible to automate this maintainance? If so... is it already
> implemented? Who will implement it? Where will that stuff live?
> (possible answer: there's a maven-pico-avalon-interop plugin that
> generates the class based on the @avalon.dependency attributes over at
> picocontainer.org)
>
> - Are we willing to track PicoContainer developments? (iow what is the
> vector of change for the constructor argument concept and is that
> acceptable to us)
>
> - What about backwards compatibility issues where people who just use
> this stuff as beans depend on the signature of the constructor? (this
> worries me the most. Adding a dependency might mean code changes to
> client code.)
>
> maybe it makes sense to do this on a branch first? I don't really feel
> like adding these classes, releasing, reconsidering, and then alienating
> users.
>
> > Thoughts?
>
> like the idea, but some reservations :D
>
> - LSD
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
________________________________________________________________________
Want to chat instantly with your online friends? Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
