incubator-celix-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r811579 - in /websites/staging/celix/trunk/content: ./ celix/community/boardreports/boardreports.html
Date Thu, 05 Apr 2012 06:50:50 GMT
Author: buildbot
Date: Thu Apr  5 06:50:49 2012
New Revision: 811579

Log:
Staging update by buildbot for celix

Modified:
    websites/staging/celix/trunk/content/   (props changed)
    websites/staging/celix/trunk/content/celix/community/boardreports/boardreports.html

Propchange: websites/staging/celix/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Thu Apr  5 06:50:49 2012
@@ -1 +1 @@
-1309669
+1309670

Modified: websites/staging/celix/trunk/content/celix/community/boardreports/boardreports.html
==============================================================================
--- websites/staging/celix/trunk/content/celix/community/boardreports/boardreports.html (original)
+++ websites/staging/celix/trunk/content/celix/community/boardreports/boardreports.html Thu
Apr  5 06:50:49 2012
@@ -113,36 +113,41 @@ For these meetings a board report must b
 <p>Celix entered incubation on November 2, 2010.</p>
 <p>The last month we received or first large code donation, the code still has to be
added to the project. This code is an implementation of the OSGi Device Access specification
for Celix and has been made by Thales Netherlands. Together with this donation a new committer
(Pepijn Noltes) is accepted. Pepijn has developed and will maintain the Device Access code.</p>
 <p>We have also been working on a graduation plan which is included below.</p>
-<p>Most important issues are:
-<em> Improve robustness (APR, error handling etc), resulting in a first release
-</em> Update/Implement remote services for interoperability with Java OSGi (Apache
Felix)
-* Generate awareness and grow a community!</p>
+<p>Most important issues are:</p>
+<div class="codehilite"><pre><span class="n">Improve</span> <span
class="n">robustness</span> <span class="p">(</span><span class="n">APR</span><span
class="p">,</span> <span class="n">error</span> <span class="n">handling</span>
<span class="n">etc</span><span class="p">),</span> <span class="n">resulting</span>
<span class="n">in</span> <span class="n">a</span> <span class="n">first</span>
<span class="n">release</span>
+<span class="n">Update</span><span class="o">/</span><span class="n">Implement</span>
<span class="n">remote</span> <span class="n">services</span> <span
class="k">for</span> <span class="n">interoperability</span> <span
class="n">with</span> <span class="n">Java</span> <span class="n">OSGi</span>
<span class="p">(</span><span class="n">Apache</span> <span class="n">Felix</span><span
class="p">)</span>
+<span class="n">Generate</span> <span class="n">awareness</span>
<span class="ow">and</span> <span class="n">grow</span> <span class="n">a</span>
<span class="n">community</span><span class="o">!</span>
+</pre></div>
+
+
 <p>Graduation Plan</p>
 <p>Celix is in incubation since November 2010. During the first one and a half year
talks where given at several conferences (EclipseCon, ApacheCon, OSGi User Group meetings,
etc).
-Even though there seems to be an interest in the project, two important questions keep coming
up:
-- What is the state of the project?
-- Why no support for C++?</p>
+Even though there seems to be an interest in the project, two important questions keep coming
up:</p>
+<ul>
+<li>What is the state of the project?</li>
+<li>Why no support for C++?</li>
+</ul>
 <p>Trying to answer/solve these two questions might make it able to attract more community
members. So this plan will focus mostly on these two items.</p>
 <p>= State of the project</p>
-<p>== Releases
-Celix entered incubation in its early stage. There was only a proof of concept, but no complete
implementation. 
+<p>== Releases</p>
+<p>Celix entered incubation in its early stage. There was only a proof of concept,
but no complete implementation. 
 This is an important reason for people to hold back and not yet use/improve Celix, on the
other hand,  being hesitant also keeps Celix from growing towards a more stable/robust solution.
 To be able to use Celix the implementation has to reach, at least, a more stable state. Over
the past year lots of effort has been put into this.
 Within the next half year a release has to be made of the core component of Celix. Hopefully
