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

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