gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: CLASSPATH logic is failing on me
Date Mon, 21 Mar 2005 09:15:56 GMT
On Sat, 19 Mar 2005, Adam R. B. Jack <ajack@apache.org> wrote:

> I figured it meant "inherit that into this project", so things that
> depend upon cactus get it & it's inherited baggage. [Actually
> though, that is inherit="jars", isn't it?]

Uhm, no, not quite.  We've obviously overloaded inherit too much.  See
below.

> Still, have I been overthinking this algorythm all along? Are
> dependencies pretty much simply between the two parties, not (as I'd
> assumed) some cascade of all the dependencies (doing "inheritence"
> the whole tree down to the ground).

It seems so, yes.  At least the way dependencies worked in traditional
Gump (which is what I'm coming from with my interpretation) has been
far simpler than you thought.

> Meaning, do I (except for inherit="jars") not "recurse into the
> sub-dependency project" to get more dependencies?

You recurse for inherit="all" and inherit="runtime", you don't for "no
inherit attribute" or inherit="jars".  Again, see below.

> Is it really as simple as for a project one simply includes/resolves
> merely the explicit dependencies specifies (with inheritence), not
> going on to get what those projects use to build themselves?

Yes.

> I guess I suspected that parts of an API in a sub-jar (e.g. log4j)
> might bleed through a user (e.g. say axis) and so to compile an axis
> user one might need log4j?

It is unlikely to be a compile time dependency.  But if it is, then
that project (the one that depends on Axis and Log4J) is supposed to
say so.

> Ok, I'm going to try to re-work this. I might as well get it right
> here, before I look @ Gump3.

Good idea.  Let me again try to capture the dependency logic of
traditional Gump so that you can compare it to your picture.  Nothing
is set to stone and I'm happy to rework things as needed - but what I
describe here is the algorithm we used before, and the algorithm I
apply when I create/modify descriptors.

If you think this is useful and not-obvious from the current docs,
then I can create an xdoc from it and add it to the site.

Here we go.

Let's assume

<project name="A">
  <jar name="A.jar"/>
</project>
<project name="B-plain">
  <depend project="A"/>
  <jar name="B-plain.jar"/>
</project>
<project name="B-runtime">
  <depend project="A" runtime="true"/>
  <jar name="B-runtime.jar"/>
</project>
<project name="B-jars">
  <depend project="A" inherit="jars"/>
  <jar name="B-jars.jar"/>
</project>

When building any of the B-* projects, A is required.  A.jar is on the
CLASSPATH while building any of them.

In the case of B-jars, A.jar is considered part of B-jars' output
jars, hiding the dependency on A completely.

Now let's go one level deeper.

<project name="C">
  <depend project="B-plain"/>
</project>

Means no dependency on A at all, A.jar is not on the CLASSPATH.  Of
course if A doesn't build, B-plain won't build so C would still end in
a pre-req failed state - but there is no direct dependency at all.

If we change that to read

<project name="C">
  <depend project="B-plain" runtime="true"/>
</project>

nothing changes at all.  B-plain has no "runtime" dependencies.

And

<project name="C">
  <depend project="B-runtime"/>
</project>

doesn't change the picture either, since B-runtime's dependencies are
ignored.

Only with

<project name="C">
  <depend project="B-runtime" inherit="runtime"/>
</project>

C gets dependent on A and A.jar becomes part of the CLASSPATH.

You'd use this combination if you want to "run" B-runtime during the
build process of C and B-runtime cannot be run without A.  Like Ant's
<junit> task cannot be run without JUnit.  Or you can only build your
site with Anakia if velocity, jdom and friends are there.

Then we also have inherit="all".  For each of the three B-* projects

<project name="C">
  <depend project="B-*" inherit="all"/>
</project>

adds A.jar to the CLASSPATH and it creates a dependency on A directly.
inherit="all" is like importing the dependencies.  As a minor variant
we have inherit="hard" which is the same as inherit="all" but turns
<option> into <depend> on its way.

And the we finally have

<project name="C">
  <depend project="B-jars"/>
</project>

This time A.jar is on the CLASSPATH when we build C, but C does not
depend on A.  If inherit="all" imports the <depend> tags, then
inherit="jars" imports the <jar> tags.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message