Andrew C. Oliver wrote:
So Getting gump to run under Windows is not particularly fun. (Don't ask, my hands are tied).
[...]
I'm curious if it has been suggested before....
Ant files are XML and transforming to them seems to be more natural. Ant isn't the most kind thing in the world for its "Hey this crap broke" messages, but it is FAR better than cmd.exe or bash in this respect.
[...]
Anyhow, I'm just curious what problems there are with this approach. As my level of pain increases I'll probably experiment with this, but I'm curious if others have thought of this and what the downsides are...Andy, I've been through all this before, in the months you were waiting for Centipede to build under Gump ;-) If you searchg in the alexandria-dev mailing list you will find some interesting discussions about this. I'll try to summarize here the results I came to. Scott Sanders seemingly did the same thing before me, so I would like to spare you this waste of time and get more productive right away.
_Gump sucks, why does it use scripts?_
Heck, Ant is in Java, cross-platform and can invoke scripts. Why don't we XSLT the descriptors into an Ant buildfile and run that? Look in the jakarta-alexandria CVS module and you'll find AntGump.
_These generated and buildfiles are messy, why don't we make a model?_
Heck, all done in XSLT gets messy. Let's parse the files and create an Object Model of the build, and act on that. In the same CVS as usual, look for Vindico, courtesy Scott Sanders (again).
_Wait, the problem is in the Gump installation, let's refactor?_
I refactored the Gump CVS to split the various parts of Gump into repository data, aggregation of data, script generation, site generation. Result? No real gain and nobody folowing. Deleted effort (but understood a lot in the process).
_Now what?_
Form the above + other info I gathered while having the high levels of frustration you envision ;-) :
- As for merging the descriptors, Jenny does just fine,it simply works.
I would not change that. So I came up with the concept of VIPROM,
that means Virtual Project Object Model. merge.xml is the current
physical way of making it, and we could access it programmatically
from jxpath (so in the future we don't need to change all code just
to change how the model is constructed)
- Then the projects must be run. Now we use script generation with
XSLT. HEck, there is a lot that can be done here. Imagine using
Velocity instead. Much faster and much cleaner writing. It
can be also quite easy to make ant buildfiles out of it.
- Another option to run is to use a Java frontend, that runs the
builds programmatically. This can be a base also for a daemon service
that can run projects remotely at request or at cvs commits.
On my side, I'll be using a VIPROM to access project descriptor info from Ant buildfiles, and add a feature in Centipede that builds the projects in the module (the single module) with dependencies et all.
Comments?
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
