Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] Dependency Preference and Versioning

I skipped this discussion earlier (been there, argued that), but I don't think there is broad consensus that require-bundle is bad. We have been using package-granularity imports/exports in Equinox and my experience is that it leads to an order of magnitude more complexity with very little gain. The end result is that we have a large number of imports and exports with no version numbers, because nobody has the time to manage the package versions (API tools doesn't support package versions yet AFAIK). This in the end is much worse than using bundle-level granularity with well managed version numbers and ranges.

If you have bundles with completely unrelated API packages that you want to allow clients to consume separately, then splitting them into separate bundles is the way to go. That way clients using require-bundle get the same level of granularity as they would by using import-package. Where import-package introduces unnecessary work is in bundles containing a collection of tightly related packages that were never intended to be used/implemented independently. The interdependencies between the classes in those packages often make finer-grained reuse or reimplementation impossible. In cases like this using package-level imports/exports just adds extra work with no benefit.

There seems to be a perception that switching to package-granularity imports/exports will automatically enable finer-grained reuse and looser coupling. In fact the granularity of reuse needs to be designed right into the code for it to work. We were only able to split org.eclipse.core.runtime into separate bundles because we had done a reasonable job of keeping concerns separated in the implementations of the various packages from the start. In retrospect of course we should have put unrelated functionality into separate bundles right from the start. Now that each API package is in its own bundle, there is no interesting distinction between bundle/package granularity imports when using them.

I do think import-package is a powerful mechanism that we should use where appropriate. In particular, if a package has been well designed for package granularity reuse, and is versioned appropriately indepently from its container, then using import-package makes complete sense. This holds especially for the OSGi packages, which were designed from day one with package granularity and multiple independent implementations in mind. For bundles containing multiple packages that were designed to act closely together (most existing Eclipse platform bundles), I see little or no benefit. As noted in earlier replies, since clients can use require-bundle we can't move packages around between bundles anyway.


Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>
Sent by: e4-dev-bounces@xxxxxxxxxxx

02/05/2009 01:32 PM

Please respond to
E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>

E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
Re: [e4-dev] Dependency Preference and Versioning


I don't know whether we have thought about this already but the
discussion and the conclusion that Require-Bundle is bad make it
necessary that we provide people a possibility to use import-package in
the 3.x appropriately by versioning our packages!

One can currently use import package against 3.x bundles but can't
define a version so it renders it quite senseless. I think most of the
runtime-project already version their packages but e.g. at platform-ui
bundles we don't which is bad. I'd for example like to use import
package to use the databinding libs but I need to stay with
Require-Bundle because I can't define a version.


Jeff McAffer schrieb:
> People who use Require-Bundle are doing so at risk of having to change
> their manifests later if packages move.  We had all manner of "facading"
> going on in the 3.0 timeframe because Require-Bundle is all you had
> before then.  That was 5 years ago.  Would be great if we got with the
> program and started supporting/using Import-Package more.
> As for the Java centricness of all this...  OSGi is a Java technology.
> At least currently.  As Tom Watson alluded to in another post, there is
> a mechanism in Equinox for expressing generic capabilities and
> requirements.  this can be used to talk about non-Java things in a
> pretty comprehensive way.  That is not currently supported by p2 but its
> just the translation that is missing. p2 is completely based on generic
> capabilities.
> As for require-bundle and extension points, NO.  This is one of the
> "great myths" of Eclipse.  for the most part OSGi only knows/cares about
> classloading.  The bundle contributing an extension that identifies a
> class is asked to load that class using normal classloading mechanisms.
> Jeff
> Boris Bokowski wrote:
>> Tom Schindl wrote on 01/14/2009 12:31:32 PM:
>> > ....
>> > > Yes, whenever you move packages between bundles, the original
>> bundle has
>> > > to Require-Bundle the new one and re-export it.
>> > >
>> >
>> > But this is not needed if I use Import-Package because then OSGi handles
>> > this for me or am I completely mistaken?
>> You are right, clients who use Import-Package are not affected. But
>> since there is no way of stopping clients from using Require-Bundle to
>> depend on your bundle, you will have to do the re-export.
>> All of this still feels too Java-centric to me...
>> Boris
>> ------------------------------------------------------------------------
>> _______________________________________________
>> e4-dev mailing list
>> e4-dev@xxxxxxxxxxx
> ------------------------------------------------------------------------
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx

B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
tom schindl                               leiter softwareentwicklung/CSO
eduard-bodem-gasse 8/3    A-6020 innsbruck      phone    ++43 512 935834
e4-dev mailing list

Back to the top