me too. regards,
Karl On Fri, May 15, 2009 at 8:04 PM, Felix Meschberger <[email protected]> wrote: > 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 >> >> > -- Karl Pauls [email protected]
