Hi Peter, Thank you very much for your interested. You pointed a distinct way for me, i have read some documents about your bndtools project, may be it is a good idea to build such a tool based on bndtools. I would like build my project as an extension to bndtools very much.
Google Summer of Code 2011 have began already, i will finish my "Bndtools based OSGi bundles maker" project proposal in the next couple days and submit it in GSoC web site[1], obviously, i will mark you as my project mentor in my proposal, the only problem is that you should register as a mentor in GSoC web site and mentor my project. If you do not know GSoC much, the following links [2][3][4] may help you much. Hoping that you can finish a fantastic job together this summer :-) [1] http://socghop.appspot.com [2] http://community.apache.org/guide-to-being-a-mentor.html [3] http://s.apache.org/gsoc2011tasks [4] http://community.apache.org/gsoc.html 2011/3/30 Peter Kriens <[email protected]>: > I am very interested in this, especially in relation to bnd(tools). Some > thoughts. > > 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). > > I find that there are then 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. > > What I am looking for is an extension to bndtools that allows me to visualize > this model and refactor the code accordingly. The techniques should be in bnd > (which is a restricted environment) and the GUI should be in bndtools, If > you're willing to work this way then I'd love to be your Google code mentor. > > Kind regards, > > Peter Kriens > > > > > > > On 17 mrt 2011, at 03:58, Tiger Gui wrote: > >> Hi guys, >> >> 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 ? >> I want to develop such a tool for Apache Felix, you guys have been working >> with Felix for a long time, so do you have any adivses about my project idea >> ? If you have any suggestions, please let me know, thank you. >> >> Meanwhile, i want to attend Google Summer of Code 2011 [1] with this >> project, this activity will help open source project development progress, >> but i must find a mentor to help me to participate in this activity >> together, so if you are interested, let me know too :-) >> >> >> [1] http://socghop.appspot.com/ >> >> >> -- >> Best Regards >> ---------------------------------------------------- >> Tiger Gui [[email protected]] > > -- Best Regards ---------------------------------------------------- Tiger Gui [[email protected]]
