[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
Recently, i am working on split my huge project in to many small sub-projects
on OSGi way. Obviously, i want to use Felix as my OSGi framework, but as you
know, this splitting job is a long and boring process. So, i am thinking that
why can we build some tools for 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.
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.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
