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. John Tom Schindl <[email protected]> Sent by: [email protected] 02/05/2009 01:32 PM Please respond to E4 Project developer mailing list <[email protected]> To E4 Project developer mailing list <[email protected]> cc Subject Re: [e4-dev] Dependency Preference and Versioning Hi, 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. Tom 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 >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/e4-dev >> > > ------------------------------------------------------------------------ > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev -- 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 [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
