>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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
