On Tue, 3 Feb 2004, Adam Jack <[EMAIL PROTECTED]> wrote:
> Any pointers on the correct behavior for determining the need for
> such dynamic dependencies?
Not sure about "correct", sorry. In "traditional" Gump things roughly
work as follows:
(1) all <depend> and <option> elements outside of <ant> are collected
in the dependsOn map keyed by the project attribute.
(2) all <depend> elements nested into <ant> get turned into <property
jarpath="..."/>.
(3) <property project="..."> adds a <depend> element to dependsOn if
it doesn't refer to the project itself, is not of type srcdir and
the project name is not already a key in the dependsOn map.
So from this, //project/option wins over //project/ant/depend.
> BTW: I think I need some 'optimization/trimming' algorithm for
> dependencies (right now any 'difference' in a dependency, and subtle
> difference = runtime or not, allows Gumpy to keep two, not one.)
We should look at the differences and create some rules to unify them.
For example, if we have runtime="true" on one element and no runtime
attribute on the other, we can probably assume that "true" is the
correct value. Things get a lot more complicated with inherited
dependencies, though.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
