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

Yup, I'm on board with multiple jars.  It is a double edged sword  
though as Mauro says.

- Paul

On Dec 20, 2006, at 7:58 AM, Mauro Talevi wrote:

> 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 ;-)
>
>> 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.
>
> Cheers
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>    http://xircles.codehaus.org/manage_email
>


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

    http://xircles.codehaus.org/manage_email