[
https://issues.apache.org/jira/browse/FELIX-2898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin Lei updated FELIX-2898:
-----------------------------
Issue Type: Task (was: Improvement)
> [GSoc 2011]Bndtools based OSGi bundles maker project
> ----------------------------------------------------
>
> Key: FELIX-2898
> URL: https://issues.apache.org/jira/browse/FELIX-2898
> 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: Gavin Lei
> Labels: gsoc, gsoc2011, mentor
> Original Estimate: 1680h
> Remaining Estimate: 1680h
>
> 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
