incubator-celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerrit Binnenmars <>
Subject Re: Multiple library support and code sharing
Date Wed, 05 Mar 2014 20:51:52 GMT
Alexander Broekhuis schreef op 4-3-2014 21:10:
> Hi,
> 2014-03-04 20:42 GMT+01:00 Gerrit Binnenmars <>:
>> Hello Alexander,
>> This is a quite interesting development. Regarding issue 111 the
>> difference between Private-Library and Import-Library is not exactly clear
>> to me.
>> More explicit: why is Private-Library needed and can't Import-Library not
>> be used always?
> Basically there are 2 types of libraries (in java 2 types of packages),
> private and exported. In the OSGi specification private packages aren't
> explicitly mentioned because by default all classes of a bundle are on the
> bundle's private classpath.
> Exported libraries need to be mentioned explicitly, this makes it possible
> to specify what is exported and also a possibility to add additional
> information. For now Celix will only support the version attribute. This
> version is important to be able to build a correct library path with
> libraries that can actually work together. Also the use of versions will
> make it possible to have multiple versions of a certain library in a
> running system without runtime issues because the resolver will find the
> matching version. This does imply that the version and ranges need to be
> declared correctly.
> Since libraries can be exported, on the other hand some bundle needs to
> specify it wants to use such library, hence the import statement. So the
> Import-Library statement is needed to declare libraries that the bundle
> wants to use, but are not provided by that bundle itself. To be able to use
> versions, the import statement can also specify a version(range) declaring
> the version the exported library should have.
> So to summarise:
> - Private-Library: lists libraries only for use by the bundle itself.
> - Export-Library: lists libraries for use by the bundle itself, but also to
> anyone else importing it.
> - Import-Library: lists libraries that are exported by another bundle and
> that the bundle itself wants to use.
> So always adding private libraries to the imports doesn't work because then
> there needs to be some bundle exporting them (this can be the same bundle
> btw). And if a bundle exports something, anyone else can use it. So this
> would basically break the mechanism where private libraries would be hidden
> for others.
> So for example, lets say there are 2 components, 1 server and 1 client. The
> server exposes an interface with some data types. The client can use that
> service.
> Currently providing a service already works, and the client can use that
> service. But if the service wants to provide some datatype, the client also
> needs to be linked to some library providing the datatype.
> So in the new setup, besides the server header describing the service,
> there would be (at least) 3 libraries:
> * Server component
> * Server datatypes
> * Client component
> Bundling these libraries would result in:
> * Server bundle
>    Private: Server component (included in this bundle)
>    Exported: Server datatypes (included in this bundle)
> * Client bundle
>    Private: Client component (included in this bundle)
>    Imported: Server datatypes (NOT included in this bundle)
> Altogether this is more or less also how the packages in Java OSGi work,
> and we want to try to follow the osgi specification as close as possible.
> I hope this makes it a bit clearer as how I think it can be solved.
>> Greetings Gerrit
>>   Hi all,
>>> One of the biggest missing features from Celix is code sharing. To start
>>> work on this, I've created 2 jira isseus [1],[2].
>>> Can you guys take a look at those and comment on them? I already have some
>>> code in a local branch which works, but I'd still like to discuss it since
>>> any other insights might be useful and result in changes.
>>> [1]:
>>> [2]:
Thanks Alexander for this large explanation!

View raw message