Hi, Richard S. Hall schrieb: > On 5/15/09 1:50 PM, Felix Meschberger wrote: >> Hi, >> >> Richard S. Hall schrieb: >> >>> We dynamically import * to avoid forcing all users of compendium to >>> satisfy all dependencies to use it, because most of the time they are >>> not needed for the contained service interfaces. However, in the cases >>> where they are needed, it is problematic. >>> >> >> IIRC the official bundle jars als have DynamicImport-Package, but maybe >> a bit more specific. I think we once had static imports which resulted >> in the bundle jars being unusable due to required dependencies (see your >> third point below). >> > > I am not saying that the official bundles will solve the issue, but at > least we can wash our hands of it since they are not our artifacts. > >>> Why do we provide these bundles at all? Originally, the OSGi JAR files >>> were not bundles, so we needed something and did it ourselves. Now this >>> is no longer the case, I believe. >>> >>> It seems we need to figure out what we should do to address such issues >>> in the future. I think there are three options: >>> >>> 1. Stop providing these bundles altogether and just rely on the >>> official artifacts from the OSGi Alliance (I believe they are in a >>> maven repo somewhere). >>> 2. Provide them with their full explicit dependencies (i.e., static >>> Import-Package declarations). >>> 3. Divide them up into more reasonable chunks, since they lack >>> cohesion as bundles which makes managing their dependencies more >>> unreasonable (e.g., it sucks having to deploy a provider of >>> javax.microedition.io for org.osgi.service.io when you just want >>> to use logging). >>> >>> At this point, I think the order of the options listed here is the order >>> of my preference. >>> >> >> I would apply the same order, though I don't particularly like number 2 >> due to the "hard" dependencies, unless those are declared optional. >> > > Optional dependencies are no better than dynamic ones in this case > because it will still allow the packages to be used without having their > _real_ dependencies resolved. The issue is that we are pretending the > dependencies are optional to avoid having to deal with resolving the > dependencies since it is a pain. A recipe for disaster. > >>> I talked to Tom Watson about this and he agrees, saying he thinks their >>> bundles are a mistake and doesn't plan on updating them. His recommended >>> approach for the future is to bundle the API with the implementations. >>> >>> Sounds good to me, since that's what we do too. What do you guys think? >>> >> >> I am split on this. Consider a logging bundle which exports the OSGi Log >> Service API. Almost all bundles will wire to that due to this. Then >> updating the log bundle will cause massive rewiring.... >> >> I don't think, that this is really the intent. So while I agree, that >> implementations should generally also export the respective official >> OSGi API, we might still want to have a specific "OSGi API bundle". >> > > Well, I think we already encourage people to do this and this was (is?) > recommended by the spec. You are correct, though, that it creates some > issues if you want to refresh. > > However, if you fix an impl detail in the impl bundle, then it is not > necessary to refresh the framework, since the older bundle revision will > still be exporting its API packages and the new revision can just wire > to those packages. The impl just needs to remember to export/import the > API packages. Then refreshing can happen at your leisure.
Ok, then I am also in favor of dropping it. Regards Felix > > -> richard > >
