Re: [e4-dev] Dependency Preference and Versioning

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

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 <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>

To	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
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
>> e4-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>   
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> 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
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev