ivy and jars in war or ear

[Gilles Scokart <gs...@gmail.com>]

Hi,

I have a web application with multiple jars.  Some jars are included
directly in the wars, but some are placed in the ear itself.

I would like to find an elegant solution using ivy and ant to :
- package the wars with the correct libs
- generate the classpath to be placed in the MANIFEST.MF of the wars
- package the ear with the correct libs


Currently, I have a rather complex implementation.  It uses ivy to retrieve
the list of dependencies, then filtering only the one that are required at
each level using antcontrib to plays with some properties (I put the
knowledge of where to place each jar in a property file).

I would like to simplify that.

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...

My problem is that I don't want to place all jars in the ivy.xml of the
wars.  I just want to put some top level one, and add a filter to say which
one should be kept in the war, or which one should be placed in the ear.  In
my case, I want to keep the jar produced in my company in the war, and place
the others in the ear.

Did you have any idea on how to do that elegantly?  


My second problem is to generate theclasspath of the manifest.mf of the war.
Currently, I have to play with antcontrib.  I iterate on all jar of the
dependency (that are placed in the ear and that are dependencies of the
war), and I create variable containing the classpath.  Could it be simpler?
Do we miss something in ivy or ant to do that?



Thanks for your suggestions,
Gilles

RE: ivy and jars in war or ear

[Gilles Scokart <gs...@gmail.com>]

I had already thought to this approach.  If you do that, the knowledge of
where the jar should be located is in the ivy.xml of the jars.  Which is
something I would like to avoid.

Gilles

> -----Original Message-----
> From: Matthias Kilian [mailto:kili@outback.escape.de]
> Sent: vendredi 20 avril 2007 16:12
> To: ivy-user@incubator.apache.org
> Subject: Re: ivy and jars in war or ear
> 
> On Fri, Apr 20, 2007 at 02:25:43PM +0200, Gilles Scokart wrote:
> > 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.
> 
> Just to be sure I understand your problem correctly: you've some
> internally developed libraries (that you want to go into the wars),
> that *may* depend on other interal stuff (also to go into the wars)
> and external (e.g.  apache) stuff, which you want to go into the
> ear.
> 
> If this is the case, *and* if the decision internal/external can
> be made in the ivys of the internal libraries (not in the wars and
> not in the ear), it may be possible to use three runtime-like
> configurations instead of one:
> 
> - runtime-internal: additional libraries from your SW dept.
> 
> - runtime-external: additional libraries from 3rd party (e.g. apache
>   stuff). Artifacts that should be considered external from an ear's
>   point of view (i.e. your war files) should also use this
>   configuration. [yes, now the naming becomes strange again, but don't
>   have a better idea for now]
> 
> - runtime: extends runtime-internal and runtime-external.
> 
> 
> For dependencies in your war's ivys, something like
> conf="runtime -> #(runtime); compile->runtime"
> may be used, but i'll have to check this.
> 
> I'll try to write some sample ivys later this day or next weekend
> and test wether this actually works.
> 
> Ciao,
> 	Kili

Re: ivy and jars in war or ear

[Matthias Kilian <ki...@outback.escape.de>]

On Fri, Apr 20, 2007 at 02:25:43PM +0200, Gilles Scokart wrote:
> 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.

Just to be sure I understand your problem correctly: you've some
internally developed libraries (that you want to go into the wars),
that *may* depend on other interal stuff (also to go into the wars)
and external (e.g.  apache) stuff, which you want to go into the
ear.

If this is the case, *and* if the decision internal/external can
be made in the ivys of the internal libraries (not in the wars and
not in the ear), it may be possible to use three runtime-like
configurations instead of one:

- runtime-internal: additional libraries from your SW dept.

- runtime-external: additional libraries from 3rd party (e.g. apache
  stuff). Artifacts that should be considered external from an ear's
  point of view (i.e. your war files) should also use this
  configuration. [yes, now the naming becomes strange again, but don't
  have a better idea for now]

- runtime: extends runtime-internal and runtime-external.


For dependencies in your war's ivys, something like
conf="runtime -> #(runtime); compile->runtime"
may be used, but i'll have to check this.

I'll try to write some sample ivys later this day or next weekend
and test wether this actually works.

Ciao,
	Kili

RE: ivy and jars in war or ear

[Gilles Scokart <gs...@gmail.com>]

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

Re: ivy and jars in war or ear

[Matthias Kilian <ki...@outback.escape.de>]

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