Niclas Hedhman <[EMAIL PROTECTED]> wrote on 05/31/2006 04:11:30 AM: > > Hi, > <not sure if I should put this to Equinox list or here, but since > bot Jeff and > BJ are present here I thought it made more sense...> > > After Peter Kriens automatic generation of Import-Package statements and the > additional generated "uses:" clauses in Export-Package, we see an extreme > difference in speed for resolving the packages. > > It essentially went from "instantenous" to "many seconds" (~10-15 onmy fairly > fast machine here). I don't understand why. > > It seems that it executes (see stack frame attached) a recursive call to
> org.eclipse.osgi.internal.module.GroupingChecker. > addInitialGroupingConstraints(GroupingChecker.java:292) > > which I think is where the time is spent (the depth varies during the start > period). > > Any takers on what is happening, and what we should do about it? > 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. 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?). This only happens if you have the "Bundle-ManifestVersion: 2" header to indicate you are using OSGi R4 bundle manifest syntax. This seems a bit problematic if it is the default setting for the tool. This is the old OSGi R3 way of doing things. In OSGi R3 every export also had a implicit import. While this is good in some scenarios it does prevent many important scenarios which OSGi R4 allows. In OSGi R4 exported packages are no longer implicitly imported. This allowed OSGi to greatly enhance to Framework to allow multiple versions of the same package to be exported at the same time by multiple bundles. If you always import every package you export then you will prevent multiple versions of the same package from being available in the system. 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. 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. 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. 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? Tom
