On 14.08.2005 19:43:36 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> >>1. IIRC Ant allows property definitions outside tasks 
> > Just do it. :-)
> 
> Well, there's still my antiquated ant-fu... I'd like to tap the
> collective wisdom, just in case I missed something important.

I'd have said if I had stumbled over anything that sounded weird. Anyway,
like you already found out, I neglected to update the build.xml after
upgrading the JAR files. I'm sorry for that. But it immediately shows
that the dist target is probably the best test case for the build. If
that creates the right stuff, the build is fine. And then, we have peer
review which will cause problems to be identified quickly.

> >>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.
> 
> The point was: if pathnames are hardcoded all over build.xml,
> moving stuff around might unintentionally break some targets,
> as happened with the hyphenation stuff. If the directory layout
> is stable, there's much more freedom to kill properties for
> directory layout control.

I'm sorry but I still don't seem to see the point. If directories are
changed the build simply has to be adjusted. Obviously, changing the
project directory structure will always need some feedback from fellow
devs first. If a change has broken the build in anyway, it simply needs
fixing.

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

<fx type="head-shaking">"..a log". When will I finally start to reread
the stuff I typed.</fx>

> > 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.
> > 
> Well, I seem to have recognized a trend that a sensible default is
> hardcoded in the main program (or buildfile), while property files
> for user customization contain documentation and sample values
> for overridable settings but everything is commented out.

Fine with me. Some values (especially paths to optional resources) need
to be easily found and used and sometimes overridden.

> > 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.
> 
> I see. It seems I killed the fop-hyph.jar target prematurely.

I'd say so, yes. :-)

> Is the spin off of the serialized hyphenation patterns the
> start of a trend which will end with a fop-core.jar, fop-api.jar,
> fop-pdfrenderer.jar, fop-j2drenderer.jar, fop-awt-application.jar,
> fop-cli.jar, fop-anttask.jar and, of course, a fop-all.jar? :-)

I don't think so, at least not to this extent for FOP itself. This is
simply good for hyphenation where there are two alternatives to choose
from both of which are optional. For library stuff like the components
to be moving to XML Graphics Commons this is more interesting because
many of these components can be used in a context outside of XSL-FO. On
the other side, providing a sleaker FOP with the renderers and foreign
XML extensions, for example, in separate JARs, automatically discovered,
just like external extensions are now, would certainly be interesting
for people using FOP in applets or WebStart apps, or simply for
pluggability fanatics like I am. :-) But I think these should be
alternatives in separate optional Ant targets. Just like I imagine this
to happen in XML Graphics Commons which will probably be distributed as
a single JAR in the normal case. After all, many people are afraid of or
at least uncomfortable with many little JARs. Well, it can be hard after
all.


Jeremias Maerki

Reply via email to