felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Kriens (JIRA)" <j...@apache.org>
Subject [jira] [Assigned] (FELIX-2899) [GSoc 2011]Bndtools based OSGi bundles maker project
Date Thu, 31 Mar 2011 06:34:05 GMT

     [ https://issues.apache.org/jira/browse/FELIX-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Peter Kriens reassigned FELIX-2899:
-----------------------------------

    Assignee: Peter Kriens

Will act as mentor to this project

> [GSoc 2011]Bndtools based OSGi bundles maker project
> ----------------------------------------------------
>
>                 Key: FELIX-2899
>                 URL: https://issues.apache.org/jira/browse/FELIX-2899
>             Project: Felix
>          Issue Type: Task
>         Environment: Eclipse platform, this project add a new tool for Felix users to
improve OSGi bundles development process in Eclipse environment
>            Reporter: Tiger Gui
>            Assignee: Peter Kriens
>              Labels: gsoc, gsoc2011, mentor, mentoring
>   Original Estimate: 1680h
>  Remaining Estimate: 1680h
>
> OSGi(Open Service Gateway Initiative) is a worldwide consortium of technology innovators
that advances a proven and 
> mature process to create open specifications that enable the modular assembly of software
built with Java technology.
> It is becoming more and more popular in Java Desktop or Web application developmenent
especially when we are working on 
> some huge project, as it is growing more and more complex, OSGi can help us.Developing
with OSGi technology means 
> developing bundles: the OSGi components. Bundles are modules. 
> OSGi is a good thing, but coin has two sides. Usually the development process with OSGi
will be more troublesome. Suppose 
> that we are in this scenario. We use a interface IMenuContributor to supply menu list
for our customers in internet, but 
> different customer should get different menu list, so we have two implemention class
for IMenuContributor interface, we 
> name them MenuContributor1 and MenuContributor2.
> If we develop this application in a traditional way, we should create at lease 3 projects
(or bundles) in our IDE (Eclipse for example).
> one service define bundle, two service supply bundles, it's a long list in our workspace.Isn't
it troublesome? If we just 
> write these codes in a Jave project and some tool can help us to split this project in
OSGi way and export 3 jar files, isn't it cool?
> So i want to build OSGi split tool for Java project, it can also be used to split and
refactor our exist huge project in OSGi way. This 
> is very important. In some huge application, how to manage components in a convinent
way is an art, so far, OSGi is the best solution
> that we can find. But the refactor and split for exist huge project is complex and painful.
This tool will help us to do this job.
> We want to build a bnd(tools) based OSGi bunlles maker project, it will help us analyse
java application and split the whole project into several OSGi bundles.
> Suppose that we write code in good style, define service in interface, implement the
service by the implemention class of the interface 
> and put similar service in a package. This tool can analyse source code, supply vari-size
grained split and refactor suggestions, show 
> the analyse result in a GUI view and we can change split solution manually, then it will
split the project into several projects.
> Function lists:
> 1. configuration 
> Define default split/refactor solution for this tool. For example,assign default interface
split particle or package split partical. Or may be 
> we can just split the project by function module define, similar with M(Module)-V(View)-C(control)
develop pattern. Or in some other ways.
> 2. analyse module
> It can analyse project source code, make clear of class dependency relationship and give
us a graphical view analyse result, this is default
> split solution, and we can change it as we like.
> The trick is to find strongly coupled packages. These are packages that are in a cycle.
A -> B -> C -> A. Normally I find that these packages should be in the same bundle.
In bnd (the current next branch) I already can calculate those strongly connected packages.
In general, I find that many, especially larger, bundles consist of a number of subsystems.

> These subsystems have dependencies on each other, however, by definition there is no
cycle between these subsystem dependencies (otherwise they would be strongly connected and
be part of the same subsystem). 
> There should be the following types of subsystems: 
> API - Self contained, no internal dependencies. All exported/imported. Very few dependencies.
The OSGi specification packages are prime examples. Having imports in these packages is always
suspect. In my experience, API must be maintained independently but carried in the bundle
that implements the API. 
> Library - Exported code == implementation. Few imports, everything is exported and in
general packages are not substitutable. 
> Implementation - Private code. No exports, many imports, If it provides an API it should
carry the API packages. 
> Bridge - Connects an external subsystem to an internal subsystem. Imports impl. code,
no exports. This case is special because they tend to drag in a lot dependencies that are
only required when the dependency is already there. For example, a subsystem can provide packages
that make it useful in Spring. I.e. it does not require Spring but when other people use spring
the package can be used in that connected world. Another example is bnd. It is an ant task
but it should only require ant when it runs inside ant.
> 3. split and export module
> We can select split the project into serveral small project or just export the project
as OSGi bundles way, this step rely on pre-step analyse
> and saved split/refactor solution. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message