Fops,

I would like to see the build system overhauled.  The overall objectives 
of the overhaul would be to simplify the build process and decrease 
barriers to entry for would-be developers.  The tactical objectives 
would be to eliminate XSL from the build, and to generate the classes 
directly from the source tree.  The advantages of this approach are, I 
think, obvious.  For a developer using an IDE/JDE, the source tree 
associated with the classes whose behaviour is being observed would be 
the same source tree to which changes are being made, and the same 
source tree from which commits would be made.  Eliminating XSL, and 
expressing the system entirely in Java means that, as far as development 
is concerned, what you see is what you get.  There are no invisible 
shenanigans going on behind the build.

I have not gone over the XSL with a fine-toothed comb, but what I have 
seen is enough to be able to give the flavour of the argument. 
 Basically, if you feel the need to generate Java from a combination of 
XML and XSL, you should make your Java look more like your XML, and less 
like the output from your XSL.  The neat data characteristics of the XML 
can and should be expressed more or less directly in Java.

Font generation is simple to translate into a static reference HashMap 
from names to codepoints, set up with a static{} block, and some further 
static{}s to set up the width arrays.

Properties are a fascinating topic.  To me, the fact that Properties 
virtually demand some kind of code generation is proof enough that the 
approach is wrong.  But more of that another time.  Let's say that you 
do need some help to set these things up.  How many times do you need to 
do it?  Isn't once enough?  The majority of the class files having been 
set up, what varies?

Create the base files, and check them in to CVS.  Then put the XML and 
XSL aside as a once-useful historical oddity.  Unimplemented properties 
will presumably be implemented one at a time, so it will be no hardship 
to create the class file by hand, and check the changes in.  If some 
global-ish change needs to be made, a perl one-liner will probably do 
it, and you check the changes in.  The same considerations apply to 
fonts if you are really, really committed to XML/XSL.  However, with 
fonts, I understand that user font data in XML is read in at 
configuration time.  If so, why not read the system font data as well? 
 There are a number of ways to skin this particular cat, none of which 
leave you with a three-language source base.  Three languages which have 
the annoying characteristic of morphing into one, under the hood.

There are a couple of other things which encourage the separation of 
source and build.source trees.  They involve the use of copy filtering 
in ant.  Version information is, I think, supplied by ant via the 
build.xml file.  This vile and disgusting habit, which ant seems to 
encourage, should be stamped out at once.  Version information comes 
from the version control system in use at the time, not from 
hand-hacking on build.xml.  A few changes to Version.java to massage the 
output of the RCS macros are all that is needed.  If that massaging is 
required during the build itself, an ant task should be able to do it.

The other one may be more difficult.  I haven't looked at it in detail, 
or recently, but the copy-filtering was being used to accommodate, I 
think, TRaX variations.  How difficult that would be to work around I 
don't know.

The bottom line is a general increase in sanity, and the simplification 
and unification of the build, development and testing environments.

Your obsequious servant,
Peter


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to