Leo Simons wrote:
I think this is a bad idea. Gump needs to be fixed to be able to do the same thing as a developer does when building; we should not remove automation because of build setup.
Guess what - I agree with you!
But we should also avoid breaking other gump runs due to a container specific dependency.
FWIW, me and berin have been looking into this.
That's good to know - I had not seen any actions (cvs comits or posts to the list) and there were no suggests or comments raised when I posted the issue to the list back on the 22nd. The datasource failure (Fortress Vertex class stuff) has been occuring since the 17th and as a result the avalon-corenerstone gump process has not run even once against the updated structure.
The problem at the moment is that we have
<ant><depend project="avalon-fortress-tools property="blah" inherit="runtime"/></ant>
but the 'inherit="runtime"' is ignored when you specify a dependency inside the <ant/> tag. One can either put the <depend/> tag outside the <ant/> tag or modify the gump code to provide support.
Either is, imho, a better idea than committing descriptors to cvs. I can see lots of difficult-to-trace build errors arriving in the future because of this.
Whatever the solution - I think it is a bad thing to introduce container depedencies into the build of what should be a container independent resource. I am not saying that the auto generation is a bad thing, I just saying that the generation of the jar file (independenty of Fortress) takes priority. Can these concerns be seperated out somwhow - e.g. a build that generates the artifact, and another build (and corresponding gump descriptor) that adds supplimentary container specific information?
Steve.
cheers,
- Leo
Stephen McConnell wrote:
I have just updated the Excalibur Datasource build.xml and the corresponding Gump descriptor to remove fortress deps. The updates remove the fortress dependency that has been breaking the gump build for the last week.
http://marc.theaimsgroup.com/?t=101947957300001&r=1&w=2
The result of this change is that the fortress auto-meta generation will not run which may break other things. If someone can put together a static version of the meta generated content that Fortress needs, commit this and adjust the build.xml as required, then everything should be hunky-dory.
If gump generates datasource without problem, we can apply the same changes to excalibur-store and excalibur-monitor.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
