celix-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From pnol...@apache.org
Subject celix git commit: CELIX-402: Adds a draft for the roadmap
Date Mon, 08 May 2017 19:33:55 GMT
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 <pepijnnoltes@gmail.com>
Authored: Mon May 8 21:38:47 2017 +0200
Committer: Pepijn Noltes <pepijnnoltes@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.
+


Mime
View raw message