Rationale of modules

[Harald Braumann <ha...@unheit.net>]

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.

Regards,
harry

Re: Rationale of modules

[Harald Braumann <ha...@unheit.net>]

On Wed, 27 Feb 2008 17:16:31 +0100
"Xavier Hanin" <xa...@gmail.com> wrote:

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

Re: Rationale of modules

[Xavier Hanin <xa...@gmail.com>]

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


>
> Regards,
> harry
>



-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

RE: Rationale of modules

["Fernandes, Gerard" <ge...@lehman.com>]

>so far I've only used maven which doesn't know modules, only artifacts.

That isn't really true, as is demonstrated by this very nice article:
http://www.javaworld.com/javaworld/jw-05-2006/jw-0529-maven.html

Gerard Fernandes
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

This message is intended only for the personal and confidential use of the designated recipient(s) named above.  If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited.  This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers.  Email transmission cannot be guaranteed to be secure or error-free.  Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such.  All information is subject to change without notice.