Celix 0.0.1 release and Native-OSGI

[Alexander Broekhuis <a....@gmail.com>]

Hi all,

We would like to work towards a first release for Celix, and would like to
know what everyone thinks that has to be in there.

Please note, this is a 0.0.1 release, so take this into account when
considering items to be in there.

Some items I think that have to be fixed:
* API code style
  Currently the code doesn't follow the API style all over the place.
Personally I think this has to be fixed for the framework at least.
* Remote Import/ExportService header and disable the resolver
  Currently the resolver isn't needed at all, but is still "semi"-used.
This can be disabled (for now at least).
* Make build more modular
  As discussed on [1].
* Small updates to CMake files
  Currently several libraries are used directly, ie not via a
Find{LibName}. For these libraries a Find{LibName} module has to be written.
  Libraries that I know of; OpenSLP and Jansson

One last thing; we have started working on the NativeOSGi project, and one
of the goals is, is to let Celix use this API and be a reference
implementation. While I think this will be a great step forward for Celix,
I also think the work needed to get this done is quite a lot. As such I
would like to make a 0.0.1 release without following the NativeOSGi work.

A next release definitely will follow it, but having a first release is
really needed after  1.5 years.

What do you all think and what is missing for a 0.0.1 release?

[1]: http://incubator.markmail.org/thread/sb6w52z3jsug2ewr

-- 
Met vriendelijke groet,

Alexander Broekhuis

Re: Celix 0.0.1 release and Native-OSGI

[Sascha Zelzer <s....@dkfz-heidelberg.de>]

Hi,

great news! I completely agree with Pepijn. Cleaning up the project 
structure and making the build system more modular is in my opinion a 
top priority.

Best,

Sascha

On 06/11/2012 09:56 AM, Pepijn Noltes wrote:
> Hi
>
> On Thu, Jun 7, 2012 at 10:47 AM, Alexander Broekhuis
> <a....@gmail.com>  wrote:
>> Hi all,
>>
>> We would like to work towards a first release for Celix, and would like to
>> know what everyone thinks that has to be in there.
>>
>> Please note, this is a 0.0.1 release, so take this into account when
>> considering items to be in there.
>>
>> Some items I think that have to be fixed:
>> * API code style
>>   Currently the code doesn't follow the API style all over the place.
>> Personally I think this has to be fixed for the framework at least.
>> * Remote Import/ExportService header and disable the resolver
>>   Currently the resolver isn't needed at all, but is still "semi"-used.
>> This can be disabled (for now at least).
>> * Make build more modular
>>   As discussed on [1].
>> * Small updates to CMake files
>>   Currently several libraries are used directly, ie not via a
>> Find{LibName}. For these libraries a Find{LibName} module has to be written.
>>   Libraries that I know of; OpenSLP and Jansson
>>
>> One last thing; we have started working on the NativeOSGi project, and one
>> of the goals is, is to let Celix use this API and be a reference
>> implementation. While I think this will be a great step forward for Celix,
>> I also think the work needed to get this done is quite a lot. As such I
>> would like to make a 0.0.1 release without following the NativeOSGi work.
>>
>> A next release definitely will follow it, but having a first release is
>> really needed after  1.5 years.
>>
>> What do you all think and what is missing for a 0.0.1 release?
> I agree on all points and can't think of anything more we really need
> for the first release. IMO the main focus should be that people can
> build and therefore tryout Celix with at least a possible external
> dependencies, but - correct if I am wrong -  this will be adressed by
> making the build more module. So I have nothing to add to that list.
>
>
> Greetings,
> Pepijn

Re: Celix 0.0.1 release and Native-OSGI

[Pepijn Noltes <pe...@gmail.com>]

Hi

