[
https://issues.apache.org/jira/browse/FELIX-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019858#comment-13019858
]
David Bosschaert commented on FELIX-2899:
-----------------------------------------
Yes, this sounds like an excellent idea, I'd love to see this done!
> [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 Greeting to say hello to our
> customers , but we should say different words to different kind of customers
> , so we have two implemention class for Greeting interface, we
> name them BasicGreeting and GreatGreeting.
> If we develop this application in a traditional OSGi 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.
> We have finished demo for this project, you can check it on line here [1].
> [1] http://code.google.com/p/osgimaker/wiki/Quick_Start
> Additional information:
> My name is Tiger Gui, come from Beijing, China. I have been working with OSGi
> for 3 years, familiar with OSGi Felix framework and Eclipse Equinox
> framework. Once we helped one customer of our professor to split a very big
> complex project into OSGi bundles, it cost us much time, several months to
> finish this job. So, i started to think about creating a smart tool which can
> help us to do some boring job. Of course, it request high-level of Artificial
> Intelligence to do this project well, but we can do it step by step, during
> this summer, i would like to finish an available OSGi bundle maker tool which
> has special level of intelligence to analyse our project and split.
> I have finish much research job and ordered Felix developer mail list and
> Equinox developer mail list, discuss this topic in mail list with open source
> guys. Especially my mentor Peter Kriens, he gave me many good advises and
> work with me together toward to a successful project, so i have confidence
> to achieve the goal this summer. If you guys have any other advises for this
> project, please let me know, My email account and GTalk account are both
> tigergui1...@gmail.com. Thank you.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
