One minor item to add. I have modified my local build.xml to include
source="1.3" in the javac element. This means the bytecode my Java 5.0
environment generates at least runs under 1.4 and 1.3. This mainly
helps me to switch between 5.0 and 1.4 without having to recompile. I
wonder if this change should go into svn?
Manuel
On Sun, 14 Aug 2005 06:27 am, J.Pietschmann wrote:
> Hi devs,
> after some cleanup, there are still some things in build.xml
> which irritate me a bit. Mainly it's style. Unfortunately, my
> ant-fu hasn't been updated much since Ant 1.3 was the actual
> version.
> 1. IIRC Ant allows property definitions outside tasks sinc,
> umm, 1.4 or so. None of the property definitions in <init>
> really seem to depend on <init-avail>. Shouldn't they be
> moved up now?
> 2. Should we really set build.compiler?
> 3. The font name properties (${Courier.xml} etc. seems to be
> used only once, the reason thy have been defined seems to
> be pure text shortening. I'd expand them again.
> 4. Id' like to expand some trivial properties like
> ${textfontencoding} too.
> 5. Some controlling properties are still in various tasks:
> schemas.dir in validate-xdocs
> javadoc.* in javadoc
> fop.transcoder* and transcoder-deps in transcoder-pkg
> (note the various name inconsistencies)
> 6. Name inconsistencies: build.gensrc, build.dest, build.javadoc,
> src.java and src.codegen are all directories but don't have the
> dir suffix like other properties holding directory names. What
> should we do here?
> 7. Generally: When should a value referenced through a property?
> Yes, I know the drill:
> - Might be overridden by properties loaded from files or the
> environment, in particular by build-local.properties
> - Is used multiple times, perhaps scattered all over the place
> - Have a single place at the top of the buildfile to change a
> value
> Well, I think abstraction went a bit out of hand in the past (long
> property definition lists in the init target run counter to the
> "have the values in a single place for easy changes"), and more
> recent additions seem to have reverted to local definitions, most
> obvious in the transcoder target. There are know directories
> hardcoded in multiple places (e.g.
> "${build.dir}/test-reports/fop"), locally coded filesets etc.
> What's our policy? In particular with regard to the directory
> layout: how stable should it be considered?
> 8. What's the purpose of having lots of properties defined in
> build.xml *and* a few more in build.properties? I suggest moving
> everything to build.xml.
>
> Last but not least: the main fop jar currently doesn't include the
> fop.xconf file nor serialized hyphenation patterns. Is this by
> design?
>
> J.Pietschmann
