On 7 Oct 2009, at 23:21, Alasdair Nottingham wrote:
Hi,
While reading over the email archive I noticed the WAB URL Handler
email chain seemed unresolved, so I thought I would contribute before
it closed (I did not receive the original email chain, so sorry if
this starts a new one). In response to a comment from Valentin:
We shouldn't need to scan embedded jars (i.e. in web-inf/lib) if they
have a valid bundle manifest.
We do need to scan embedded jars both inside and potentially outside
web-inf/lib. These bundles are not OSGi bundles and the OSGi framework
will pay no attention to the manifest data in the embedded jars, so
their dependencies need to be in the manifests of the war.
I agree that we need to determine the dependencies of every embedded
library that would be available to the WAR in a JEE context.
My comment was meant to say that we don't need to scan embedded jars
with a bundle manifest since the converter can simply take their
dependencies from the available manifest, and then add them to the WAB
bundle manifest. I realise this might be slightly more effort then
just scanning everything regardless. However, the spirit of RFC 66 to
me is to respect existing OSGi metadata wherever possible. So if a
utility library has this set we should be using it.
On the subject of importing everything as optional I would point out
that it is common for war applications to be "incomplete" with non-JEE
dependencies used from outside the WAR. When we discussed this in the
context of the original IBM code we did decide that over provisioning
was acceptable, which is why the packages were not marked as optional.
The consensus on this list though is that they should be optional,
which is fine. Guillaume gave three options for doing the optional
importing:
I think the only possible solution is to have either:
* scanning with all packages as optional
+1
* no scanning with a DynamicImport-Package = javax.*, org.org.xml.*,
org.w3c.*
-1 I do not like using DynamicImport-Package, OSGi is a modularity
system based around declaring your usage of packages.
DynamicImport-Package breaks this modularity and since the url handler
is a "migration" aid people are likely to make use of the result of
the url handler to generate their manifests when they do a proper WAR
-> WAB conversion. We should have the url handler perform the scan
according to the way we would prefer they author their manifests.
* no scanning with a DynamicImport-Package = *
-1 see previous comment
Just my 2 cents worth.
Alasdair Nottingham
[email protected]
Link to Valentin email:
http://mail-archives.apache.org/mod_mbox/incubator-aries-dev/200910.mbox/%[email protected]%3e
Link to Guillaume email:
http://mail-archives.apache.org/mod_mbox/incubator-aries-dev/200910.mbox/%[email protected]%3e
