incubator-celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Broekhuis <>
Subject Re: [Native-OSGi] Progress update
Date Wed, 26 Jun 2013 08:32:04 GMT

2013/6/12 Sascha Zelzer <>

> Hi,
> I just wanted to confirm that I think moving forward with the Celix
> project and extending it to support C++ is an important step.

Great to hear this!

> To get started, we should probably discuss the directory layout of the
> Celix code repository. With respect to a (hypothetical) C/C++ OSGi spec, we
> could first try make the distinction between interfaces and implementation
> apparent at the directory level.  A first (incomplete) shot of mine trying
> to cope with these new requirements looks like this:

I'd like to take some smaller steps in this, and start with a "new"
directory for the Native-OSGi compliant implementation. Some reasons are:
* Celix relies on APR all over the place, also on the API level. This was
an explicit choice when we made it. Moving to Native-OSGi breaks the
current Celix API.
* We have a (small) userbase using Celix, I would like to keep the current
codebase supported for them, see above point.
* Creating a new subproject gives us the opportunity to work on it and
breaking stuff, without to much impact on the current Celix source.

> cmake
>  ...
> framework/  <-- current Celix C implementation
> framework++/  <-- new Celix C++ stuff
>   |---- wrapped/  <-- C++ implementation using the existing C impl.
>   L---- native/   <-- independent C++ implementation (for experimentation)
>  ...
> osgi/
>  |---- framework/
>  |      |---- include/
>  |      |      L---- osgi/
>  |      |             |---- BundleContext.hxx   <-- C++ interface
>  |      |             L---- bundle_context.h  <-- C interface
>  |      L---- src/
>  |---- cm/
>  |      |---- include/
>  |      |      L---- osgi/
>  .      |             L---- cm/
>  .      |                    |---- ConfigurationAdmin.hxx
>  .      |                    L---- configuration_admin.h
>  -      L---- src/

This layout looks good, but I'd like to see is to make "framework" the new
Celix C implementation which is Native-OSGi compliant.

> I tried to just add stuff on top of the existing repository to keep the
> impact low. With the second-level dirs, we could also add more
> sub-directories by e.g. having "c" and "cpp" folders below osgi/framework/
> , but I thought trying to keep the hierarchy from getting too deep is
> better. We would still have to figure out how C and C++ implementations of
> service specifications could be marked as such and distinguished from each
> other (as long as these implementations are not contained in their own
> repository).

I'd like to follow the Celix directory layout a bit more and also use the
public and private directories. This gives a good sense as to what should
be exported and what not (wrt osgi metadata, but also wrt including and
building). Also, I do think have a c and cpp folder makes sense. That way
it is immediately clear in what language(s) a module is implemented.

Also, in your example you have eg "osgi/cm/include/osgi/cm", is the second
"osgi/cm" needed? For C it is an unneeded duplication, and it doesn't add
any extra information. It is already placed in the "osgi/cm" directory, so
why use it again?
Has it to do with C++ namespaces? If so, I'd like to split the h and hxx
files into own directories, this keeps the namespace specific for C++ and
doesn't make C use paths to include files.

I prefer the language directory on a higher level, if a certain module
doesn't have a c (or cpp) implementation or doesn't have any private files,
the directory isn't needed. Adding it later on doesn't have an impact on
the already existing directories etc.


> I would be more than happy to contribute the work done in the Native OSGi
> directory so far (especially the C++ interfaces [1]).

If the others agree, I'd like to use that contribution as a means to make
you committer ;). So yeah, I'd like to that code moved to Celix.

Met vriendelijke groet,

Alexander Broekhuis

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