ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harald Braumann <ha...@unheit.net>
Subject Re: Rationale of modules
Date Wed, 27 Feb 2008 20:24:15 GMT
On Wed, 27 Feb 2008 17:16:31 +0100
"Xavier Hanin" <xavier.hanin@gmail.com> wrote:

> On Wed, Feb 27, 2008 at 5:06 PM, Harald Braumann <harry@unheit.net>
> 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.
> 
> Xavier

Right, thanks. I guess I see trouble where there isn't any.

Mime
View raw message