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

Hi Mauro,

Mauro Talevi wrote on Wednesday, December 20, 2006 11:59 AM:

> Jörg Schaible wrote:
>> Well, it seems we're back were we started ....
> 
> Well, yes and no ... maybe ... sorta :-)
> 
> Unfortunately, as we working with Mike on finishing the m2
> build and it became clear that we were up
> against the wall.

I knew that, hehehe

[snip]

Basically I was never a friend of the one-artifact-contains-all, but I did not care too much about.

[snip]

> - the transitive dependency in m2 now make it just a easy (or
> even easier) to use nanowar with a
> single dependency call.  Eg if I want to use nanowar with
> WW2, I simply declare
> 
>          <dependency>
>              <groupId>org.nanocontainer</groupId>
>              <artifactId>nanocontainer-nanowar-webwork2</artifactId> 
> </dependency> 
> 
> which know all it needs to know about the WW2-related
> dependencies. Compare this with the need to
> declare
> 
>          <dependency>
>              <groupId>org.nanocontainer</groupId>
>              <artifactId>nanocontainer-nanowar</artifactId>         
> </dependency> 
> 
>          <dependency>
>              <groupId>opensymphony</groupId>
>              <artifactId>xwork</artifactId>
>          </dependency>
> 
>          <dependency>
>              <groupId>opensymphony</groupId>
>              <artifactId>webwork</artifactId>
>          </dependency>
> 
> 
> etc etc ...
> 
> Typically, one uses the *one* framework of choice at a time,
> be it struts, WW or other.

You don't have to convince me, ... convince Paul ;-)

> 
> - we can still have a m2 module - call it
> nanocontainer-nanowar-all - which includes all the nanowar
> modules.  Either as a simple POM that declares all the
> nanowar modules as dependencies or we can
> merge together the jars into a uberjar.  So the end product
> can still be the same, although the
> intermediate factors are not.
> We can also have a distribution/assembly of all jars into a
> downloadable zip. 

Deps are enough, otherwise you get troubles again with transitive deps of apps using our stuff.

> - building the examples in m2 was also much cleaner in this way.
> 
> Given the above, does anybody foresee any real problem with
> current setup?

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.

- Jörg

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

    http://xircles.codehaus.org/manage_email