Stefan Thanks for your continued patience and assistance, I really appreciate it.
> > 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. I was trying to say ... for the project we are building: go get it's dependencies (respecting all/runtime), but once "inside" those dependencies don't get their sub-dependencies. (As such, I've stopped recursion for "all" or "runtime" unless depth=1 ... i.e. the current project). I don't quite follow, don't for "jars". Why not? "jars" is used (in the main) as an alias, it seems. As such we seem to want to "pass though" that project (almost as if it weren't there), so go get sub-dependencies. Do you mean 'noclasspath'? I've not see an "no inherit attribute". > > 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. > Cool. > > 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. Given what you are telling me, how would it "say so"? What would allow it to export on of it's dependencies? > 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. I do believe it probably ought be changed, (perhaps as you said for the 'overload'.) That said, let's get it right, as best possible, and go from there. BTW: Given the way that Gump2 works I don't think it is easy to "take the jars and break the dependency", and things like that. Dependency and Classpath are related, but separate things. Gump2 simply walks the dependency tree and forms a list for the classpath and caches it on the object. From what I know now, I'd rather calculate things project by project (at one time) not in some recursive loop. Perhaps Gump3 can do that. > 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. I think it is a good re-iteration. Clearly I read far more than there was between the lines, so perhaps others would also. I've printed it out and will keep reviewing it until I get the recursion algorithm right. BTW: I'm hoping I'm close, but w/ such recursion tweaking one never knows if that is so, or it's just another subtle a change. I'm hoping to compare TEST to PUBLIC over the next day or few to see what the outcome of the builds shows. Theoretically TEST could fail w/o it being wrong, just that the current metadata relies upon the bloated classpath algorithm. I'll keep watching. regards, Adam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
