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
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 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.
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/
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
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,
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
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 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
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,
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.
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.
>
>
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
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 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, 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
>
16 matches
Mail list logo
