Just to make it clear - the saxon plugin does not contain any code. I have removed the saxon debugging code that used to depend on saxon.jar. It will'compile' just fine (in fact there is no java code at all, it is just resources).
All it contains is a contribution to the processorTypes extension point, which allows Saxon to appear as a possible processor type in the Features, Output Properties and Installed Processors preferences.
Currently there isn't another way for the user to add it themselves - unless they feel like contributing their own extension points!
----- Original Message ----
From: David Carver <d_a_carver@xxxxxxxxx>
To: WTP Incubator Dev list <wtp-incubator-dev@xxxxxxxxxxx>
Sent: Thursday, 17 January, 2008 4:13:35 PM
Subject: Re: [wtp-incubator-dev] Smoke Test Time
DOUG SATCHWELL wrote:
> There is a good reason to retain the Saxon plugin, even though it
> doesn't actually contribute a Saxon processor instance.
>
> The user is allowed to add new instances of a processor via the
> Installed Processors preference page. But without the Saxon plugin,
> they will not be able to add Saxon processors themselves.
The problem is that without the SAXON.jar you can't get a clean
compile. We shouldn't check in code that doesn't compile cleanly. And
Saxon isn't approved by IP to use.
I agree that it is woudl be great to have
the functionality, but there
are other ways the user can add it themselves, or have Saxon itself
include the functionality through a plugin for the XSLT editor.
Dave
_______________________________________________
wtp-incubator-dev mailing list
wtp-incubator-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/wtp-incubator-dev