RE: Re: [picocontainer-dev] FW: [picocontainer] [3121] java/nanocontainer-nanowar/trunk: Split nanowar into core and separate modules for each framework supported.

Mauro Talevi wrote on Wednesday, December 20, 2006 6:59 PM:

> Jörg Schaible wrote:
> 
>> 
>> Basically I was never a friend of the
> one-artifact-contains-all, but I did not care too much about.
>> 
> 
> It has its pros and cons - IMO one needs to balance them and
> take a position on a case-by-case basis.
> 
>> You don't have to convince me, ... convince Paul ;-)
> 
> Done ;-)

Nice to have Paul on board :)

>> Yep, but the other way round. We have the same issue for
> the other nano-projects and it already starts in
> nanocontainer itself. Currently any dep is optional (AOP,
> Groovy, Bsh, Jython, ...) and you don't really have a clue,
> which dep is even transitive. I understand Paul's point that
> it should be easy to download the complete stuff at once, but
> nobody stops us from preparing a binary distribution artifact
> that assembles all the jars into a single download. And this
> might contain all the "ready to release" artifacts from all nano
> projects. 
> 
> Yep - that is true.  The uberjar approach cannot tell which
> deps are required by which embedded lib.
> Although, in the case of nanocontainer itself, one may argue
> that it is possible that a user
> requests more than one library it depends on (eg two
> different types of scripts, groovy and xml) at
> the same time.
> 
> Borderline case I think - could be argued either way.

Well, how often do you use two of those at same time? And if you do, then it is no problem to declare two deps ... or?

- Jörg

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

    http://xircles.codehaus.org/manage_email