Gumpy and

[Stefan Bodewig <bo...@apache.org>]

Hi,

excalibur-component builds on gump.covalent.net but not on lsd as
Gumpy doesn't even try to build it.  It says the prereq checkstyle was
missing.

checkstyle is an optional dependency, doesn't Gumpy support that, yet?

Sorry that I can't do more than complaining ATM.

Stefan

Re: Gumpy and

[Adam Jack <aj...@TrySybase.com>]

> excalibur-component builds on gump.covalent.net but not on lsd as
> Gumpy doesn't even try to build it.  It says the prereq checkstyle was
> missing.
>
> checkstyle is an optional dependency, doesn't Gumpy support that, yet?

It can't be that simple, it certainly has the concept. It tries to only
'warn' if an optional dependency is missing/failed, and I'd have bet a
decent amount of cash on that working. I'll try to dig in this evening (PST
time).

> Sorry that I can't do more than complaining ATM.

Identifying problems is a big help, no problem...

regards,

Adam

Re: Gumpy and

[Adam Jack <aj...@TrySybase.com>]

> 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.)

I agree there are a number of way this could be implemented, but I think
Gumpy needs to start by correctly emulating Gump, and we'll take it from
there in the future. Looking into the code I think that the approach above
is how Gumpy was coded (first by Sam, then extended by me) but that steps
(3) and (1) were reversed in order, unintentionally (not sure when, if not
always). I think the fix might be as simple as switching the two bits of
code, but I'm suffering from one big network outage (at hotel) so I can't
test/check-in. [If this mail gets sent soon it'll be during a break on a
borrowed network.]

> 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.

Yup I agree. I've not don't it yet 'cos bloated classpath haven't
(noticeably) caused problems yet. I'd like to be as clean as possible
though, so I'm keeping this issue in mind.

regards

Adam

Re: Gumpy and

[Stefan Bodewig <bo...@apache.org>]

On Tue, 3 Feb 2004, Adam Jack <aj...@trysybase.com> 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

Re: Gumpy and

[Adam Jack <aj...@TrySybase.com>]

> excalibur-component builds on gump.covalent.net but not on lsd as
> Gumpy doesn't even try to build it.  It says the prereq checkstyle was
> missing.
>
> checkstyle is an optional dependency, doesn't Gumpy support that, yet?

I should've waited to press send, 'cos I figured it'd be along these lines
... the <ant <property is setting a '<depend' despite the lower down
'<option. So -- incorrectly -- as displayed here, it has two dependencies on
that project.

http://lsd.student.utwente.nl/gump/avalon-excalibur/excalibur-component_deta
ils.html#Project+Dependencies

I know the code checks for a full dependency on the project before
constructing one, so I'm not sure how this slipped in. Any pointers on the
correct behavior for determining the need for such dynamic dependencies?

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.)

regards

Adam