On 14.08.2005 00:27:20 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?

Just do it. :-)

> 2. Should we really set build.compiler?

Probably not needed anymore.

> 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.

see 1. :-) ......

> 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?

Scratch the itch.

> 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?

Policy? Hmm. :-) 

> In particular with regard to the directory layout:
>   how stable should it be considered?

Well, I'd say we have more liberty now to change anything than after the
next release. If you see anything that needs fixing, let's fix it. Are
you referring to the build directory only, or also to the src directory,
for example? I'd love to do some changes on the latter but that might
not be extremely popular.

> 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.

I like stuff likely to be overridden be documented in build.properties
as template for a build-local.properties. I use that pattern a log.
People should simply be able to copy build.properties to
build-local.properties and adjust the values therein without a lot of
searching stuff together.

> Last but not least: the main fop jar currently doesn't include the
> fop.xconf file nor serialized hyphenation patterns. Is this by design?

I think the hyphenation patterns were supposed to be in the fop-hyph.jar
which can be used or replaced by the one offered by OFFO. AFAIK, there's
no need for a fop.xconf to be compiled into the fop.jar anymore with the
Avalon, uhm, Excalibur-style configuration. I wonder how many people
actually used the possibility to compile the configuration into the JAR
file. This seems very unflexible to me.

Jeremias Maerki

Reply via email to