ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <gscok...@gmail.com>
Subject RE: ivy and jars in war or ear
Date Fri, 20 Apr 2007 12:25:43 GMT
Thanks matthias,

The nomenclature that you propose is nice.  I like it.

What you propose is exactly what I want to do...  except that I don't want
to place all jars in the ivy.xml of the war.

The reason is that I have also ivy.xml for each jars.  And if someone adds a
dependency to one of this jar, I want to have it added automatically in the
war or in the ear (depending on the type of filtering I placed) without
having to update the ivy.xml of the war.

When you take this requirements, the solution you propose is not sufficient
anymore.

Do you see?

Gilles

> -----Original Message-----
> From: Matthias Kilian [mailto:kili@outback.escape.de]
> Sent: vendredi 20 avril 2007 14:02
> To: ivy-user@incubator.apache.org
> Subject: Re: ivy and jars in war or ear
> 
> On Fri, Apr 20, 2007 at 01:25:26PM +0200, Gilles Scokart wrote:
> > I would like to place the knowledge of which jars to include in the war
> (or
> > in the ear) at the level of the ivy.xml of the wars.  The idea is that
> the
> > wars should have two configurations: 'war_libs' and 'ear_libs'.  But it
> is
> > not easy to achieve...
> 
> So you've one ivy.xml for the ear and one for each war, and the
> ear's ivy.xml depends on the war's ivy.xmls, right?
> 
> > My problem is that I don't want to place all jars in the ivy.xml of the
> > wars.
> 
> Why? Using the two different configurations seems to be fine, e.g.
> 
> - "war_libs": all libraries to include into the war.
> - "ear_libs": libraries to put into the ear *and* probably to put into
>    the CLASSPATH when compiling the war's classes.
> 
> For a better nomenclatura, you could also use
> 
> - "assembly" (private) : libraries to include into the war.
> - "runtime" (public): additional libraries (for the ear). The artifact
>   (war file) itself should also use this configuration.
> - "compile" (private): more libraries required to compile your sources,
> e.g.
>    jms.jar, xml-apis.jar, or just j2ee.jar.
> 
> Then, retrieve all of those configurations at once and use a retrieve
> pattern like lib/[conf], and you end up with lib/assembly, lib/runtime
> and lib/compile.
> 
> For the ear, you could use the same naming scheme with an configuration
> mapping "assembly -> runtime" for all the war dependencies. This
> way you'll get all the wars and their "external" libraries into
> lib/assembly of the ear build directory.
> 
> Benefits:
> 
> - unique configuration scheme, independent of wether you're building
>   wars, ears or whatever.
> - simple build scripts (just include lib/assembly/* when assembling your
>   archive, and lib/runtime/* and lib/compile/* when compiling).
> 
> Also, for generating the manifest, this may simplify things. I don't
> have a solution for this at hand, but I've seen solutions in the
> past where you just create classpath entries for all files contained
> in a single directories.
> 
> Ciao,
> 	Kili


Mime
View raw message