Hi all,
we are currently shipping two transformers for XSLT import/export
filters. The default one is libxslt-based (thanks, Peter!) and is used
for all our internal filters. The older saxon-based one only remains as
a backup, in case some existing filter needs features not-supported by
libxslt (e
On Wed, Oct 3, 2012 at 3:40 AM, David Tardon wrote:
> Hi all,
>
> 2. a repo on github or similar
> PROS:
> * distance from libreoffice. It is not part of our project, so we are not
> obliged in any way to ship it :-)
> CONS:
> * no automatic commit rights (but who would want to commit to the
>
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
duplicate
On Wed, 2012-10-03 at 03:58 -0500, Norbert Thiebaud wrote:
> Why? if that become truly an extension, it can be on whatever license
> no ? so just leave it as LGPL3...
To make it future-proof against wheel of reincarnation if saxon licence
changes again and/or something comes along and we want to f
On Thu, 2012-10-04 at 10:14 +0100, Michael Meeks wrote:
> 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 n
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.
>
>
Hi,
Quoting David Tardon :
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.
On Thu, Oct 4, 2012 at 7:37 AM, wrote:
> Hi,
>
>
> Quoting David Tardon :
>
>> 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
>
Hi Norbert,
Quoting Norbert Thiebaud :
On Thu, Oct 4, 2012 at 7:37 AM, wrote:
Hi,
Quoting David Tardon :
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
Hi,
On Thu, Oct 04, 2012 at 03:11:43PM +0200, d.ostrov...@idaia.de wrote:
> >Of course I welcome volunteers :-)
> Another advantage if it is hosted on gerrit: i am going to
> contribute to it ;-)
I did not mean 'volunteers' for contributing, but for the maintenance
:-) I personally do not expect
Hi,
Quoting David Tardon :
Note that it is possible it will never be needed by anyone. I have
already said I do not know of any existing XSLT filter that uses XSLT
2.0. But there was demand for it back in OO.o times and it was one of
the reasons for switch from xerces to saxon. Because I cannot
On Thu, 2012-10-04 at 16:15 +0200, d.ostrov...@idaia.de wrote:
> It sounds very suspiciously like YAGNI rule [1] candidate to me, in
> wich case we should probably just kill it or like Michael Stahl put it
There has been at least one question around the XSLT 2 functionality in
the las
Hi David,
I found the MS XML 2003 filters to use XSLT 2.0, but only for the way
they referred to extension functions (which is no longer required).
Also, Saxon offers some optimizations for the recursive templates used
in spreadsheetml 2003 (that Xalan doesn't handle well), so that might
have
Le 03/10/2012 10:40, David Tardon a écrit :
Hi David,
These changes wouldn't happen to cause the build to fail in binfilter by
any chance, coz I'm seeing this now in tail_build :
autogen switches
--enable-binfilter
--enable-extra-template
/home/Development/libo/workdir/unxlngi6.pro/CxxObject/
Le 06/10/2012 13:18, Alex Thurgood a écrit :
>
> These changes wouldn't happen to cause the build to fail in binfilter by
> any chance, coz I'm seeing this now in tail_build :
>
> autogen switches
> --enable-binfilter
> --enable-extra-template
FWIW, I get the same build failure on Mac OSX 10.8.
Hi,
On Sat, Oct 06, 2012 at 01:18:04PM +0200, Alex Thurgood wrote:
> Le 03/10/2012 10:40, David Tardon a écrit :
> Hi David,
>
>
> These changes wouldn't happen to cause the build to fail in binfilter by
> any chance, coz I'm seeing this now in tail_build :
No, for two reasons:
1. it does not t
Le 07/10/2012 09:55, David Tardon a écrit :
Hi David,
> No, for two reasons:
> 1. it does not touch sax at all
> 2. it is not in master yet
>
Ah, ok, thanks for the info.
Well, I did a complete complete git pull, make clean, rebuild and got
through to the end on Linux, will have to check on my
17 matches
Mail list logo
