This patch fixes some copy&pastos in the extension
JavaDocs as well as updates Xalan2 and Saxon URLs.
Logged In: YES
Here's an updated patch including more fixes. Please apply.
Extension javadoc fixes
Logged In: YES
I'll look at these patches and first apply in my
sandbox without committing to CVS.
Then, I will give you a standalone build of the
extensions for Saxon 6 and Xalan 2. At that time, I'd
like to ask you and whoever else from the JPackage
project to check it and comment on it.
I made some minor changes to your build.xml file. For
one, I changed jar file names to docbook-xslt-saxon6.jar
and docbook-xslt-xalan2.jar. Part of the reason is
that Norm has added extensions for Saxon 8. So when
those are released standalone, it seems like the name
docbook-xslt2-saxon8.jar will make sense.
I also added README, RELEASE-NOTES.html and
RELEASE-NOTES.txt files and VERSION files.
I have suggested to the DocBook project team that we
start releasing the DocBook XSLT Java extensions as a
separate package; if I get an OK from the team, we will
probably do a docbook-xslt-java-1.5 release next week.
Ok. In JPackage, we cannot rename the jars without
providing backwards compatibility symlinks, and I don't
actually see a compelling reason to rename the existing
ones. How about just leaving the old ones as is, and just
adding saxon8? By the way, we will most likely not be
providing the saxon8 jar in JPackage, because Saxon 8 is not
free software. I updated our docbook-xsl-java package to
1.67.0 yesterday, it's in the "devel" section and will be
released soon, probably next week, along with the rest of
JPackage distribution version 1.6.
A separate package for the java extensions would be nice,
but I'd like to ask you to not go backwards with the version
number (current 1.67.0, new 1.5 as you suggested) as this
will cause all sorts of upgrade problems that need special
Thanks for the reply. OK, based on your feedback, I
guess that if/when we do that standalone release, it'll:
- retain the same jar file names as in the build.xml
file you included
- not include Saxon 8 extensions (if those are
released, I guess it would make sense to make them
a separate docbook-xsl2-java package)
- be version-numbered so as to not cause JPackage
But about the last point: If we release the upstream
package as a standalone package, I personally think it
does not make any sense to version it with a four-digit
version number like that of the docbook-xsl package.
It's not necessary and worse yet, it is misleading in
that it implies it is in sync somehow with the
docbook-xsl versioning, which it won't be & need not be.
What about numbering it using a simple single-digit
numbering scheme, starting with, say, docbook-xsl-java-5 ?
Will that be a problem? If so, can you please suggest a
version-numbering convention that will work for you all?
Thanks for your time and consideration.
Regarding the version numbering scheme of the possible
standalone package, I have no strong opinions as long as it
keeps increasing at every release, and if possible, also at
the transition (1.67.0 -> XXXX) time. I don't see any
problems with the suggested single-number naming scheme; if
you feel comfortable with it, just go ahead.
A fix for this issue has been added to the current codebase.
Please test the fix with the latest snapshot from:
Log in to post a comment.