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]
