Hi, Peter I personally agree that the properties don't need the XML+XSLT approach. Even if one leaves aside the aural properties there are over 250 properties, and on close inspection the commonalities are limited. I believe the largest group size of properties that are identical is 4. Many properties have extra constraints (they interoperate with other properties, for example), they accept different combinations of input generic types, percentages have meaning only in the context of the property, and so on and so forth.
One could come up with a super-sophisticated XML+XSLT system to embody all this, but why bother? I'm not going to bad-mouth the current system that FOP has. I acquiesced at least implicitly in the choice to at least continue with it, at an early stage. But I now believe that the right place for a lot of logic related to properties is actually in the properties. I think an XML+XSLT approach pushes a lot of that out into places where it ought not to be. Most of the common handling has actually little to do with the properties per se - it has to do with expressions and datatypes. This is not the same thing. An XSL property is not a datatype, IMO, and shouldn't be regarded that way. I don't think it's a pressing issue unless someone then immediately proposes and moves forward with work to make the properties rich, interesting things. It's not really an IDE issue - there are IDEs that handle the current FOP setup just fine. I also agree that ease of making changes to properties is not a compelling argument for XML files, nor for using XSLT to generate the code. The properties are simply not that similar. So you may as well work on Java properties files directly. And since properties _are_ what make XSL, if there are significant changes in properties in the spec then the disruption is going to be widespread. I agree with Keiron's observations regarding the other point, about versioning. Our numbers are release numbers (major, minor, patch, plus stage info, as he puts it), and these require human decision-making. You can't automate release numbers sensibly. Anything else Ant supports (timestamping, token filtering, build number incrementing) makes a lot of sense in the right contexts, mostly in the sense of configuration management and builds. I'd like to see a stronger link between the release number in the build.xml and the presence of a matching tag in the CVS, myself. I've been personally guilty of forgetting to tag the CVS when buildng a distro and it's because there was no mechanism to jog my memory. I don't think the tagging itself should be automated but some aspect of the source code retrieval prior to building a dist* target should be dependent on the presence of a matching tag. Let's face it, right now we have no configuration management at all - maybe this isn't much better but at least it's something. Regards, Arved -----Original Message----- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: April 3, 2002 12:23 PM To: fop-dev Subject: Some comments on the build system 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
