Tim Ellison wrote:
[ If you don't know/care about either OSGi manifests or Eclipse, then
don't worry, you can ignore this note -- just continue as you are. ]
I'm going through the module manifests and putting in some explicit
imports to satisfy the requirements of the tests within a module.
Since this means that a module will now 'import' (depend upon) a package
only because a test case uses it, I'm marking such imports in the
manifest as 'optional' -- this means that the same manifest can be used
in development and in the JARs that we deploy at runtime (which don't
contain the test code). The alternative would have been to move test
code out into a separate module but I'm NOT going there!
That makes sense.
Similarly, where a module manifest exports a package only to satisfy
somebody else's test code, it is done with a mandatory attribute to show
why it is being imported.
:/
What's the downside? It doesn't matter now, but in the future, should
we consider having the manifests assembled as part of the build based on
target? Talking out of my hat, it sounds like each breaks into two
parts, a 'manifest base' and 'manifest test' or -ish...
I'll also commit updates Eclipse metadata (.project and .classpath
files) for our modules, for those people who want to follow along.
Common custom is to keep that kind of thing out of SVN but I realize
that as Eclipse is such a bear to set up.... ;)
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