On Thu, Jun 7, 2012 at 10:47 AM, Alexander Broekhuis
<a....@gmail.com> wrote:
> Hi all,
>
> We would like to work towards a first release for Celix, and would like to
> know what everyone thinks that has to be in there.
>
> Please note, this is a 0.0.1 release, so take this into account when
> considering items to be in there.
>
> Some items I think that have to be fixed:
> * API code style
>  Currently the code doesn't follow the API style all over the place.
> Personally I think this has to be fixed for the framework at least.
> * Remote Import/ExportService header and disable the resolver
>  Currently the resolver isn't needed at all, but is still "semi"-used.
> This can be disabled (for now at least).
> * Make build more modular
>  As discussed on [1].
> * Small updates to CMake files
>  Currently several libraries are used directly, ie not via a
> Find{LibName}. For these libraries a Find{LibName} module has to be written.
>  Libraries that I know of; OpenSLP and Jansson
>
> One last thing; we have started working on the NativeOSGi project, and one
> of the goals is, is to let Celix use this API and be a reference
> implementation. While I think this will be a great step forward for Celix,
> I also think the work needed to get this done is quite a lot. As such I
> would like to make a 0.0.1 release without following the NativeOSGi work.
>
> A next release definitely will follow it, but having a first release is
> really needed after  1.5 years.
>
> What do you all think and what is missing for a 0.0.1 release?

I agree on all points and can't think of anything more we really need
for the first release. IMO the main focus should be that people can
build and therefore tryout Celix with at least a possible external
dependencies, but - correct if I am wrong -  this will be adressed by
making the build more module. So I have nothing to add to that list.


Greetings,
Pepijn

Re: Celix 0.0.1 release and Native-OSGI

[Pepijn Noltes <pe...@gmail.com>]

On Tue, Aug 7, 2012 at 11:27 AM, Alexander Broekhuis
<a....@gmail.com> wrote:
> Hi,
>
>
>>
>> I have created an alternative for making bundles which does not
>> depends on CPack.
>> IMO making bundles with CPack is messy, because it also results in
>> extra and often unwanted install rules and
>> I think that is preferable to have a make install command which works
>> as expected and not rely on user typing commands like:
>> "cmake -DCOMPONENT=framework -P cmake_install.cmake".
>>
>
> "As expected" is quite a stretch to say. Please don't confuse CMake with
> autotools/configure. They are 2 separate things.

True, but CMake generates a makefile with a install target. I prefer
that this install target works as expected.

>
>
>> I placed the logic for creating bundles without CPack in
>> cmake/Bundling.cmake.
>>
>> You can activate the bundling logic by changing the
>> cmake/Include.cmake file so that it will include Bundling.cmake
>> instead of Packing.cmake. In
>> device_access/device_access/CMakeLists.txt there are some - commented
>> out - example commands for adding files and marking a bundle for
>> install.
>>
>> Any comment on this would be great.
>>
>
> Even though I don't mind having an alternative, I do have some objections
> at this point of time. We basically said to work towards a first release
> and not make any big changes. Imo this is a big change.

Agreed, although I do think it is important to have a easy to
understand and working build and install target for a first release,
it is a big change and we should not delay a first release any more
that really necessary.

We can pick up the discussion after the first release ;)


