celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Broekhuis <a.broekh...@gmail.com>
Subject Re: Multiple library support and code sharing
Date Tue, 04 Mar 2014 20:10:00 GMT
Hi,

2014-03-04 20:42 GMT+01:00 Gerrit Binnenmars <gerritbinnenmars@gmail.com>:

> 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]: https://issues.apache.org/jira/browse/CELIX-111
>> [2]: https://issues.apache.org/jira/browse/CELIX-112
>>
>>
>


-- 
Met vriendelijke groet,

Alexander Broekhuis

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message