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
