Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prepare Celix 3.0.0 release #509

Open
23 of 42 tasks
pnoltes opened this issue Apr 3, 2023 · 3 comments · Fixed by #664, #663, #662, #665 or #666
Open
23 of 42 tasks

Prepare Celix 3.0.0 release #509

pnoltes opened this issue Apr 3, 2023 · 3 comments · Fixed by #664, #663, #662, #665 or #666
Assignees
Labels
component/framework Categorizes an issue or PR relevant to the framework. component/logging component/shell Categorizes an issue or PR relevant to the shell. component/utils Categorizes an issue or PR relevant to the utils. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt.
Milestone

Comments

@pnoltes
Copy link
Contributor

pnoltes commented Apr 3, 2023

For the next major version bump a lot deprecated functionality and functions can be dropped. Also some header files not meant for users should be made private.

An overview of the changes that should or can be done, before a Celix 3.0.0 release are:

  • Update CELIX_MAJOR (etc) to 3.0.0
  • Remove static dm libs
  • Change bundle cache dir scheme in v3
  • Remove CELIX_PROPERTIES_FOR_EACH
  • Remove deployment admin
  • Refactor C++ DependencyManager and remove setCSevice methods and not longer wanted SetCallbacks, etc
  • Remove C++11 support (dep man and C++11 dep man tests)
  • Add FRAMEWORK_EXPORT/UTIL_EXPORT to all public header functions
  • Remove installation of deprecated headers dir (libs/utils an libs/framework)
  • Rename non prefixed celix_ symbols from celix_ headers
  • Remove non celix prefixed function from cmake
  • Remove OSGI_ from celix_constants.h and remove old unused entries
  • Remove usage of cosgi.auto.start.0 etc from framework.c and celix_bundle_cache.c
  • Change delimiters in CELIX_AUTO_START_1 (etc) from " " to ","
  • Remove OSGI_FRAMEWORK_BUNDLE_UNKNOWN and other OSGI_ (no CELIX_) prefix enums
  • Refactor celix launcher and remove some of the functions
  • Remove USE_FILE32API from framework cmake target compile definitions
  • Remove add_celix_docker support from cmake
  • Remove add_celix_runtime support from cmake
  • Before release make all installed libs (including interface libs) not depend on deprecated headers
    • rsa_api
    • rsa_commons
    • pubsub_spi
    • pubsub_utils
    • pubsub_api
  • Update celix_types.h so that non prefixed celix_ typedef are removed to a celix_private_types.h
  • Update celix_api.h to not include non prefixed celix_ headers
  • Remove support for old log_service and shell service
  • Remove lang_c / lang_cxx from service registration/lookup in bundle context and dep manager
  • Remove deprecated functions from celix_array_list.h, celix_properties.h and other celix_ headers
  • Remove pubsub libs/bundles from celix (pubsub is not part of the OSGi specifications)
  • Remove C++17 (std::string_view) support from utils and framework and keep support on C++14.
  • Merge type support for properties #470 (updated properties)
  • Remove avpr support from dfi. Not stable and not used.
  • Check if embedded memstream can be removed from utils (not needed anymore for OSX)
  • Update doxygen for celix_bundleContext_useService (and C++ variant) to indicate that the callbacks can be called from the calling thread or the Celix event thread. This will give the option to changes to useService(s) function so that they directly work on the calling thread.
  • maybe update the rsa spi/api. Create api for the remote constants header, remove svc references and registrations from the rsa_spi.
  • Move celix_log.h header to framework src (private).
  • Remove celix_status struct from celix_errno.h
  • Remove some api in the celix_framework.h that is already available in celix_bundle_context to framework_private (minimize the public api)
  • Remove support for CELIX_DEPRECATED_FACTORY_SERVICE in service registration and upstream
  • Remove cpputest or replace them with gtest

Note that this does not mean that all deprecated functions/types usage (i.e. bundle_getState, etc) needs to be removed from Celix, but for a first 3.0.0 only that these functions / types are no longer useable downstream (so not useable for Apache Celix users)

