RE: cvs commit: jakarta-alexandria/proposal/gump/java Jenny.java Module.java Project.java

["Sikha, Naresh" <Na...@schwab.com>]

>Re: the proposed fix to expand: the problem I was seeing wasn't related to
>profiles.  Once included, the old nodes are no longer needed in their
>previous form.  What I was seeing is that the logic I added which enabled
>the inheriting of dependencies effectively ended up stealing them.
>
>In any case, if you look closely at the logic you patched, a few lines down
>there is the logic to recurse through the children.  There is no need to do
>this twice.

I think I misinterpreted the bug you described. The problem I've encountered
that the patch I proposed solves can be described as follows:

- reference a profile that contains project "foo"
- "foo" specifies that it delivers a jar called "lib/foo.jar"
- override "foo" project in your workspace and have it deliver a different
jar, "lib/newname.jar"
- the overriden jar doesn't show up, but the original jar does. this is
because of "moving" children in a profile to the end of the workspace. The
effect is that newname.jar is interpreted as the original jar and the
foo.jar is interpreted as the overriding jar name.

Here is a visual representation:

workspace
|
-- profile "x"
|  |
|  -- project "foo"
|     |
|     -- <jar name="lib/foo.jar" id="jar.foo"/>     
-- project "foo"
   |
   -- <jar name="lib/newname.jar"/>

And the end result (given the existing algorithm in expand) is that you have
a jar definition of:
  <jar name="lib/foo.jar" id="jar.foo"/>
when the expected definition of the jar should be (IMHO):
  <jar name="lib/newname.jar" id="jar.foo"/>

The patch I proposed would expand the reference to the profile so the
workspace looks like:
workspace
|
-- project "foo"
|  |
|  -- <jar name="lib/foo.jar" id="jar.foo"/>     
-- project "foo"
   |
   -- <jar name="lib/newname.jar"/>

Then overriding project definitions makes becomes clearer. Right now
overrding project definitions doesn't take place, only appending new
attributes/elements (i.e. the "package" attribute is an addition).

Let me suffix this by stating that I, unfortunately, have had to fork the
gump codebase :(, but solving the problem in the manner I proposed has not
only allowed for dependency inheritance and true project overrides, it has
allowed me to develop "anti-elements" (as you have mentioned in your
documentation). Here is an anti element I have developed:
  <not-jar name="lib/foo.jar" id="jar.foo"/>
which removes the <jar name="lib/foo.jar" id="jar.foo"/> element altogether
(but the order the elements are entered into the workspace most definitely
matters).

Cheers.

-Naresh Sikha

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>