this will attract more users/testers (and potentially committers).
 Since a formal release takes quite some effort, it might also make sense to provide snapshots
(with documentation) to be able to reach more people.</p>
-<p>== Committers
-During the last months there has been an interest from Thales Netherlands to use Celix in
its middleware. In a research project they are working on an implementation of the Device
Access specification. This implementation is donated to Celix, and the main developer has
expressed the intention to maintain the code base. Via this path a new committer has been
added to Celix <a href="http://markmail.org/message/q4n7562jvngd33s5">1</a>.
+<p>== Committers</p>
+<p>During the last months there has been an interest from Thales Netherlands to use
Celix in its middleware. In a research project they are working on an implementation of the
Device Access specification. This implementation is donated to Celix, and the main developer
has expressed the intention to maintain the code base. Via this path a new committer has been
added to Celix <a href="http://markmail.org/message/q4n7562jvngd33s5">1</a>.
 But to be able to have a diverse community more committers are needed.
 Having a release makes it easier for people to use and improve Celix. This is one step towards
more committers.</p>
-<p>== Technical state
-One of the important aspects of Celix is interoperability with Java OSGi through remote services.
Currently Celix has basic support for Celix to Celix remote services, following the Remote
Service Admin specification of OSGi. This implementation has to be improved and extended to
comply better to the specification. Also a Java OSGi implementation has to be made which can
interact with the Celix implementation. Some existing opensource solutions are available,
but are either to large for our intended target platforms or rely on to many other libraries
(for example XML handling etc). To be able to have an implementation which fits the environment
((de)serialization and protocol) it makes sense to implement a simple solution ourselves.
+<p>== Technical state</p>
+<p>One of the important aspects of Celix is interoperability with Java OSGi through
remote services. Currently Celix has basic support for Celix to Celix remote services, following
the Remote Service Admin specification of OSGi. This implementation has to be improved and
extended to comply better to the specification. Also a Java OSGi implementation has to be
made which can interact with the Celix implementation. Some existing opensource solutions
are available, but are either to large for our intended target platforms or rely on to many
other libraries (for example XML handling etc). To be able to have an implementation which
fits the environment ((de)serialization and protocol) it makes sense to implement a simple
solution ourselves.
 Having functional remote services makes it easier to use Celix in a mixed Java/C environment.
This solution can also be positioned as an alternative to JNI with the benefit that the Java
and C components are separate processes. If either one crashes the other part is kept running,
resulting in a more robust solution.</p>
 <p>= C++ Support</p>
-<p>== Technical Scope
-Currently Celix is limited to C only. This was a deliberate choice since Celix tries to target
 embedded/constrained platforms. But during talks people also seem to be interested in C++
support. Extending the technical scope of the project might attract more users and committers.
+<p>== Technical Scope</p>
+<p>Currently Celix is limited to C only. This was a deliberate choice since Celix tries
to target  embedded/constrained platforms. But during talks people also seem to be interested
in C++ support. Extending the technical scope of the project might attract more users and
committers.
 Over the next half year we will work out a plan how C++ support can be added without impacting
the current supported platforms. A start with the discussions has been made on the mailinglist,
see <a href="http://markmail.org/message/q4n7562jvngd33s5">2</a> for more information.</p>
-<p>== Cooperate with existing C++ OSGi like implementations
-In <a href="http://markmail.org/thread/a3qltqhsocmrnerd">3</a> a list of similar
projects is mentioned. Reaching out to these projects and trying to find a common ground on
requirements/API etc could benefit Celix (and those projects as well). 
+<p>== Cooperate with existing C++ OSGi like implementations</p>
+<p>In <a href="http://markmail.org/thread/a3qltqhsocmrnerd">3</a> a list
of similar projects is mentioned. Reaching out to these projects and trying to find a common
ground on requirements/API etc could benefit Celix (and those projects as well). 
 To see if there is a common ground we need to contact those projects and plan a meeting.</p>
 <p>Signed off by mentor:</p>
 <h2 id="2012-01"><a href="http://wiki.apache.org/incubator/January2012">2012-01</a></h2>



Mime
View raw message