>
> There are also several options missing, eg how can files be added? Besides
> that, the functions look overly complicated for such a simple thing. I'll
> have to look into detail to verify them.
>
> You tried to replace a basic function of CMake/CPack. Although I agree that
> currently the "make install" is a little awkward, for now I'd like to
> suggest to keep it the way it is.
>
> One other minor remark, you used FILE(GLOB..., to include header files.
> They are probably in some more places. For file inclusion it is ok, but
> take caution when doing the same to add source files. Using a GLOB breaks
> the dependency tracking of CMake.
>
> To summarize,
>
> I am ok with an alternative, but the macro's/functions should be more
> inline with all other macros (bundle_add uses a very strange way for
> parsing arguments). Also, these things require a discussion to get all
> details clear. Eg what does it support now and what should it support in a
> new solution? Let's please have that discussion before we start changing
> things. These are not minor changes!
>
> Finally, I don't think this is the right time to start messing with the
> bundling/installation.
> For both of us available time is limited, so having to test this thoroughly
> will delay a release even more.
> Let's focus on a release first!
>

Greetings,
Pepijn

Re: Celix 0.0.1 release and Native-OSGI

[Alexander Broekhuis <a....@gmail.com>]

Hi,


>
> I have created an alternative for making bundles which does not
> depends on CPack.
> IMO making bundles with CPack is messy, because it also results in
> extra and often unwanted install rules and
> I think that is preferable to have a make install command which works
> as expected and not rely on user typing commands like:
> "cmake -DCOMPONENT=framework -P cmake_install.cmake".
>

"As expected" is quite a stretch to say. Please don't confuse CMake with
autotools/configure. They are 2 separate things.


> I placed the logic for creating bundles without CPack in
> cmake/Bundling.cmake.
>
> You can activate the bundling logic by changing the
> cmake/Include.cmake file so that it will include Bundling.cmake
> instead of Packing.cmake. In
> device_access/device_access/CMakeLists.txt there are some - commented
> out - example commands for adding files and marking a bundle for
> install.
>
> Any comment on this would be great.
>

Even though I don't mind having an alternative, I do have some objections
at this point of time. We basically said to work towards a first release
and not make any big changes. Imo this is a big change.

There are also several options missing, eg how can files be added? Besides
that, the functions look overly complicated for such a simple thing. I'll
have to look into detail to verify them.

You tried to replace a basic function of CMake/CPack. Although I agree that
currently the "make install" is a little awkward, for now I'd like to
suggest to keep it the way it is.

One other minor remark, you used FILE(GLOB..., to include header files.
They are probably in some more places. For file inclusion it is ok, but
take caution when doing the same to add source files. Using a GLOB breaks
the dependency tracking of CMake.

To summarize,

I am ok with an alternative, but the macro's/functions should be more
inline with all other macros (bundle_add uses a very strange way for
parsing arguments). Also, these things require a discussion to get all
details clear. Eg what does it support now and what should it support in a
new solution? Let's please have that discussion before we start changing
things. These are not minor changes!

Finally, I don't think this is the right time to start messing with the
bundling/installation.
For both of us available time is limited, so having to test this thoroughly
will delay a release even more.
Let's focus on a release first!


-- 
Met vriendelijke groet,

Alexander Broekhuis

Re: Celix 0.0.1 release and Native-OSGI

[Pepijn Noltes <pe...@gmail.com>]

Hi All,

I committed some changes to the build system, see the rest of comments
for more details.

On Wed, Jul 11, 2012 at 12:26 PM, Alexander Broekhuis
<a....@gmail.com> wrote:
> Hi,
>
>>
>> Updated the build system. Added a FindJansson and FindSlp module and
>> adjusted the bundles using those libraries.
>>
>
> Looks good, though I'd like to suggest to use the find_package in the
> CMakeLists file when needed.

I agree and updated this.

>
> Also I noticed you use find_package, whereas previously I always used
> Include(FindXX). I think it is better to use find_package. So this is
> something that can be updated as well. (find_package provides more
> configuration options, whereas include doesn't have any at all).

I replaced all the include(FindXX) which i could find with find_package.

>
>
>> I noticed that "make install" install to unwanted files for bundles. I
>> will try to fix that the coming days.
>>
>
> Feel free to take a look at it, but be very careful changing stuff involved
> in installing. It is used to create the bundles.
>
> CMake's installation/packaging system (CPack) supports Components, this is
> used to group the correct files for one bundle. For each component a
> CMake/CPack installation config file is created. Calling CPack with on of
> these configs creates the bundle. See the Packaging.cmake for the macros.
> But using Makefiles, these components can't easily be provided, so when
> running a make install all files marked for installation are installed.
>
> All framework files are installed in the component "framework", so if it is
> possible to call the normal install command with a component (or overwrite
> it) this problem is solved.
>
> This can be done when executing the config file yourself, see [1], for
> Celix this would be: "cmake -DCOMPONENT=framework -P cmake_install.cmake".
> The "make install-fw" does almost the same, but packages the files in a zip
> file, this can easily be changed to install the files in the file system.
>
> This is also a reason why I'd like to split the build into several
> projects. The framework/utils and launcher are normal plain old libraries,
> which could (should?) be installed like any other system library/executable.
> All bundles are more specific, and related to a certain deployment. So a
> "normal" installation makes less sense in that case. With several projects,
> the normal make install would work again.
>
> So as mentioned before, tread lightly when trying to do something about
> this... Though a solution would be really great!

I have created an alternative for making bundles which does not
depends on CPack.
IMO making bundles with CPack is messy, because it also results in
extra and often unwanted install rules and
I think that is preferable to have a make install command which works
as expected and not rely on user typing commands like:
"cmake -DCOMPONENT=framework -P cmake_install.cmake".

I placed the logic for creating bundles without CPack in cmake/Bundling.cmake.

You can activate the bundling logic by changing the
cmake/Include.cmake file so that it will include Bundling.cmake
instead of Packing.cmake. In
device_access/device_access/CMakeLists.txt there are some - commented
out - example commands for adding files and marking a bundle for
install.

Any comment on this would be great.


>
> 2) IMO The Apache Celix binary, library and util library should be
>> renamed. The names are now bin/launcher, lib/libframework.so and
>> lib/libutils.so.  I think these names are to generic and will bring
>> confusing. Any thoughts ?
>>
>
> Agreed. How about:
>
> launcher -> celix
> libframework -> libcelix_framework
> libutils -> libcelix_utils
> lib{anythingelsewecomeupwith -> libcelix_{anythingelsewecomeupwith}
>
> For the include files I'd like to use /prefix_to_include/celix/*.h instead
> of the header files directly in the include directory.
>

I agree and the build system now does this.

Greeting,
Pepijn

Re: Celix 0.0.1 release and Native-OSGI

[Alexander Broekhuis <a....@gmail.com>]

Hi,

>
> Updated the build system. Added a FindJansson and FindSlp module and
> adjusted the bundles using those libraries.
>

Looks good, though I'd like to suggest to use the find_package in the
CMakeLists file when needed. For example, for remote services the
find_package is done in the overall CMakeLists file. It makes more sense to
place the find_package in the correct subdirectory. If, for some reason,
someone disables a certain subdirectory, the dependencies aren't needed
anymore as well. Now they always have to be installed.

This should probably also happen with several other libraries/find modules.
For example APR_UTIL.

Also I noticed you use find_package, whereas previously I always used
Include(FindXX). I think it is better to use find_package. So this is
something that can be updated as well. (find_package provides more
configuration options, whereas include doesn't have any at all).


> I noticed that "make install" install to unwanted files for bundles. I
> will try to fix that the coming days.
>

Feel free to take a look at it, but be very careful changing stuff involved
in installing. It is used to create the bundles.

CMake's installation/packaging system (CPack) supports Components, this is
used to group the correct files for one bundle. For each component a
CMake/CPack installation config file is created. Calling CPack with on of
these configs creates the bundle. See the Packaging.cmake for the macros.
But using Makefiles, these components can't easily be provided, so when
running a make install all files marked for installation are installed.

All framework files are installed in the component "framework", so if it is
possible to call the normal install command with a component (or overwrite
it) this problem is solved.

This can be done when executing the config file yourself, see [1], for
Celix this would be: "cmake -DCOMPONENT=framework -P cmake_install.cmake".
The "make install-fw" does almost the same, but packages the files in a zip
file, this can easily be changed to install the files in the file system.

This is also a reason why I'd like to split the build into several
projects. The framework/utils and launcher are normal plain old libraries,
which could (should?) be installed like any other system library/executable.
All bundles are more specific, and related to a certain deployment. So a
"normal" installation makes less sense in that case. With several projects,
the normal make install would work again.

So as mentioned before, tread lightly when trying to do something about
this... Though a solution would be really great!

Another interesting thread is: [2]

[1]: http://www.cmake.org/pipermail/cmake/2012-May/050465.html
[2]: http://www.cmake.org/pipermail/cmake/2007-July/015305.html


2) IMO The Apache Celix binary, library and util library should be
> renamed. The names are now bin/launcher, lib/libframework.so and
> lib/libutils.so.  I think these names are to generic and will bring
> confusing. Any thoughts ?
>

Agreed. How about:

launcher -> celix
libframework -> libcelix_framework
libutils -> libcelix_utils
lib{anythingelsewecomeupwith -> libcelix_{anythingelsewecomeupwith}

For the include files I'd like to use /prefix_to_include/celix/*.h instead
of the header files directly in the include directory.

This only applies to the system libraries, and not to the bundles.

-- 
Met vriendelijke groet,

Alexander Broekhuis

Re: Celix 0.0.1 release and Native-OSGI

[Pepijn Noltes <pe...@gmail.com>]

>>
>>> * Small updates to CMake files
>>>   Currently several libraries are used directly, ie not via a
>>> Find{LibName}. For these libraries a Find{LibName} module has to be written.
>>>   Libraries that I know of; OpenSLP and Jansson
>>>
>>
>> Still should be done. With the better build system, and the information now
>> on the website, it is much clearer what subprojects have what dependencies.
>> Fixing the Find modules is needed to get thinks working correctly.
>> Especially if some library is missing.
>>
>> Do any of you see other blocking items for a first release? If not, this is
>> a fairly limited list of items we need to do. Some help with this would be
>> really great!
>
> I'm willing to take up the Find libraries work. I'm still not very
> experienced with CMake so this gives me a excuse
> to remedy that ;)
>
> I will post an update if have some work done.

Updated the build system. Added a FindJansson and FindSlp module and
adjusted the bundles using those libraries.
I noticed that "make install" install to unwanted files for bundles. I
will try to fix that the coming days.

I noticed some things when installing Apache Celix ("make install"):
1) For bundles unwanted files (e.g. the manifest) are installed. I
will try to look into this the coming days.
2) IMO The Apache Celix binary, library and util library should be
renamed. The names are now bin/launcher, lib/libframework.so and
lib/libutils.so.  I think these names are to generic and will bring
confusing. Any thoughts ?

Greetings,
Pepijn

Re: Celix 0.0.1 release and Native-OSGI

[Pepijn Noltes <pe...@gmail.com>]

On Tue, Jul 3, 2012 at 10:56 AM, Alexander Broekhuis
<a....@gmail.com> wrote:
> Hi all,
>
> Some update on the progress towards a first release
>
> * API code style
>>
>
> No extensive work has been done on this one. I think we should consider to
> not do this for the first release. Or perhaps for only the framework
> itself. What do you guys think?

I agree with this.

>
>
>> * Remote Import/ExportService header and disable the resolver
>>   Currently the resolver isn't needed at all, but is still "semi"-used.
>> This can be disabled (for now at least).
>>
>
> Not yet done.
>
>
>> * Make build more modular
>>   As discussed on [1].
>>
>
> This is partially done, at least for a first release this is enough I guess.
>

I also agree that this is not needed for a first release.

>
>> * Small updates to CMake files
>>   Currently several libraries are used directly, ie not via a
>> Find{LibName}. For these libraries a Find{LibName} module has to be written.
>>   Libraries that I know of; OpenSLP and Jansson
>>
>
> Still should be done. With the better build system, and the information now
> on the website, it is much clearer what subprojects have what dependencies.
> Fixing the Find modules is needed to get thinks working correctly.
> Especially if some library is missing.
>
> Do any of you see other blocking items for a first release? If not, this is
> a fairly limited list of items we need to do. Some help with this would be
> really great!

I'm willing to take up the Find libraries work. I'm still not very
experienced with CMake so this gives me a excuse
to remedy that ;)

I will post an update if have some work done.

Greetings,
Pepijn

Re: Celix 0.0.1 release and Native-OSGI

[Alexander Broekhuis <a....@gmail.com>]

Hi all,

Some update on the progress towards a first release

* API code style
>

No extensive work has been done on this one. I think we should consider to
not do this for the first release. Or perhaps for only the framework
itself. What do you guys think?


> * Remote Import/ExportService header and disable the resolver
>   Currently the resolver isn't needed at all, but is still "semi"-used.
> This can be disabled (for now at least).
>

Not yet done.


> * Make build more modular
>   As discussed on [1].
>

This is partially done, at least for a first release this is enough I guess.


> * Small updates to CMake files
>   Currently several libraries are used directly, ie not via a
> Find{LibName}. For these libraries a Find{LibName} module has to be written.
>   Libraries that I know of; OpenSLP and Jansson
>

Still should be done. With the better build system, and the information now
on the website, it is much clearer what subprojects have what dependencies.
Fixing the Find modules is needed to get thinks working correctly.
Especially if some library is missing.

Do any of you see other blocking items for a first release? If not, this is
a fairly limited list of items we need to do. Some help with this would be
really great!

-- 
Met vriendelijke groet,

Alexander Broekhuis