On Sat, 19 Mar 2005, Adam R. B. Jack <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
