Skip to main content

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


> > 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?


In the worst of cases, it might be allowed ... but definitely not good practice and
shouldn't be our first choice, nor second, nor third :)

Dave's suggestion to make it part of Saxconica is a great one.

If that fails, we need to think/design some more, I think.




From: David Carver <d_a_carver@xxxxxxxxx>
To: WTP Incubator Dev list <wtp-incubator-dev@xxxxxxxxxxx>
Date: 01/03/2008 11:50 AM
Subject: 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
>  

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


Back to the top