Andrew C. Oliver wrote:
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.
Costin already started something along these lines:
http://cvs.apache.org/viewcvs/jakarta-gump/stylesheet/ant-build.xsl
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...That may be a value use case for a large portion of the portion of the potential "marketplace" for gump.
Issues:
* I want to fully bootstrap. In my case, I want to build ant from source and use that version later in the build.
* I want to be able to easily reproduce problems outside of the environment generated by Gump. Many times I've found it handy to be able to send somebody a shell script or a batch file along with a set of jars to reproduce a problem that they are *sure* must be Gump's fault.
* Leaky abstractions. I've always found ant calling ant to be confusing, particularly when it comes to what properties can be passed and what can be modified. But that may just be me.
* Modifying JDK levels and/or bootclasspath. A persistent requirement (despite never having been implemented, so take it with a grain of salt) is to do a build with different portions of the build at different JDK levels. What is a real requirement, however, is the ability to modify the bootclasspath between job steps.
All presented merely as food for thought. They reasons may or may not be applicable to you. But there is no reason why Gump can't support multiple targets - it already does so with bash and win2k.
- Sam Ruby
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
