Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-incubator-dev] Xalan

It is definitely the case that the Saxon plugin depends on the wst.xsl code, NOT the other way round. If you take a peek at the org.eclipse.wst.xsl.xalan plugin, you can see exactly how it would work for Saxon too.

The Xalan plugin is entirely self-contained - it does not even export any libraries. In fact, it doesn't even have an Activator class - its a pure resource-only plugin that simply contributes to extension points defined in wst.xsl.launching.

I'm pretty confident then that we can make an externally maintained plugin, should we so wish. But as David W rightly points out, we must ensure that it remains that way, particularly if we are looking to implement XSLT 2.0 and require a 2.0 processor!


----- Original Message ----
From: David Carver <d_a_carver@xxxxxxxxx>
To: WTP Incubator Dev list <wtp-incubator-dev@xxxxxxxxxxx>
Sent: Sunday, 16 December, 2007 6:47:32 PM
Subject: Re: [wtp-incubator-dev] Xalan

David M Williams wrote:
>
> /... but host that support out on Sourceforge or another site outside
> of Eclipse.  I've seen the ECF project do this for some of their
> plugins that didn't pass Eclipse IP. ..../
>
> Care will be needed here, as there are new IP rules this year that
> state, briefly, that anything that a project depends on needs to have
> IP review ... whether its redistributed or not! This was put in place
> specifically for cases where people were by-passing the Eclipse IP rules,
> especially for cases where the third party code was required to use the
> Eclipse code.
>
> If it's a very general pre-req, such as "the end user needs to add
> some XSL processor"
> and there are some Eclipse IP passed choices (such as Xalan) then we
> are probably ok,
> but I'm just noting this here to note the limitations, and that we'll
> need to
> re-read the rules closely and (still) submit the required IP information.
To implement an XSLT framework that is extensible, doesn't require the
use of Saxon, as we can implement that framework with just Xalan support
and XSLT 1.0 as the default distribution.  With that said, we might
consider developing the XSLT 2.0 for saxon as a seperate project that
just acts as any other plugin.  In this way, it's just a plugin that
uses the framework and the framework doesn't depend on it.

Dave

_______________________________________________
wtp-incubator-dev mailing list
wtp-incubator-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-incubator-dev


Back to the top