Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] GSOC 2014

hi scott,

thank you for the reply with such detail. it seems like most of the ECF projects using OSGI modularity so i thought i should start with studying about osgi modularity[1][2] and get familiar with bugs that you shown above.


Best regards,

On Wed, Mar 5, 2014 at 3:31 AM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
Hi Sakith,

First, thanks for expressing your interest, and willingness to contribute/participate.

On 3/4/2014 9:12 AM, sakith indula wrote:
Dear All,

I am a third year undergraduate  at Department of Computing and information System, Sabaragamuwa University of Sri Lanka[1] and intending to take part in GSoC 2014 for the first time.I am very much interested to contribute myself to Eclipse ECF as a project for GSoC 2014.also I have expertise in following areas.

Object oriented programming
Data Structures and Algorithms 
Java Design patterns

Basically I am doing programming with Java therefor I have a advance knowledge with programming in Java also I have experience with programming in  C++ and C#.I am interested in doing one of your  Advanced Projects..

Your background provides you with a good start.  Some areas that are directly related to ECF...that you may wish to learn about:

1) OSGi (e.g. modularity, services, versioning, dynamics)
2) Distributed systems and messaging (e.g. inter-process communication (IPC)/remote procedure call (RPC), various types of protocols...e.g. network-based discovery, mqtt, jms, etc, threading/concurrency)
3) Eclipse (e.g. Plugin Development Environment/PDE, JDT, DS tooling, etc)
4) Continuous Build/Test/Release Engineering technologies (e.g. Jenkins, Junit, etc)

And then there is ECF specifically :) (see below).

I went through the papers and slides in the [3] in eclipse-ECF wiki site and some related articles i found[4].It is very helpful if any one can provide some information about the is there any project ideas are available for this year GSOC.

The work in spring/summer 2014 is likely to be primarily in the following areas of ECF (This is my personal view...i.e. these are things that I personally expect to work on.  Other ECF contributors and/or committers may have other ideas as well, and I encourage them to speak up with their thoughts on ideas...and to place these on the GSOC Ideas page [9] as well)

A) Implement OSGi R6 specification.  Specifically...OSGi Remote Services (chap 100) and Remote Service Admin (chap 122).   This is going to consume a lot of my available effort.  ECF already has a fully compliant implementation of these specs, but in R6 things are being added, and these additions have to be implemented, tested, etc., etc.  Here's the overarching bug for this work [1].  I know a standard may not sound like very exciting work for a GSOC project :), but there are some interesting things that could be done for GSOC as this work goes on:

    a) Create a distributed 'junit-like' framework for testing and debugging remote services.  In my view, this is potentially a very valuable thing for the OSGi Remote Services community, as since remote services are inherently based upon multiple processes+network communication, a test framework for such a thing has yet to emerge.
    b) New Eclipse-based tooling for helping people create, test, debug, document, and deploy OSGi Remote Services.  ECF currently has several tutorials and remote services examples, but more are needed...and if some additional Eclipse-based tooling were created/made available, it would be great to provide more tutorial-style documentation that uses that improved tooling.

B) Creating new discovery and remote services providers and/or updating existing ones
    a) Discovery:  We need to update some existing providers ...e.g. [2], and there may be other discovery providers [3] that could use some work (I'm not the lead committer for these parts of ECF, so Markus, Wim, and others may have more specific direction here.
    b) Remote Services.   We already have quite a need for new providers...e.g. [4], and we have even more need for additional documentation/examples/tutorials (and test framework) for creating providers...e.g. [5].   This is a big deal IMHO, as we are trying to move from creating most of these provider implementations ourselves to making possible (and as easy as possible) for others to create new discovery and remote service providers for themselves (potentially based upon existing ones...or from 'scratch').
    c) We have a number of providers...e.g. based upon xmlrpc, javagroups/jgroups, Restlet, MQTT, and others at github [6]...many of which are in need of updating (in line with work with A).  Further, it would be great if we could get more of these existing providers into the ECF automated build-and-test...which currently runs the OSGi RSA compatibility test suite on a subset of all the discovery and distribution providers.

C)  Make OSGi Remote Services available via other languages and frameworks.  For example, we already have underway an effort to connect Python/iPopo and Java-based remote services...e.g. [7].

D) Help may our OSGi Remote Services implementation more easily consumable (and testable) by non-Equinox OSGi frameworks...e.g. Felix and/or others.   We already do some things here...e.g. we build both p2 and maven repos, and we create karaf features for consumption based upon Apache Karaf.  But there is more to do.

E) We've had previous GSOC projects that haven't yet been fully integrated into ECF and deployed.   I would like to see the work on some of these continue and be completed for full inclusion into ECF.

F) Then there are lots of other parts of ECF (not directly related to OSGi Remote Services) that could be worked on.  For example, we provide an extensible real-time shared editor for Eclipse called 'cola' [10] that could use new additional work.

I haven't yet had a chance to create ECF based entries on the Eclipse GSOC Ideas page...i.e. [9].   But I will work on boiling down the above to a few sentences and put them into [9].   Since you (Sakith) asked on the ecf-dev mailing list, you get the 'full dump' version...prior to editing :).



ecf-dev mailing list

Back to the top