You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@celix.apache.org by pn...@apache.org on 2017/05/08 19:33:55 UTC
celix git commit: CELIX-402: Adds a draft for the roadmap
Repository: celix
Updated Branches:
refs/heads/develop e2ad48f87 -> 9b5bca43d
CELIX-402: Adds a draft for the roadmap
Project: http://git-wip-us.apache.org/repos/asf/celix/repo
Commit: http://git-wip-us.apache.org/repos/asf/celix/commit/9b5bca43
Tree: http://git-wip-us.apache.org/repos/asf/celix/tree/9b5bca43
Diff: http://git-wip-us.apache.org/repos/asf/celix/diff/9b5bca43
Branch: refs/heads/develop
Commit: 9b5bca43dda5ad47137d45a92900541f79c1d9c8
Parents: e2ad48f
Author: Pepijn Noltes <pe...@gmail.com>
Authored: Mon May 8 21:38:47 2017 +0200
Committer: Pepijn Noltes <pe...@gmail.com>
Committed: Mon May 8 21:38:47 2017 +0200
----------------------------------------------------------------------
documents/roadmap/improvement_ideas.md | 55 ---------------
documents/roadmap/roadmap.md | 106 ++++++++++++++++++++++++++++
2 files changed, 106 insertions(+), 55 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/celix/blob/9b5bca43/documents/roadmap/improvement_ideas.md
----------------------------------------------------------------------
diff --git a/documents/roadmap/improvement_ideas.md b/documents/roadmap/improvement_ideas.md
index ff71d11..1218106 100644
--- a/documents/roadmap/improvement_ideas.md
+++ b/documents/roadmap/improvement_ideas.md
@@ -1,22 +1,4 @@
# Improvement Ideas
-
-
-# Extend Dependency Manager C/C++
-The dependency manager offers declarative API for working with services and is arguable more easier
-to use than the official OSGi Api. Extend the DM so that in can be used for virtually any bundle
-without directly using the bundle context, bundle, module, service ref, service registration, etc API.
-This provided a much smaller API providing almost the same functionality.
-
-This means:
-1. Add support for service factory
-1. Add support for providing listener hooks. Note that this is already supported by registering
- a `listener_hook_service` service, but maybe a more abstracted way.
-1. Add support looking up and opening resources in the bundle.
-1. Replace add,remove, etc callbacks which uses the service reference, with callbacks using properties
-1. Test if the dm correctly works when adding / removing provided services and service dependencies after a component is started.
-1. Add support for bundle listener without needing the bundle.h API
-1. Add support for listing installed bundles without needing the bundle.h/bundle_context.h API
-1. Only required dependencies should be in celix_utils. This means: properties, lists, celix errors.
# Introduce dlmopen for library imports.
Currently library are loaded LOCAL for bundles. This works alright, but makes it hard to add a concept
@@ -31,23 +13,6 @@ libraries in a given namespace. For bundle this can be used to create a library
and load exported libraries int importing bundle namespace. A clean solution, but this currently
only works for glibc (linux).
-# Refactor service registry to a single threaded design
-Celix currently has some nested lock. It would be preferable to remove these, but this is difficult
-because they are used to sync events which react on registering/unregistering services. Specially when
-a unregister/register event leads to other services being registered/unregisterd. One way to deal with
-this sync problem is to remove it by adding a single thread which handle al interaction between bundles
-and the service registry.
-
-# Create dfi descriptor generator
-Create a descriptor generator which can parse type and service headers.
-This can be relatively easy achieved by (e.g.) using the libclang library.
-Also extend the CMake add_bundle command and create a CMake bundle_add_descriptors command to be able
-to add the descriptors to the bundle
-
-# Use dfi descriptor in service registrations/references
-When available dfi descriptors can be used in Celix to validate if service are compatible and
-in case of the provided service having more functions than the consumer needs, create a (cast to)
-a compatible consumer version.
# Fix the performance use case and add C++ support
There was a locking example which also functioned as a performance test to measure the impact of
@@ -60,32 +25,12 @@ See [locking example tree](https://github.com/apache/celix/tree/216032cae956379d
Celix is growing and getting more sub project, this is fine but maybe the structure needs a cleanup to
create a more clear root directory structure.
-# Add Support for running Celix as a single executable
-For different reasons it could be interesting to support running bundles from a single executable.
-Primarily security, but also startup performance.
-
-
-To start this can be achieved by creating static version of the celix provided bundles. These static
-bundles should have unique symbols, e.g shell_bundleActivator_create instead of a
-"normal" bundleActivator_create. The normal activator functions should then
-only be used (using a define or separated source file) when building a shared library bundle.
-A additional property (e.g. "cosgi.auto.static.start=shell, shell_tui") can be used to specify which
-symbol prefixes to use.
-
-Note that if this is implemented it would also be a good moment to add a compile option / launcher option
-to disable dynamic loading of libraries. This way shared library based bundles can be used during
-development, but for production a static executable with no capability to add bundles runtime
-could be used if preferable.
-
# Extend the test environment
# Improve documentation
# Create one or more "real life" applications based on Celix to show the potential of Celix
-# Investigate if in the pubsub admin the serialization and communication can be decoupled.
-Now an admin is responsible for serialization and communication.
-
# Add pub sub admins.
The current implementation uses JSON over multicast UDP or over ZMQ.
One or more could be added. i.e. serialization based on Apache-Avro, communication over TCP / Kafka / Shared Memory
http://git-wip-us.apache.org/repos/asf/celix/blob/9b5bca43/documents/roadmap/roadmap.md
----------------------------------------------------------------------
diff --git a/documents/roadmap/roadmap.md b/documents/roadmap/roadmap.md
new file mode 100644
index 0000000..2594800
--- /dev/null
+++ b/documents/roadmap/roadmap.md
@@ -0,0 +1,106 @@
+# Roadmap
+
+Note this roadmap is still a draft.
+
+# Apache Celix 2.0.1
+
+Date: TBD (juli/aug 2017?)
+
+## Improve PubSub (CELIX-407)
+
+1. Finalize introduction serializer services
+1. Ensure code coverage of ~ 70%
+
+## Finalize Runtime Creation (CELIX-408)
+
+1. Ensure that the runtime command are used for testing some distributed test (e.g. pubsub)
+
+## Add Support for running Celix as a single executable (TODO issue)
+For different reasons it could be interesting to support running bundles from a single executable.
+Primarily security, but also startup performance.
+
+To start this can be achieved by creating static version of the celix provided bundles. These static
+bundles should have unique symbols, e.g shell_bundleActivator_create instead of a
+"normal" bundleActivator_create. The normal activator functions should then
+only be used (using a define or separated source file) when building a shared library bundle.
+A additional property (e.g. "cosgi.auto.static.start=shell, shell_tui") can be used to specify which
+symbol prefixes to use.
+
+Note that if this is implemented it would also be a good moment to add a compile option / launcher option
+to disable dynamic loading of libraries. This way shared library based bundles can be used during
+development, but for production a static executable with no capability to add bundles runtime
+could be used if preferable.
+
+# Apache Celix 2.1.0
+
+Date: TBD (Jan 2018)
+
+Note a short comming is that there is still no good support for export and import libraries between
+bundles. For Linux dlmopen is a solution, but for a more broader UNIX support a more "creative"
+solution is needed (e.g. Just in time replacing the SONAME and NEEDED values in the respective shared libraries)
+
+## Extend Dependency Manager C/C++ (CELIX-409)
+
+The dependency manager offers declarative API for working with services and is arguable more easier
+to use than the official OSGi Api. Extend the DM so that in can be used for virtually any bundle
+without directly using the bundle context, bundle, module, service ref, service registration, etc API.
+This provided a much smaller API providing almost the same functionality.
+
+This means:
+1. Add support for service factory
+1. Add support for providing listener hooks. Note that this is already supported by registering
+ a `listener_hook_service` service, but maybe a more abstracted way.
+1. Add support looking up and opening resources in the bundle.
+1. Replace add,remove, etc callbacks which uses the service reference, with callbacks using properties
+1. Test if the dm correctly works when adding / removing provided services and service dependencies after a component is started.
+1. Getting framework properties (e.g. bundleContext_getProperty)
+1. Support for getting basic info from bundle (version, symbolic name, manifest)
+
+## Add framework services (TODO issue)
+Apache Celix is a framework for service oriented programming, this should also include for interacting with the
+framework itself. Create framework services for:
+
+1. bundle management: installing, Starting, Stopping, deinstalling, listing, etc bundles.
+1. service registry info: nr of service registered, nr of service listeners, etc.
+1. framework listenerL start, stop, error events (whiteboard)
+1. bundle listener: installed, start, stop, deinstalled events (whiteboard)
+
+## Support dependency manager from framework (TODO issue)
+Because the dependency manager is actual the preferred way to write bundles, this should be support
+like "normal" activators" directly from the framework without using a static library.
+
+## Refactor Celix provided bundles to use dependency manager and framework services (TODO issue)
+Refactor Celix bundles (shell, shell_tuu, RSA, etc) to use the dependency manager instead of a "vanilla"
+bundle activator. The dependency manager should be the preferred way to handle services.
+Also instead of directly using the API from bundle_context, bundle, module, etc the framework services
+should be used.
+
+## Create dfi descriptor generator (TODO issue)
+Create a descriptor generator which can parse type and service headers.
+This can be relatively easy achieved by (e.g.) using the libclang library.
+Also extend the CMake add_bundle command and create a CMake bundle_add_descriptors command to be able
+to add the descriptors to the bundle
+
+## Use dfi descriptor in service registrations/references (TODO issue)
+When available dfi descriptors can be used in Celix to validate if service are compatible and
+in case of the provided service having more functions than the consumer needs, create a (cast to)
+a compatible consumer version.
+
+# Apache Celix 3.0.0
+
+Date: TBD (aug 2018)
+
+## Remove support for "vanilla" bundle activators (TODO issue)
+When all Celix provided bundles are using the dependency manager and framework services support for
+the "vanilla" bundle activator can be dropped. Also a lot internals can be refactored because the public
+API should have shrunk quite a bit; This should lead to smaller code base -> less complex, easier to maintain
+and a smaller footprint.
+
+
+## Refactor service registry to a single threaded design (TODO issue)
+Celix currently has some nested lock. It would be preferable to remove these, but this is difficult
+because they are used to sync events which react on registering/unregistering services. Specially when
+a unregister/register event leads to other services being registered/unregisterd. One way to deal with
+this sync problem is to remove it by adding a single thread which handle al interaction between bundles
+and the service registry.
+