On Wed, Sep 24, 2008 at 17:53, Stuart McCulloch [EMAIL PROTECTED] wrote:
2008/9/24 Yvan Royon [EMAIL PROTECTED]
The way I see it, an OSGi bundle tries to fit both granularities at
the same time.
Thus, it is up to the packager to choose one or the other, or a little
of both, and it can be
Sorry to bump a 4 month old thread...
On Mon, Jun 9, 2008 at 09:18, Peter Kriens [EMAIL PROTECTED] wrote:
The whole problem with modularity is the -granularity-. If you make the
granularity too small you end up with too many artifacts to comprehend.
If you make it too large you do not get the
2008/9/24 Yvan Royon [EMAIL PROTECTED]
Sorry to bump a 4 month old thread...
On Mon, Jun 9, 2008 at 09:18, Peter Kriens [EMAIL PROTECTED] wrote:
The whole problem with modularity is the -granularity-. If you make the
granularity too small you end up with too many artifacts to comprehend.
Or even something like Equinox's p2 support. It allows you to publish
bundles and collections of bundles and manage dependencies on arbitrary
capabilities and requirements. To a certain degree you can do similar
things with OBR it is just harder to create the metadata and the
capability
This is certainly an option if you are the author of both the client and
impl but for cases where there is a third party library with an api you
want to use it seems a little odd to include the third party lib in all
the client bundles?
Definitely more than one way to solve this which is
To expand on this train of thought as it's getting on towards of end of
day here in the UK so I feel the urge to talk to the wall ;)
The consideration when building bundles is how best to weight the
distribution of code between bundles is which code belongs together from
a client perspective.
Hmm. I like implementations that carry their interfaces. OSGi can handle
multiple implementations that carry the same API code. Refreshing might
then sometimes restart a bundle that could have been prevented but I
fail
to see that as a big drawback.
I think it is crucial that bundles run out
Concerning this...
Huh? If only com.bar is present than these dependencies exist anyway?
A:
Import-Package: com.foo
B:
Export-Package: com.foo
Import-Package: com.bar, com.baz
A will resolve to B. B has dependencies that are required to implement
com.foo. If I take
implementation C:
