On Friday 02 June 2006 21:47, Thomas Watson wrote: > Niclas, thanks for pointing this out to us. I'm sure the Felix team > (Richard) is loving this ;-) > > I found several areas in the (Equinox) resolver to greatly improve > performance when large sets of "uses:=" directives are used.
Cool. I got the notification from Bugzilla. > While investigating this it dawned on me that you are importing > every package which you export. I now realize that is a result > of running the automatic manifest generation tool (is this mangen?). No, I'm running the Maven plugin that Peter Kriens has donated to Felix. > This only happens if you have the "Bundle-ManifestVersion: 2" > header to indicate you are using OSGi R4 bundle manifest syntax. Yes, I have added to the said plugin that it defaults to ManifestVersion 2. I am not fond of undefined versions. > If you always import every package you export then you will > prevent multiple versions of the same package from being available > in the system. I don't follow this argument. IIRC, the multiple versions of the same packages has been with OSGi since the early days, and not anything new in R4. > For example, imagine you must support two versions > of the junit library in your system at the same time. One junit > bundle version 3.8.1 exports all of its junit packages at version > 3.8.1. Another junit bundle version 4.1.0 exports all of its junit > packages at version 4.1.0. Both of these bundles can be installed > and resolved at the same time. Now if the 3.8.1 junit bundle > imports every package it exports then the resolver can resolve > its imports to the 4.1.0 versions of the junit packages. This will > drop the exported packages from the 3.8.1 version of the bundle and > make them unavailable to the rest of the bundles in the Framework. Huh? No. That depends on the version directives. And the way I interpret the spec (but I can have missed something) is that; If Bundle A exports q-1.0 and imports q, and Bundle B exports q-1.1 and the framework resolves A's import to B's export, A will still provide the export of q-1.0 for, for instance, Bundle C that imports q-1.0 (restricted). So that albeit Bundle A doesn't use its own exported packages, it will still have to provide it for those who depends on them. > This also puts a much greater burden on the developer when they > decide to export a package. If every exported package is also > imported then the developer must be prepared to handle when their > own exported package is substituted with another version of the > package from a different bundle. This means you cannot have > any internal implementation dependencies on the packages you > export. This is an accurate note, which I "hope" the Maven plugin will detect and report, if not now then it should be added. > In your example manifest you have over 100 exports. > Are you prepared for any one of those exports being replaced with > a package from another bundle? Are there no internal > implementation dependencies between your packages. With such a > large set of packages it seems likely you would have some > internal implementation dependancies. In my case, I am 'suffering' the "legacy syndrom". The majority of packages are "Wicket", a web framework outside the OSGi domain, which I am OSGi enabling with dynamic components, replacable pages, and other OSGi tricks. Since a) the Wicket components and pages will sit in their own bundles, b) I want aviod limiting what you can do in Wicket, c) Wicket was not designed for OSGi, I have not much choice than export all their packages. The interesting case, however, is what are the implications if Wicket is imported from somewhere else? For the time being I have said, "not allowed" as I think there are still a couple of classloader issues involved, but that is a totally different story. > One last nit. The tool seems to add packages to the uses clause > which either do not exist or are internal packages to your bundle. > For example search for org.ops4j.pax.wicket.service.internal in > your uses clause. It states that exported package > org.ops4j.pax.wicket.service uses this internal package. > Is the tool being to aggressive? > Or do you have an unintentional internal dependency? I think the answer to those are both "Yes". Peter Kriens have to provide more info on how he perceives an automated tool should work. I added the possibility to "ignore" packages, i.e. exclude them from the auto import. However, Peter's tool have also discovered "uses" of classes that I would have never thought of importing and that would have cause runtime problems very "late"... So, I think the "aggressive" is probably good, but that the developer need to scrutinize the list actively and add the "ignores". But thanks a lot for your attention. Cheers Niclas
