FWIW, I think I've been running into a problem at build time because of
this exact issue. There's a bit of code in the javascript sample
HelloWorldTestCase.java test that gathers up all of the
META-INF/sca/default.scdl resources it can find. The test then throws
away the first resource in the enumeration assuming it's the
application's default.scdl and not the extension's default.scdl.
ant elder wrote:
I guess it somehow needs to find the URL to the default.scdl for the
JavaScript extension, but thats just in a jar on the classpath and there's
lots of default.scdl resources on the class path so how does it know which
is the JavaScript one?
And the once it has that URL it isn't real obvious (to me) how you could
use
that from the testcase to get the extension registered with the runtime.
...ant
While the build generally succeeds, every once in a while the test fails
with an UnrecognizedElementException on implementation.js. I added a
System.out.println to the test to show which of the resources was thrown
away in the following code snippet and found that the extension scdl can
be discarded instead of the application scdl. (I'm assuming this is
because enumeration that comes back from getResources doesn't have a
specfied order.)
At this point I guess I have to wonder if the name used for the
extensions' scdl should be something different from the default
application scdl name? It seems like it might be nice to do something
like gather up like all of the visible META-INF/sca/extension.scdl
resources and add them to the runtime as extensions. I don't believe
this would be at odds with the current extensions mechanism in the
DirectoryScanExtender if it went after extension.scdl instead of
default.scdl.
Just a thought.
--
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
