Cool,

how do you avoid the following situation though.

subproject1 depends on commons-logging-1.1.jar
subproject2 depends on commons-logging-1.0.jar

The latter is an accident because I forgot to update subproject2's
dependencies. I was hoping Ivy could help me in the deployment process and
warn me if my subprojects refer to different versions of the same artifact.

 Roger

On Dec 19, 2007 8:27 PM, Phillip Rhodes <[EMAIL PROTECTED]> wrote:

> Roger Kapsi wrote:
>
> > And I want to tell Ivy or rather Ant to give me C and all its
> > dependencies. In other words I want to get C.jar, B.jar, A.jar and all
> > the other external Jars. Hope somebody can give me a hint how to do
> > that or am I on the wrong track with Ivy?
>
> There may be a cleaner way, but here's what I do:
>
> 1. in each sub-project, resolve the dependencies to the local "lib" dir
> with configurations separating the dependencies that are needed at
> runtime from the ones that arent'. So I wind up with something like
>
> /myproject/subproject1/lib
>                        /core/
>                           ajar.jar
>                           bjar.jar
>                        /compile/
>                           compileonly1.jar
>                           compileonly2.jar
>
>
> 2. in the "package" task for each sub-project (it probably more properly
>  belongs in "publish" but I'm still tweaking this) copy all of the
> "runtime" jars (the "core" directory) to a common dir
>
> so I have something like this:
>
> /myproject/
>    subproject1/
>    subproject2/
>    subprojectN/
>    commonlib/ :this contains all the dependent jars for all subprojects
>
> 3. then in the "master" project I just declare dependencies on the
> artifacts from the subprojects like normal and resolve them to a dir
> I call "assemble."  The I copy everything from the commonlib dir into
> the "assemble" dir and package it.  In my case the subprojects are
> typically building war files or ejb-jar files and the driver builds
> an ear, but the same approach could be used for other things I guess.
>
> Again, there might be a better way, but this seems to work for now.
> HTH.
>
>
> TTYL,
>
>
> --
> Phillip Rhodes
> Chief Architect - OpenQabal
> https://openqabal.dev.java.net
>

Reply via email to