Re: More about build.xml
Now that I got my memory back, I was actually the one starting the vote to remove all this: http://marc.theaimsgroup.com/?l=fop-dev&m=111079476222548&w=2 http://marc.theaimsgroup.com/?t=111558789900011&r=1&w=2 I got tired of dealing with the licensing hell on hyphenation patterns. I hated this so much I even unconciously banned all this from my brain. D'oh. On 14.08.2005 22:55:24 J.Pietschmann wrote: > Simon Pepping wrote: > > In spring of this year it was proposed that all hyphenation patterns > > be removed from fop and only be made available by OFFO. > > I must have missed something: FOP is supposed to be distributed > without any hyphenation patterns at all? > > I support augmentation by external projects, but we ought to > support hyphenation out of the box at least for a few languages. > After all, hyphenation is part of the FOP core business, in > contrast to, e.g., providing a servlet. > > J.Pietschmann Jeremias Maerki
Re: More about build.xml
Simon Pepping wrote: In spring of this year it was proposed that all hyphenation patterns be removed from fop and only be made available by OFFO. I must have missed something: FOP is supposed to be distributed without any hyphenation patterns at all? I support augmentation by external projects, but we ought to support hyphenation out of the box at least for a few languages. After all, hyphenation is part of the FOP core business, in contrast to, e.g., providing a servlet. J.Pietschmann
Re: More about build.xml
Damn. Right. Bloody details. Does anyone know where I can get a decent brain upgrade or replacement? Anybody been lucky on ebay or something like that? I hate forgetting stuff like that all the time. On 14.08.2005 21:56:21 Simon Pepping wrote: > On Sun, Aug 14, 2005 at 07:43:36PM +0200, J.Pietschmann wrote: > > Jeremias Maerki wrote: > > >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. > > 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? :-) > > In spring of this year it was proposed that all hyphenation patterns > be removed from fop and only be made available by OFFO. In fact, the > same old set is still in xml-fop/src/hyph. > > Users could put their hyphenation patterns in xml-fop/hyph. The > hyphenation target uses this directory. If it is empty, no hyphenation > patterns will be compiled. The patterns in xml-fop/src/hyph are not > used. > > hyphenation-jar collects the patterns in xml-fop/build/hyph in a separate > jar file, to preserve independence of fop. > > In fact I offer ready made hyphenation jars in OFFO, > http://prdownloads.sourceforge.net/offo/offo-hyphenation-fop-HEAD.zip?download. > > > Simon > > -- > Simon Pepping > home page: http://www.leverkruid.nl Jeremias Maerki
Re: More about build.xml
On Sun, Aug 14, 2005 at 07:43:36PM +0200, J.Pietschmann wrote: > Jeremias Maerki wrote: > >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. > 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? :-) In spring of this year it was proposed that all hyphenation patterns be removed from fop and only be made available by OFFO. In fact, the same old set is still in xml-fop/src/hyph. Users could put their hyphenation patterns in xml-fop/hyph. The hyphenation target uses this directory. If it is empty, no hyphenation patterns will be compiled. The patterns in xml-fop/src/hyph are not used. hyphenation-jar collects the patterns in xml-fop/build/hyph in a separate jar file, to preserve independence of fop. In fact I offer ready made hyphenation jars in OFFO, http://prdownloads.sourceforge.net/offo/offo-hyphenation-fop-HEAD.zip?download. Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: More about build.xml
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. "..a log". When will I finally start to reread the stuff I typed. > > 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
Re: More about build.xml
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. 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 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. 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. 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. 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? :-) J.Pietschmann
Re: More about build.xml
Not a bad idea, I think. Jörg? On 14.08.2005 04:43:29 Manuel Mall wrote: > 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? Jeremias Maerki
Re: More about build.xml
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
> really seem to depend on . 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
Re: More about build.xml
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
> really seem to depend on . 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
More about build.xml
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
really seem to depend on . 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
