Hi David - I think we've been through this before on this list...but the reason is that neither of these plugins actually contribute anything to the Eclipse classpath, they simply build jars that are needed for when a transform is launched.
It is very important that we know the name and location of the built jars, and also that we don't jar the bundles, so that we can add the built jars to the classpath of the launched process. In fact I notice that version 1.2 of build.properties in org.eclipse.wst.xsl.xalan is broken because it no longer specifes the name of the jar to be created...this needs to be fixed or else the launching won't work when the project is built!
----- Original Message ----
From: David M Williams <david_williams@xxxxxxxxxx>
To: wtp-incubator-dev@xxxxxxxxxxx
Sent: Sunday, 10 February, 2008 9:44:18 PM
Subject: [wtp-incubator-dev] Status of Builds for M5 and a question on non-jarred plugins
I've changed the build scripts to produce "S" builds now, instead of "I" builds.
I'm using the xalan jar from Orbit, instead of having our own "embedded" one.
I am done experimenting with signing now, so if you see an S build that is signed, it's an error.
(and ... let me know!).
And, an important question ... I've noticed that two plugins are not jarred up.
org.eclipse.wst.xsl.xalan
org.eclipse.wst.xsl.debug
Why is that? Was it because they contained embedded jars?
If so,
org.eclipse.wst.xsl.xalan
no longer does ... so, guess we could jar that one up.
And ... why is there two jars in
org.eclipse.wst.xsl.debug?
History? Or some functional need?
Can we eliminate them, and jar up that plugin too?
Thanks,