@pnoltes pnoltes added kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. component/framework Categorizes an issue or PR relevant to the framework. component/shell Categorizes an issue or PR relevant to the shell. component/utils Categorizes an issue or PR relevant to the utils. component/logging labels Apr 3, 2023
@PengZheng
Copy link
Contributor

PengZheng commented Apr 4, 2023

  • Change bundle cache dir scheme in v3

It reminds me of the brainstorm we had in #441 (comment)

Now that #476 splits the cache and storage, the most straightforward way of supporting efficient sharing of bundles between multiple Celix instances is to add support for uncompressed bundle. This way, each framework instance has its own bundle cache like before, but for shared bundles, we extract them to someplace outside of bundle cache (maybe make them read-only), and then make symbolic links within the bundle cache to uncompressed shared bundles.

For containered/sandboxed APPs, we can mount folder containing uncompressed bundles read-only into the container/sandbox, and include the mount point into the bundle path, so that the framework within the container/sandbox can find them.

Our new celix_utils_deleteDirectory deals with symbolic links correctly, see TEST_F(FileUtilsTestSuite, DeleteSymbolicLinkToDirectory) in #476.

  • Remove FRAMEWORK_EXPORT (only needed for windows)

It's needed to perform binary footprint optimization for shared object. See #442
It's especially important for C++ bundles if they were to be deployed in devices with limited storage.
IMHO, we should use it universally in the whole Celix project, and encourage (and facilitate) our users to do the same.

  • Maybe (TBD) remove pubsub admins from celix (pubsub is not part of the OSGi specifications)

But OSGi does have Event Admin. The only problem I see with PSA is that it does not support zero-overhead in process communication like RSA: one socket per subscriber is too expensive for communication within the same process.

PSA(Event Admin)/RSA represent two typical inter-component communication styles. We could add support for Event Admin, which both support zero overhead in-process and efficient inter-process communication, or we add support of zero-overhead in-process communication to PSA and rename it to Event Admin.

Also it's worth noting that now service discovery for RSA/PSA(Event Admin) can be unified easily using dns-sd.

@PengZheng
Copy link
Contributor

As mentioned in #511, a crystal clear specification of the Celix component model or a reinterpretation of OSGi in the Celix context is very desirable.

@pnoltes
Copy link
Contributor Author

pnoltes commented Apr 9, 2023

I agree with adding a Celix EventAdmin. The event admin is part of the OSGi spec and I also think a remote event admin makes sense and is easier to use for users.

The main reason is that the current PubSub (and also the Remote Service Admin) needs extra manual work or codegen to be able to function. This manual work/codegen is needed to create DFI descriptors for serialization / remote invocation.
The event admin is based on properties and for properties serialization should be straightforward and can be done - for example - with reuse of the netstring implementation used in pubsub wire protocol.

I will add a separate issue for the event admin.

@pnoltes pnoltes self-assigned this Apr 14, 2023
pnoltes added a commit that referenced this issue Oct 1, 2023
pnoltes added a commit that referenced this issue Oct 1, 2023
pnoltes added a commit that referenced this issue Oct 1, 2023
pnoltes added a commit that referenced this issue Oct 1, 2023
@pnoltes pnoltes added this to the 3.0.0 milestone Oct 29, 2023
pnoltes added a commit that referenced this issue Oct 29, 2023
pnoltes added a commit that referenced this issue Nov 6, 2023
pnoltes added a commit that referenced this issue Nov 9, 2023
pnoltes added a commit that referenced this issue Nov 10, 2023
pnoltes added a commit that referenced this issue Nov 10, 2023
Also:
  - Add some clarification of when error messaged are pushed to celix err
    in the celix properties header documentation.
PengZheng added a commit that referenced this issue Dec 12, 2023
pnoltes added a commit that referenced this issue Feb 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component/framework Categorizes an issue or PR relevant to the framework. component/logging component/shell Categorizes an issue or PR relevant to the shell. component/utils Categorizes an issue or PR relevant to the utils. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt.
Projects
None yet
3 participants