[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [wtp-incubator-dev] Saxon 9
|
Yeah, but it has a dependency to work only if the Saxon.jar is included,
because of this dependency, we can't distribute it (at least that is my
interpretation). I personally wouldn't want to have code included that
doesn't compile cleanly.
I think the best option here, would be to submit the
org.eclipse.wst.xsl.saxon plugin as a contribution back to Saxconica so
that the author can distribute it with Saxon. That way if somebody
needs Saxon support, and wants to use the Eclipse XSLT editor and
debugger, it is already included there.
Michael Kay is the author, so you might want to contact him to see if he
is interested in accepting a code contribution from you to add the
support as one of his optional dependencies. He can be reached at:
http://www.saxonica.com/contact.html
mike@xxxxxxxxxxxx
Dave
DOUG SATCHWELL wrote:
Actually, we use both methods you have outlined below. The user can
either add a processor install via an extension point I've created
(org.eclipse.wst.xsl.launching.processor) or add one dynamically via
the preference page (in the same way you can add a new JRE for Java).
And you're right - the saxon plugin contains the Saxon debugger I've
written which won't compile without saxon.jar, which we're not allowed
to add. But this is not as stupid as it seems, because the plugin is
not a runtime one - i.e. Eclipse does not load it. It is a
resource-only plugin, and the only time the jar file is actually used
is when a) the user has set up a Saxon install themselves via the
preferences or extension point and b) they start a debug session on
that install. It is then the launched program that loads the jar.
While Saxon is not EPL, the source that I've written for the Saxon
debugger is EPL. So I think the plan is for me to compile it myself
using the saxon.jar I have on my machine, and check the resulting jar
into the saxon plugin module (but also keep a copy of the debugger src
in there too). Is that allowed?
Thanks,
Doug
----- Original Message ----
From: David M Williams <david_williams@xxxxxxxxxx>
To: WTP Incubator Dev list <wtp-incubator-dev@xxxxxxxxxxx>
Sent: Thursday, 3 January, 2008 3:38:58 PM
Subject: Re: [wtp-incubator-dev] Saxon 9
> I have still created an org.eclipse.wst.xsl.saxon plugin, but
> without saxon.jar in it.
From the little I've looked at this, I don't think it's following a
friendly "Eclipse Model".
I'm not sure a "plugin without a jar" in it will even compile (without
being present at compile time).
And, it's not good practice to ask or expect users to copy things into
an installed plugin.
There's a couple of other design possibilities, I think, that would be
better.
One would be to have an XSLT Processor adapter layer (extension point)
that would define what's sometimes called an SPI to "plugin" to any
code that used
an XSLT Processor. (The code would be written to the adapter layer,
instead of directly to
xalan or saxon APIs).
Another design that's sometimes used is the one where the user
specifies where the
processor is installed on their file system, and it's loaded
dynamically, as needed.
This works well if there's a clear, standard interface, and only few
factory methods.
I'll look closer of course, but thought I'd make this quick comment
for discussion
(and my education :)
------------------------------------------------------------------------
_______________________________________________
wtp-incubator-dev mailing list
wtp-incubator-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-incubator-dev
