ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: Rationale of modules
Date Wed, 27 Feb 2008 16:16:31 GMT
On Wed, Feb 27, 2008 at 5:06 PM, Harald Braumann <> wrote:

> Hi,
> so far I've only used maven which doesn't know modules, only artifacts.
> Thus I have a bit of trouble to understand the rationale behind
> modules and how to use them. I try to explain with a few examples.
> Example 1)
> Module B consists of 2 libs: some low level implementation
> B-lowlevel.jar and some high level API B-api.jar. Module A, which
> depends on B, will always get both artifacts. But what if A only wants
> to use B-lowlevel.jar? I could create different configurations for B,
> one with B-api.jar and one with B-lowlevel.jar only. But then I would
> have to anticipate all possible uses of B at creation time. This is
> easy in this case but there might be uncountable combinations in more
> complex modules. Somehow to me it feels that B is the wrong place to
> specify these possible combinations. What if B is a third party product
> and they didn't anticipate the usage without B-api.jar? The other
> possibility would be to use includes/excludes in A but that feels like
> a hack to me. Also it would pull in all dependencies of B-api.jar,
> although I only use B-lowlevel.jar.
> Example 2)
> Lets say B consists of B-core.jar and a couple of plug-ins
> B-plugin1.jar, B-plugin2.jar, ... These are loaded at run-time
> dynamically. Now if B-core and all plug-ins are in one module, A, which
> depends on B, would always get all plug-ins. But it might only need one
> or two. Whats the best way of implementing this? Put each plug-in in
> its own module? Use includes in A?
> As I see it, modules are a way of grouping dependent artifacts
> together, which is a good thing. But they also reduce
> flexibility as things, like dependencies, can only be specified for
> all the artifact in a module together. Maven OTOH doesn't have any way
> of grouping artifacts together, which is equally bad.
> The solution I tend to is to put each artifact in its own module and
> then create a virtual module to group them together. I would still need
> to use include statements to only select some of the artifacts, but at
> least I could specify things on a per artifact basis. Of course this
> contradicts the whole module concept of ivy, and thus again doesn't
> really feel right, when using ivy.

It doesn't really contradict the module concept of Ivy. You can see it as
you want and as it fits your needs. From my experience, you should use
module for case #1 and #2 as long as their size is manageable. If you fear
you will lack of flexibility, split your module, no problem. Using a virtual
module to ease the usage of your modules set is a good idea in this case.
And remember that you can use configurations in your virtual module to
address your most usual use cases.


> Regards,
> harry

Xavier Hanin - Independent Java Consultant

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message