FWIW, I agree with Sebastien and Rajini. I don't believe it's a coincidence that both SpringSource and ServiceMix went the route of adding manifests to the thirdparty jars. It keeps things simple and gives a better experience from an OSGi perspective. If we're serious about supporting OSGi we should try to do the right thing by the technology.
Whilst not necessarily an argument against virtual bundles, I also agree that we should have properly authored dependencies. This view is supported by the discussion Rajini is having in Jira 2343. I know for a fact that SpringSource work very hard to ensure the version ranges on their dependencies are sensible (e.g. match the rules governing version increments for each project). I don't believe we can completely do away with virtual bundles in the short term, but we should only use them where necessary (e.g for signed jars and jars which require code extensions to function in OSGi). Regards, Graham. 2008/5/29 Jean-Sebastien Delfino <[EMAIL PROTECTED]>: > Rajini Sivaram wrote: > >> There is no technical reason why we can't store 3rd party jars separately >> and merge them at runtime to create "virtual bundles", rather than >> distribute "real bundles" containing these manifests. I think the issues >> are: >> >> 1. The build will be harder and messier since existing tools are not >> geared to do this >> 2. The distribution will be messier from an OSGi perspective > > Agreed. How about keeping things simple and clean?? > >> 3. OSGi will continue to remain a peripheral feature of Tuscany, never >> properly integrated since this is not really mainstream. > > Agreed. > >> 4. Real bundles provide more flexibility to OSGi users in terms of >> substituting 3rd party jars with newer or patched versions of these, as >> well >> as avoiding classloading conflicts resulting from version constraints. >> > > Good point too. > > My 2c: Generating bundles automatically from JARs is useless. If you want to > leverage OSGi you need to make authoring / fine tuning your imports/exports > a first class part of your development process. > > I'm starting to feel like a broken record, so I'm going to say it one last > time, for the record. I think we should just follow a simple approach and > add proper (authored) OSGi entries to our JARs and 3rd party dependency > JARs. This doesn't multiply distros, doesn't duplicate JARs, does not > complicate the build. It just makes simple sense IMHO, and other projects > with experience with OSGi are on that path too. > > -- > Jean-Sebastien >
