I agree with much of what John has said here. If I may
summarize/re-iterate:
- There is no one right answer. Do the right thing
- If you are talking about tightly coupled implementation, messing
with package imports likely is not a win
- OTOH, SPI and multi-impl scenarios are ideal for package level
dependencies
- Managing version numbers is hard. Versioning packages means more
numbers to manage. API tooling would make this easier
- Good choice of packaging is important up front to enable refactoring
bundles later on
- we actually did a relatively poor job of this IMHO in the runtime
in the beginning.
That is why org.eclipse.core.runtime is now split over three
bundles.
Keep your concerns in separate bundles.
- Whatever patterns we see in Eclipse today are likely the product of
some time ago. They may or may not be appropriate for e4.
Jeff
John Arthorne wrote:
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
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
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
|
