[jira] [Created] (FELIX-2899) [GSoc 2011]Bndtools based OSGi bundles maker project

["Tiger Gui (JIRA)" <ji...@apache.org>]

[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

[jira] [Updated] (FELIX-2899) [GSoc 2011]Bndtools based OSGi bundles maker project

["Tiger Gui (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/FELIX-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tiger Gui updated FELIX-2899:
-----------------------------

    Description: 
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 IMenuContributor to supply menu list for our customers in internet, but 
different customer should get different menu list, so we have two implemention class for IMenuContributor interface, we 
name them MenuContributor1 and MenuContributor2.

If we develop this application in a traditional 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. 



  was:
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.


> [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
>              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 IMenuContributor to supply menu list for our customers in internet, but 
> different customer should get different menu list, so we have two implemention class for IMenuContributor interface, we 
> name them MenuContributor1 and MenuContributor2.
> If we develop this application in a traditional 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. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FELIX-2899) [GSoc 2011]Bndtools based OSGi bundles maker project

["Tiger Gui (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FELIX-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13014390#comment-13014390 ] 

Tiger Gui commented on FELIX-2899:
----------------------------------

Hi all, you can go here http://code.google.com/p/osgimaker/wiki/Quick_Start to check this project's on line demo :-)

> [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

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (FELIX-2899) [GSoc 2011]Bndtools based OSGi bundles maker project

["Peter Kriens (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/FELIX-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Kriens reassigned FELIX-2899:
-----------------------------------

    Assignee: Peter Kriens  (was: Karl Pauls)

> [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 tigergui1990@gmail.com. Thank you.  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (FELIX-2899) [GSoc 2011]Bndtools based OSGi bundles maker project

["Tiger Gui (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/FELIX-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tiger Gui updated FELIX-2899:
-----------------------------

    Description: 
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 tigergui1990@gmail.com. Thank you.  

  was:
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


> [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 tigergui1990@gmail.com. Thank you.  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FELIX-2899) [GSoc 2011]Bndtools based OSGi bundles maker project

["David Bosschaert (JIRA)" <ji...@apache.org>]

    [ 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 tigergui1990@gmail.com. Thank you.  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FELIX-2899) [GSoc 2011]Bndtools based OSGi bundles maker project

["Simon Chemouil (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FELIX-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016413#comment-13016413 ] 

Simon Chemouil commented on FELIX-2899:
---------------------------------------

Hi, commenting because I had a similar idea some time ago, and reached the same conclusion as Peter that identifying strongly connected components in the static dependency graph of Java classes (and packages) is the best bet. And there's already an optimal algorithm for that ;-). Refinements & parametrization should come later (e.g: should the tool be allowed to move classes to another package, should interfaces be extracted for API needs, should factories be created and exposed as a DS component, etc).

Anyway, after thinking about this for some time, I came to the conclusion that doing an "out of the box" solution is a lot of work, and probably make a very intense GSoC :-).

If there was such a tool, it would definitely be an enabler for OSGi and allow many projects (including many open source Java projects) to become more modular at a much lower cost. I hope the GSoC team will accept it.

When they do, good luck with the coding :-).

> [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 tigergui1990@gmail.com. Thank you.  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (FELIX-2899) [GSoc 2011]Bndtools based OSGi bundles maker project

["Tiger Gui (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/FELIX-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tiger Gui updated FELIX-2899:
-----------------------------

    Description: 
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. 



  was:
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 IMenuContributor to supply menu list for our customers in internet, but 
different customer should get different menu list, so we have two implemention class for IMenuContributor interface, we 
name them MenuContributor1 and MenuContributor2.

If we develop this application in a traditional 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. 




> [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. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FELIX-2899) [GSoc 2011]Bndtools based OSGi bundles maker project

["Přemek Brada (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FELIX-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020319#comment-13020319 ] 

Přemek Brada commented on FELIX-2899:
-------------------------------------

I find the proposal certainly a much needed and useful thing. We are just in the middle of manually decomposing a small-ish monolithic app into a bundelized one, so I would be much interested in comparing the results with possible outcome of this project.

That said, creating a truly generic (not just strongly connected components but also patterns in code, hidden dependencies e.g. via resources cutting through many layers, etc.) and scalable (from a dozen to hundreds-thousands of potential bundles) solution is a great challenge. In fact, I was thinking proposing this as a research topic for 1-2 phd students :-)  So, fingers crossed Tiger.

> [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 tigergui1990@gmail.com. Thank you.  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FELIX-2899) [GSoc 2011]Bndtools based OSGi bundles maker project

["Richard S. Hall (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FELIX-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016411#comment-13016411 ] 

Richard S. Hall commented on FELIX-2899:
----------------------------------------

We definitely need better tooling for creating OSGi bundles, so this seems very worthwhile to me.

> [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 tigergui1990@gmail.com. Thank you.  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FELIX-2899) [GSoc 2011]Bndtools based OSGi bundles maker project

["Tiger Gui (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FELIX-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021587#comment-13021587 ] 

Tiger Gui commented on FELIX-2899:
----------------------------------

Yeah, a little ambitious, but we have at least 3 months this summer, i confirm that we can really do some thing useful :-)

> [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 tigergui1990@gmail.com. Thank you.  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (FELIX-2899) [GSoc 2011]Bndtools based OSGi bundles maker project

["Peter Kriens (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/FELIX-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Kriens reassigned FELIX-2899:
-----------------------------------

    Assignee: Karl Pauls  (was: Peter Kriens)

> [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: Karl Pauls
>              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 tigergui1990@gmail.com. Thank you.  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (FELIX-2899) [GSoc 2011]Bndtools based OSGi bundles maker project

["Peter Kriens (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/FELIX-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Kriens reassigned FELIX-2899:
-----------------------------------

    Assignee: Peter Kriens

Will act as mentor to this project

> [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 IMenuContributor to supply menu list for our customers in internet, but 
> different customer should get different menu list, so we have two implemention class for IMenuContributor interface, we 
> name them MenuContributor1 and MenuContributor2.
> If we develop this application in a traditional 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. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FELIX-2899) [GSoc 2011]Bndtools based OSGi bundles maker project

["Peter Kriens (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FELIX-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021567#comment-13021567 ] 

Peter Kriens commented on FELIX-2899:
-------------------------------------

Hey! A bit of ambition has harmed nobody so far! :-) But I agree, it is ambitious. The project should really focus on the low hanging fruit first. 

> [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 tigergui1990@gmail.com. Thank you.  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (FELIX-2899) [GSoc 2011]Bndtools based OSGi bundles maker project

["Tiger Gui (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/FELIX-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tiger Gui updated FELIX-2899:
-----------------------------

    Description: 
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

  was:
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. 




> [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

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira