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 :)
