bundled saxon considered harmful

[David Tardon]

Hi,

On Thu, Oct 04, 2012 at 10:14:00AM +0100, Michael Meeks wrote:
> 
> On Wed, 2012-10-03 at 10:40 +0200, David Tardon wrote:
> > It has always bothered me (and other package maintainers too) that we
> > have to bundle saxon*[2] just because of something that is most probably
> > never used.
> 
> 	Yep - sounds annoying; it'd be nice to drop the 5Mb of jar file
> duplicated by all those downloads :-)

This is one aspect of the thing that I have never considered :-)

> 
> > I propose that we change the saxon-based transformer into an extension
> > and then drop it from our codebase. The first step has already been done
> > on branch feature/kill-saxon. The other step requires to answer the
> > question "where to put it?" There are two possibilities:
> 
> 	And how/who builds and up-loads it is of interest to me; should we have
> these extensions built and up-loaded by some automated mechanism in our
> release process ? with some account that has widely known credentials -
> so there is no single point of failure ? or do they feasibly change so
> infrequently that there is no problem :-)

The idea is that when we drop it from core it becomes "just another
extension usable with LibreOffice". We do not worry about LanguageTool,
OpenOffice.org2GoogleDocs or any other of the extensions listed on
http://extensions.libreoffice.org/extension-center, do we? "XSLT2
Transformer" will just join the crowd there. IOW, it is not going to be
connected to LibreOffice in any way (except that the committer(s) happen
to be libreoffice developer(s)). Making this separation clear is the
main reason I am in favor of putting the code to github or similar site.

It would be the committer's responsibility to build the extension and
continue maintaining the code (if there is anything to maintain there
:-) I suppose that unfortunate maintainer is going to be me, unless we
decide to put the code in a repo under libreoffice on fd.o; then
everyone of us would have access to it (but see the pros and cons in my
original email). Of course I welcome volunteers :-)

As for the rate of changes:
filter/source/xsltfilter/com/sun/star/comp/xsltfilter/XSLTransformer.java
has had 28 changes since 2004, 6 since 2010-09-28. Of the latter, 2 are
updates to Java5, one is Apache rebase, and one is my work to make it
usable as an extension.

D.