avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <paul_hamm...@yahoo.com>
Subject Re: exCornerstone components.
Date Mon, 23 Jun 2003 12:33:04 GMT
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 <leosimons@apache.org> 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: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>  

________________________________________________________________________
Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message