I would assume OSGi manifest mostly refers to the manifest from the war, not really those of embedded jars ...
On Thu, Oct 8, 2009 at 08:13, Valentin Mahrwald <[email protected]> wrote: > 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 > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
