Hi,
2013/6/12 Sascha Zelzer <[email protected]>
> 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.
cm/
c/
private/
include/
src
public/
include/
configuration_admin.h
src
cpp/
private/
include/
src
public/
include/
osgi/cm/ConfigurationAdmin.hxx
src
>
> 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
