felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gavin Lei (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (FELIX-2898) [GSoc 2011]Bndtools based OSGi bundles maker project
Date Thu, 31 Mar 2011 02:36:05 GMT

     [ 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

View raw message