You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Tiger Gui <ti...@gmail.com> on 2011/03/17 03:58:30 UTC
OSGi split tool for Java project in Eclipse
Hi guys,
Recently, i am working on split my huge project in to many small
sub-projects on OSGi way. Obviously, i want to use Felix as my OSGi
framework, but as you know, this splitting job is a long and boring process.
So, i am thinking that why can we build some tools for us to do this job ?
I want to develop such a tool for Apache Felix, you guys have been working
with Felix for a long time, so do you have any adivses about my project idea
? If you have any suggestions, please let me know, thank you.
Meanwhile, i want to attend Google Summer of Code 2011 [1] with this
project, this activity will help open source project development progress,
but i must find a mentor to help me to participate in this activity
together, so if you are interested, let me know too :-)
[1] http://socghop.appspot.com/
--
Best Regards
----------------------------------------------------
Tiger Gui [tigergui1990@gmail.com]
Re: OSGi split tool for Java project in Eclipse
Posted by Tiger Gui <ti...@gmail.com>.
Hi Peter,
I have update my project proposal [1] and submit it into GSoC system,
its URL in GSoC web site is [2], looking for more advises and
feedbacks from you :-)
Thank You
[1] https://issues.apache.org/jira/browse/FELIX-2899
[2] http://socghop.appspot.com/gsoc/proposal/review/google/gsoc2011/tigergui/1
2011/3/31 Peter Kriens <pe...@aqute.biz>:
> I've assigned this bug to me, as I read it this should make me the mentor of this project.
>
> Kind regards,
>
> Peter Kriens
>
> On 31 mrt 2011, at 04:44, Tiger Gui wrote:
>
>> Hi Peter,
>>
>> I have created the JIRA issue "[GSoc 2011]Bndtools based OSGi bundles
>> maker project" [1] in Apache JIRA system, now it is in Apache GSoC
>> 2011 issue list, and i also mentioin mentor and gsoc in the labels. I
>> want to assign you as mentor for this project, but i do not know how
>> to do it, i have been traveling in the JIRA system for hours, but can
>> not find how to assign a mentor for a issue :-(
>>
>> [1] https://issues.apache.org/jira/browse/FELIX-2898
>> [2] https://issues.apache.org/jira/secure/IssueNavigator.jspa?pager/start=50
>>
>> 2011/3/30 Peter Kriens <pe...@aqute.biz>:
>>> As far as I understand you should create a JIRA issue in FELIX for this and assign it to me. You should then mention mentor and gsoc in the labels. This should assign me as mentor. I am a Felix committer.
>>>
>>> Kind regards,
>>>
>>> Peter Kriens
>>>
>>> On 30 mrt 2011, at 10:42, Tiger Gui wrote:
>>>
>>>> Hi Peter,
>>>>
>>>> Thank you very much for your interested. You pointed a distinct way
>>>> for me, i have read some documents about your bndtools project, may be
>>>> it is a good idea to build such a tool based on bndtools. I would
>>>> like build my project as an extension to bndtools very much.
>>>>
>>>> Google Summer of Code 2011 have began already, i will finish my
>>>> "Bndtools based OSGi bundles maker" project proposal in the next
>>>> couple days and submit it in GSoC web site[1], obviously, i will mark
>>>> you as my project mentor in my proposal, the only problem is that you
>>>> should register as a mentor in GSoC web site and mentor my project. If
>>>> you do not know GSoC much, the following links [2][3][4] may help you
>>>> much.
>>>>
>>>> Hoping that you can finish a fantastic job together this summer :-)
>>>>
>>>>
>>>> [1] http://socghop.appspot.com
>>>> [2] http://community.apache.org/guide-to-being-a-mentor.html
>>>> [3] http://s.apache.org/gsoc2011tasks
>>>> [4] http://community.apache.org/gsoc.html
>>>>
>>>>
>>>> 2011/3/30 Peter Kriens <pe...@aqute.biz>:
>>>>> I am very interested in this, especially in relation to bnd(tools). Some thoughts.
>>>>>
>>>>> The trick is to find strongly coupled packages. These are packages that are in a cycle. A -> B -> C -> A. Normally I find that these packages should be in the same bundle. In bnd (the current next branch) I already can calculate those strongly connected packages. In general, I find that many, especially larger, bundles consist of a number of subsystems.
>>>>>
>>>>> These subsystems have dependencies on each other, however, by definition there is no cycle between these subsystem dependencies (otherwise they would be strongly connected and be part of the same subsystem).
>>>>>
>>>>> I find that there are then the following types of subsystems:
>>>>>
>>>>> API - Self contained, no internal dependencies. All exported/imported. Very few dependencies. The OSGi specification packages are prime examples. Having imports in these packages is always suspect. In my experience, API must be maintained independently but carried in the bundle that implements the API.
>>>>> Library - Exported code == implementation. Few imports, everything is exported and in general packages are not substitutable.
>>>>> Implementation - Private code. No exports, many imports, If it provides an API it should carry the API packages.
>>>>> Bridge - Connects an external subsystem to an internal subsystem. Imports impl. code, no exports. This case is special because they tend to drag in a lot dependencies that are only required when the dependency is already there. For example, a subsystem can provide packages that make it useful in Spring. I.e. it does not require Spring but when other people use spring the package can be used in that connected world. Another example is bnd. It is an ant task but it should only require ant when it runs inside ant.
>>>>>
>>>>> What I am looking for is an extension to bndtools that allows me to visualize this model and refactor the code accordingly. The techniques should be in bnd (which is a restricted environment) and the GUI should be in bndtools, If you're willing to work this way then I'd love to be your Google code mentor.
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Peter Kriens
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 17 mrt 2011, at 03:58, Tiger Gui wrote:
>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> Recently, i am working on split my huge project in to many small
>>>>>> sub-projects on OSGi way. Obviously, i want to use Felix as my OSGi
>>>>>> framework, but as you know, this splitting job is a long and boring process.
>>>>>> So, i am thinking that why can we build some tools for us to do this job ?
>>>>>> I want to develop such a tool for Apache Felix, you guys have been working
>>>>>> with Felix for a long time, so do you have any adivses about my project idea
>>>>>> ? If you have any suggestions, please let me know, thank you.
>>>>>>
>>>>>> Meanwhile, i want to attend Google Summer of Code 2011 [1] with this
>>>>>> project, this activity will help open source project development progress,
>>>>>> but i must find a mentor to help me to participate in this activity
>>>>>> together, so if you are interested, let me know too :-)
>>>>>>
>>>>>>
>>>>>> [1] http://socghop.appspot.com/
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best Regards
>>>>>> ----------------------------------------------------
>>>>>> Tiger Gui [tigergui1990@gmail.com]
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best Regards
>>>> ----------------------------------------------------
>>>> Tiger Gui [tigergui1990@gmail.com]
>>>
>>>
>>
>>
>>
>> --
>> Best Regards
>> ----------------------------------------------------
>> Tiger Gui [tigergui1990@gmail.com]
>
>
--
Best Regards
----------------------------------------------------
Tiger Gui [tigergui1990@gmail.com]
Re: OSGi split tool for Java project in Eclipse
Posted by Peter Kriens <pe...@aqute.biz>.
I've assigned this bug to me, as I read it this should make me the mentor of this project.
Kind regards,
Peter Kriens
On 31 mrt 2011, at 04:44, Tiger Gui wrote:
> Hi Peter,
>
> I have created the JIRA issue "[GSoc 2011]Bndtools based OSGi bundles
> maker project" [1] in Apache JIRA system, now it is in Apache GSoC
> 2011 issue list, and i also mentioin mentor and gsoc in the labels. I
> want to assign you as mentor for this project, but i do not know how
> to do it, i have been traveling in the JIRA system for hours, but can
> not find how to assign a mentor for a issue :-(
>
> [1] https://issues.apache.org/jira/browse/FELIX-2898
> [2] https://issues.apache.org/jira/secure/IssueNavigator.jspa?pager/start=50
>
> 2011/3/30 Peter Kriens <pe...@aqute.biz>:
>> As far as I understand you should create a JIRA issue in FELIX for this and assign it to me. You should then mention mentor and gsoc in the labels. This should assign me as mentor. I am a Felix committer.
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>> On 30 mrt 2011, at 10:42, Tiger Gui wrote:
>>
>>> Hi Peter,
>>>
>>> Thank you very much for your interested. You pointed a distinct way
>>> for me, i have read some documents about your bndtools project, may be
>>> it is a good idea to build such a tool based on bndtools. I would
>>> like build my project as an extension to bndtools very much.
>>>
>>> Google Summer of Code 2011 have began already, i will finish my
>>> "Bndtools based OSGi bundles maker" project proposal in the next
>>> couple days and submit it in GSoC web site[1], obviously, i will mark
>>> you as my project mentor in my proposal, the only problem is that you
>>> should register as a mentor in GSoC web site and mentor my project. If
>>> you do not know GSoC much, the following links [2][3][4] may help you
>>> much.
>>>
>>> Hoping that you can finish a fantastic job together this summer :-)
>>>
>>>
>>> [1] http://socghop.appspot.com
>>> [2] http://community.apache.org/guide-to-being-a-mentor.html
>>> [3] http://s.apache.org/gsoc2011tasks
>>> [4] http://community.apache.org/gsoc.html
>>>
>>>
>>> 2011/3/30 Peter Kriens <pe...@aqute.biz>:
>>>> I am very interested in this, especially in relation to bnd(tools). Some thoughts.
>>>>
>>>> The trick is to find strongly coupled packages. These are packages that are in a cycle. A -> B -> C -> A. Normally I find that these packages should be in the same bundle. In bnd (the current next branch) I already can calculate those strongly connected packages. In general, I find that many, especially larger, bundles consist of a number of subsystems.
>>>>
>>>> These subsystems have dependencies on each other, however, by definition there is no cycle between these subsystem dependencies (otherwise they would be strongly connected and be part of the same subsystem).
>>>>
>>>> I find that there are then the following types of subsystems:
>>>>
>>>> API - Self contained, no internal dependencies. All exported/imported. Very few dependencies. The OSGi specification packages are prime examples. Having imports in these packages is always suspect. In my experience, API must be maintained independently but carried in the bundle that implements the API.
>>>> Library - Exported code == implementation. Few imports, everything is exported and in general packages are not substitutable.
>>>> Implementation - Private code. No exports, many imports, If it provides an API it should carry the API packages.
>>>> Bridge - Connects an external subsystem to an internal subsystem. Imports impl. code, no exports. This case is special because they tend to drag in a lot dependencies that are only required when the dependency is already there. For example, a subsystem can provide packages that make it useful in Spring. I.e. it does not require Spring but when other people use spring the package can be used in that connected world. Another example is bnd. It is an ant task but it should only require ant when it runs inside ant.
>>>>
>>>> What I am looking for is an extension to bndtools that allows me to visualize this model and refactor the code accordingly. The techniques should be in bnd (which is a restricted environment) and the GUI should be in bndtools, If you're willing to work this way then I'd love to be your Google code mentor.
>>>>
>>>> Kind regards,
>>>>
>>>> Peter Kriens
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 17 mrt 2011, at 03:58, Tiger Gui wrote:
>>>>
>>>>> Hi guys,
>>>>>
>>>>> Recently, i am working on split my huge project in to many small
>>>>> sub-projects on OSGi way. Obviously, i want to use Felix as my OSGi
>>>>> framework, but as you know, this splitting job is a long and boring process.
>>>>> So, i am thinking that why can we build some tools for us to do this job ?
>>>>> I want to develop such a tool for Apache Felix, you guys have been working
>>>>> with Felix for a long time, so do you have any adivses about my project idea
>>>>> ? If you have any suggestions, please let me know, thank you.
>>>>>
>>>>> Meanwhile, i want to attend Google Summer of Code 2011 [1] with this
>>>>> project, this activity will help open source project development progress,
>>>>> but i must find a mentor to help me to participate in this activity
>>>>> together, so if you are interested, let me know too :-)
>>>>>
>>>>>
>>>>> [1] http://socghop.appspot.com/
>>>>>
>>>>>
>>>>> --
>>>>> Best Regards
>>>>> ----------------------------------------------------
>>>>> Tiger Gui [tigergui1990@gmail.com]
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Best Regards
>>> ----------------------------------------------------
>>> Tiger Gui [tigergui1990@gmail.com]
>>
>>
>
>
>
> --
> Best Regards
> ----------------------------------------------------
> Tiger Gui [tigergui1990@gmail.com]
Re: OSGi split tool for Java project in Eclipse
Posted by Tiger Gui <ti...@gmail.com>.
Sorry Peter, I supplied wrong URLs in the last mail. The issue url
is [1] https://issues.apache.org/jira/browse/FELIX-2899, and GSoC 2011
idea list url is [2]. There is no "assign" field in issue add/edit
page, so i can not assign the issue to you, i do know why
[1]https://issues.apache.org/jira/browse/FELIX-2899
[2]https://issues.apache.org/jira/secure/IssueNavigator.jspa?requestId=12315354
2011/3/31 Tiger Gui <ti...@gmail.com>:
> Hi Peter,
>
> I have created the JIRA issue "[GSoc 2011]Bndtools based OSGi bundles
> maker project" [1] in Apache JIRA system, now it is in Apache GSoC
> 2011 issue list, and i also mentioin mentor and gsoc in the labels. I
> want to assign you as mentor for this project, but i do not know how
> to do it, i have been traveling in the JIRA system for hours, but can
> not find how to assign a mentor for a issue :-(
>
> [1] https://issues.apache.org/jira/browse/FELIX-2898
> [2] https://issues.apache.org/jira/secure/IssueNavigator.jspa?pager/start=50
>
> 2011/3/30 Peter Kriens <pe...@aqute.biz>:
>> As far as I understand you should create a JIRA issue in FELIX for this and assign it to me. You should then mention mentor and gsoc in the labels. This should assign me as mentor. I am a Felix committer.
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>> On 30 mrt 2011, at 10:42, Tiger Gui wrote:
>>
>>> Hi Peter,
>>>
>>> Thank you very much for your interested. You pointed a distinct way
>>> for me, i have read some documents about your bndtools project, may be
>>> it is a good idea to build such a tool based on bndtools. I would
>>> like build my project as an extension to bndtools very much.
>>>
>>> Google Summer of Code 2011 have began already, i will finish my
>>> "Bndtools based OSGi bundles maker" project proposal in the next
>>> couple days and submit it in GSoC web site[1], obviously, i will mark
>>> you as my project mentor in my proposal, the only problem is that you
>>> should register as a mentor in GSoC web site and mentor my project. If
>>> you do not know GSoC much, the following links [2][3][4] may help you
>>> much.
>>>
>>> Hoping that you can finish a fantastic job together this summer :-)
>>>
>>>
>>> [1] http://socghop.appspot.com
>>> [2] http://community.apache.org/guide-to-being-a-mentor.html
>>> [3] http://s.apache.org/gsoc2011tasks
>>> [4] http://community.apache.org/gsoc.html
>>>
>>>
>>> 2011/3/30 Peter Kriens <pe...@aqute.biz>:
>>>> I am very interested in this, especially in relation to bnd(tools). Some thoughts.
>>>>
>>>> The trick is to find strongly coupled packages. These are packages that are in a cycle. A -> B -> C -> A. Normally I find that these packages should be in the same bundle. In bnd (the current next branch) I already can calculate those strongly connected packages. In general, I find that many, especially larger, bundles consist of a number of subsystems.
>>>>
>>>> These subsystems have dependencies on each other, however, by definition there is no cycle between these subsystem dependencies (otherwise they would be strongly connected and be part of the same subsystem).
>>>>
>>>> I find that there are then the following types of subsystems:
>>>>
>>>> API - Self contained, no internal dependencies. All exported/imported. Very few dependencies. The OSGi specification packages are prime examples. Having imports in these packages is always suspect. In my experience, API must be maintained independently but carried in the bundle that implements the API.
>>>> Library - Exported code == implementation. Few imports, everything is exported and in general packages are not substitutable.
>>>> Implementation - Private code. No exports, many imports, If it provides an API it should carry the API packages.
>>>> Bridge - Connects an external subsystem to an internal subsystem. Imports impl. code, no exports. This case is special because they tend to drag in a lot dependencies that are only required when the dependency is already there. For example, a subsystem can provide packages that make it useful in Spring. I.e. it does not require Spring but when other people use spring the package can be used in that connected world. Another example is bnd. It is an ant task but it should only require ant when it runs inside ant.
>>>>
>>>> What I am looking for is an extension to bndtools that allows me to visualize this model and refactor the code accordingly. The techniques should be in bnd (which is a restricted environment) and the GUI should be in bndtools, If you're willing to work this way then I'd love to be your Google code mentor.
>>>>
>>>> Kind regards,
>>>>
>>>> Peter Kriens
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 17 mrt 2011, at 03:58, Tiger Gui wrote:
>>>>
>>>>> Hi guys,
>>>>>
>>>>> Recently, i am working on split my huge project in to many small
>>>>> sub-projects on OSGi way. Obviously, i want to use Felix as my OSGi
>>>>> framework, but as you know, this splitting job is a long and boring process.
>>>>> So, i am thinking that why can we build some tools for us to do this job ?
>>>>> I want to develop such a tool for Apache Felix, you guys have been working
>>>>> with Felix for a long time, so do you have any adivses about my project idea
>>>>> ? If you have any suggestions, please let me know, thank you.
>>>>>
>>>>> Meanwhile, i want to attend Google Summer of Code 2011 [1] with this
>>>>> project, this activity will help open source project development progress,
>>>>> but i must find a mentor to help me to participate in this activity
>>>>> together, so if you are interested, let me know too :-)
>>>>>
>>>>>
>>>>> [1] http://socghop.appspot.com/
>>>>>
>>>>>
>>>>> --
>>>>> Best Regards
>>>>> ----------------------------------------------------
>>>>> Tiger Gui [tigergui1990@gmail.com]
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Best Regards
>>> ----------------------------------------------------
>>> Tiger Gui [tigergui1990@gmail.com]
>>
>>
>
>
>
> --
> Best Regards
> ----------------------------------------------------
> Tiger Gui [tigergui1990@gmail.com]
>
--
Best Regards
----------------------------------------------------
Tiger Gui [tigergui1990@gmail.com]
Re: OSGi split tool for Java project in Eclipse
Posted by Tiger Gui <ti...@gmail.com>.
Hi Peter,
I have created the JIRA issue "[GSoc 2011]Bndtools based OSGi bundles
maker project" [1] in Apache JIRA system, now it is in Apache GSoC
2011 issue list, and i also mentioin mentor and gsoc in the labels. I
want to assign you as mentor for this project, but i do not know how
to do it, i have been traveling in the JIRA system for hours, but can
not find how to assign a mentor for a issue :-(
[1] https://issues.apache.org/jira/browse/FELIX-2898
[2] https://issues.apache.org/jira/secure/IssueNavigator.jspa?pager/start=50
2011/3/30 Peter Kriens <pe...@aqute.biz>:
> As far as I understand you should create a JIRA issue in FELIX for this and assign it to me. You should then mention mentor and gsoc in the labels. This should assign me as mentor. I am a Felix committer.
>
> Kind regards,
>
> Peter Kriens
>
> On 30 mrt 2011, at 10:42, Tiger Gui wrote:
>
>> Hi Peter,
>>
>> Thank you very much for your interested. You pointed a distinct way
>> for me, i have read some documents about your bndtools project, may be
>> it is a good idea to build such a tool based on bndtools. I would
>> like build my project as an extension to bndtools very much.
>>
>> Google Summer of Code 2011 have began already, i will finish my
>> "Bndtools based OSGi bundles maker" project proposal in the next
>> couple days and submit it in GSoC web site[1], obviously, i will mark
>> you as my project mentor in my proposal, the only problem is that you
>> should register as a mentor in GSoC web site and mentor my project. If
>> you do not know GSoC much, the following links [2][3][4] may help you
>> much.
>>
>> Hoping that you can finish a fantastic job together this summer :-)
>>
>>
>> [1] http://socghop.appspot.com
>> [2] http://community.apache.org/guide-to-being-a-mentor.html
>> [3] http://s.apache.org/gsoc2011tasks
>> [4] http://community.apache.org/gsoc.html
>>
>>
>> 2011/3/30 Peter Kriens <pe...@aqute.biz>:
>>> I am very interested in this, especially in relation to bnd(tools). Some thoughts.
>>>
>>> The trick is to find strongly coupled packages. These are packages that are in a cycle. A -> B -> C -> A. Normally I find that these packages should be in the same bundle. In bnd (the current next branch) I already can calculate those strongly connected packages. In general, I find that many, especially larger, bundles consist of a number of subsystems.
>>>
>>> These subsystems have dependencies on each other, however, by definition there is no cycle between these subsystem dependencies (otherwise they would be strongly connected and be part of the same subsystem).
>>>
>>> I find that there are then the following types of subsystems:
>>>
>>> API - Self contained, no internal dependencies. All exported/imported. Very few dependencies. The OSGi specification packages are prime examples. Having imports in these packages is always suspect. In my experience, API must be maintained independently but carried in the bundle that implements the API.
>>> Library - Exported code == implementation. Few imports, everything is exported and in general packages are not substitutable.
>>> Implementation - Private code. No exports, many imports, If it provides an API it should carry the API packages.
>>> Bridge - Connects an external subsystem to an internal subsystem. Imports impl. code, no exports. This case is special because they tend to drag in a lot dependencies that are only required when the dependency is already there. For example, a subsystem can provide packages that make it useful in Spring. I.e. it does not require Spring but when other people use spring the package can be used in that connected world. Another example is bnd. It is an ant task but it should only require ant when it runs inside ant.
>>>
>>> What I am looking for is an extension to bndtools that allows me to visualize this model and refactor the code accordingly. The techniques should be in bnd (which is a restricted environment) and the GUI should be in bndtools, If you're willing to work this way then I'd love to be your Google code mentor.
>>>
>>> Kind regards,
>>>
>>> Peter Kriens
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 17 mrt 2011, at 03:58, Tiger Gui wrote:
>>>
>>>> Hi guys,
>>>>
>>>> Recently, i am working on split my huge project in to many small
>>>> sub-projects on OSGi way. Obviously, i want to use Felix as my OSGi
>>>> framework, but as you know, this splitting job is a long and boring process.
>>>> So, i am thinking that why can we build some tools for us to do this job ?
>>>> I want to develop such a tool for Apache Felix, you guys have been working
>>>> with Felix for a long time, so do you have any adivses about my project idea
>>>> ? If you have any suggestions, please let me know, thank you.
>>>>
>>>> Meanwhile, i want to attend Google Summer of Code 2011 [1] with this
>>>> project, this activity will help open source project development progress,
>>>> but i must find a mentor to help me to participate in this activity
>>>> together, so if you are interested, let me know too :-)
>>>>
>>>>
>>>> [1] http://socghop.appspot.com/
>>>>
>>>>
>>>> --
>>>> Best Regards
>>>> ----------------------------------------------------
>>>> Tiger Gui [tigergui1990@gmail.com]
>>>
>>>
>>
>>
>>
>> --
>> Best Regards
>> ----------------------------------------------------
>> Tiger Gui [tigergui1990@gmail.com]
>
>
--
Best Regards
----------------------------------------------------
Tiger Gui [tigergui1990@gmail.com]
Re: OSGi split tool for Java project in Eclipse
Posted by Peter Kriens <pe...@aqute.biz>.
As far as I understand you should create a JIRA issue in FELIX for this and assign it to me. You should then mention mentor and gsoc in the labels. This should assign me as mentor. I am a Felix committer.
Kind regards,
Peter Kriens
On 30 mrt 2011, at 10:42, Tiger Gui wrote:
> Hi Peter,
>
> Thank you very much for your interested. You pointed a distinct way
> for me, i have read some documents about your bndtools project, may be
> it is a good idea to build such a tool based on bndtools. I would
> like build my project as an extension to bndtools very much.
>
> Google Summer of Code 2011 have began already, i will finish my
> "Bndtools based OSGi bundles maker" project proposal in the next
> couple days and submit it in GSoC web site[1], obviously, i will mark
> you as my project mentor in my proposal, the only problem is that you
> should register as a mentor in GSoC web site and mentor my project. If
> you do not know GSoC much, the following links [2][3][4] may help you
> much.
>
> Hoping that you can finish a fantastic job together this summer :-)
>
>
> [1] http://socghop.appspot.com
> [2] http://community.apache.org/guide-to-being-a-mentor.html
> [3] http://s.apache.org/gsoc2011tasks
> [4] http://community.apache.org/gsoc.html
>
>
> 2011/3/30 Peter Kriens <pe...@aqute.biz>:
>> I am very interested in this, especially in relation to bnd(tools). Some thoughts.
>>
>> The trick is to find strongly coupled packages. These are packages that are in a cycle. A -> B -> C -> A. Normally I find that these packages should be in the same bundle. In bnd (the current next branch) I already can calculate those strongly connected packages. In general, I find that many, especially larger, bundles consist of a number of subsystems.
>>
>> These subsystems have dependencies on each other, however, by definition there is no cycle between these subsystem dependencies (otherwise they would be strongly connected and be part of the same subsystem).
>>
>> I find that there are then the following types of subsystems:
>>
>> API - Self contained, no internal dependencies. All exported/imported. Very few dependencies. The OSGi specification packages are prime examples. Having imports in these packages is always suspect. In my experience, API must be maintained independently but carried in the bundle that implements the API.
>> Library - Exported code == implementation. Few imports, everything is exported and in general packages are not substitutable.
>> Implementation - Private code. No exports, many imports, If it provides an API it should carry the API packages.
>> Bridge - Connects an external subsystem to an internal subsystem. Imports impl. code, no exports. This case is special because they tend to drag in a lot dependencies that are only required when the dependency is already there. For example, a subsystem can provide packages that make it useful in Spring. I.e. it does not require Spring but when other people use spring the package can be used in that connected world. Another example is bnd. It is an ant task but it should only require ant when it runs inside ant.
>>
>> What I am looking for is an extension to bndtools that allows me to visualize this model and refactor the code accordingly. The techniques should be in bnd (which is a restricted environment) and the GUI should be in bndtools, If you're willing to work this way then I'd love to be your Google code mentor.
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>>
>>
>>
>>
>> On 17 mrt 2011, at 03:58, Tiger Gui wrote:
>>
>>> Hi guys,
>>>
>>> Recently, i am working on split my huge project in to many small
>>> sub-projects on OSGi way. Obviously, i want to use Felix as my OSGi
>>> framework, but as you know, this splitting job is a long and boring process.
>>> So, i am thinking that why can we build some tools for us to do this job ?
>>> I want to develop such a tool for Apache Felix, you guys have been working
>>> with Felix for a long time, so do you have any adivses about my project idea
>>> ? If you have any suggestions, please let me know, thank you.
>>>
>>> Meanwhile, i want to attend Google Summer of Code 2011 [1] with this
>>> project, this activity will help open source project development progress,
>>> but i must find a mentor to help me to participate in this activity
>>> together, so if you are interested, let me know too :-)
>>>
>>>
>>> [1] http://socghop.appspot.com/
>>>
>>>
>>> --
>>> Best Regards
>>> ----------------------------------------------------
>>> Tiger Gui [tigergui1990@gmail.com]
>>
>>
>
>
>
> --
> Best Regards
> ----------------------------------------------------
> Tiger Gui [tigergui1990@gmail.com]
Re: OSGi split tool for Java project in Eclipse
Posted by Tiger Gui <ti...@gmail.com>.
Hi Peter,
Thank you very much for your interested. You pointed a distinct way
for me, i have read some documents about your bndtools project, may be
it is a good idea to build such a tool based on bndtools. I would
like build my project as an extension to bndtools very much.
Google Summer of Code 2011 have began already, i will finish my
"Bndtools based OSGi bundles maker" project proposal in the next
couple days and submit it in GSoC web site[1], obviously, i will mark
you as my project mentor in my proposal, the only problem is that you
should register as a mentor in GSoC web site and mentor my project. If
you do not know GSoC much, the following links [2][3][4] may help you
much.
Hoping that you can finish a fantastic job together this summer :-)
[1] http://socghop.appspot.com
[2] http://community.apache.org/guide-to-being-a-mentor.html
[3] http://s.apache.org/gsoc2011tasks
[4] http://community.apache.org/gsoc.html
2011/3/30 Peter Kriens <pe...@aqute.biz>:
> I am very interested in this, especially in relation to bnd(tools). Some thoughts.
>
> The trick is to find strongly coupled packages. These are packages that are in a cycle. A -> B -> C -> A. Normally I find that these packages should be in the same bundle. In bnd (the current next branch) I already can calculate those strongly connected packages. In general, I find that many, especially larger, bundles consist of a number of subsystems.
>
> These subsystems have dependencies on each other, however, by definition there is no cycle between these subsystem dependencies (otherwise they would be strongly connected and be part of the same subsystem).
>
> I find that there are then the following types of subsystems:
>
> API - Self contained, no internal dependencies. All exported/imported. Very few dependencies. The OSGi specification packages are prime examples. Having imports in these packages is always suspect. In my experience, API must be maintained independently but carried in the bundle that implements the API.
> Library - Exported code == implementation. Few imports, everything is exported and in general packages are not substitutable.
> Implementation - Private code. No exports, many imports, If it provides an API it should carry the API packages.
> Bridge - Connects an external subsystem to an internal subsystem. Imports impl. code, no exports. This case is special because they tend to drag in a lot dependencies that are only required when the dependency is already there. For example, a subsystem can provide packages that make it useful in Spring. I.e. it does not require Spring but when other people use spring the package can be used in that connected world. Another example is bnd. It is an ant task but it should only require ant when it runs inside ant.
>
> What I am looking for is an extension to bndtools that allows me to visualize this model and refactor the code accordingly. The techniques should be in bnd (which is a restricted environment) and the GUI should be in bndtools, If you're willing to work this way then I'd love to be your Google code mentor.
>
> Kind regards,
>
> Peter Kriens
>
>
>
>
>
>
> On 17 mrt 2011, at 03:58, Tiger Gui wrote:
>
>> Hi guys,
>>
>> Recently, i am working on split my huge project in to many small
>> sub-projects on OSGi way. Obviously, i want to use Felix as my OSGi
>> framework, but as you know, this splitting job is a long and boring process.
>> So, i am thinking that why can we build some tools for us to do this job ?
>> I want to develop such a tool for Apache Felix, you guys have been working
>> with Felix for a long time, so do you have any adivses about my project idea
>> ? If you have any suggestions, please let me know, thank you.
>>
>> Meanwhile, i want to attend Google Summer of Code 2011 [1] with this
>> project, this activity will help open source project development progress,
>> but i must find a mentor to help me to participate in this activity
>> together, so if you are interested, let me know too :-)
>>
>>
>> [1] http://socghop.appspot.com/
>>
>>
>> --
>> Best Regards
>> ----------------------------------------------------
>> Tiger Gui [tigergui1990@gmail.com]
>
>
--
Best Regards
----------------------------------------------------
Tiger Gui [tigergui1990@gmail.com]
Re: OSGi split tool for Java project in Eclipse
Posted by Peter Kriens <pe...@aqute.biz>.
I am very interested in this, especially in relation to bnd(tools). Some thoughts.
The trick is to find strongly coupled packages. These are packages that are in a cycle. A -> B -> C -> A. Normally I find that these packages should be in the same bundle. In bnd (the current next branch) I already can calculate those strongly connected packages. In general, I find that many, especially larger, bundles consist of a number of subsystems.
These subsystems have dependencies on each other, however, by definition there is no cycle between these subsystem dependencies (otherwise they would be strongly connected and be part of the same subsystem).
I find that there are then the following types of subsystems:
API - Self contained, no internal dependencies. All exported/imported. Very few dependencies. The OSGi specification packages are prime examples. Having imports in these packages is always suspect. In my experience, API must be maintained independently but carried in the bundle that implements the API.
Library - Exported code == implementation. Few imports, everything is exported and in general packages are not substitutable.
Implementation - Private code. No exports, many imports, If it provides an API it should carry the API packages.
Bridge - Connects an external subsystem to an internal subsystem. Imports impl. code, no exports. This case is special because they tend to drag in a lot dependencies that are only required when the dependency is already there. For example, a subsystem can provide packages that make it useful in Spring. I.e. it does not require Spring but when other people use spring the package can be used in that connected world. Another example is bnd. It is an ant task but it should only require ant when it runs inside ant.
What I am looking for is an extension to bndtools that allows me to visualize this model and refactor the code accordingly. The techniques should be in bnd (which is a restricted environment) and the GUI should be in bndtools, If you're willing to work this way then I'd love to be your Google code mentor.
Kind regards,
Peter Kriens
On 17 mrt 2011, at 03:58, Tiger Gui wrote:
> Hi guys,
>
> Recently, i am working on split my huge project in to many small
> sub-projects on OSGi way. Obviously, i want to use Felix as my OSGi
> framework, but as you know, this splitting job is a long and boring process.
> So, i am thinking that why can we build some tools for us to do this job ?
> I want to develop such a tool for Apache Felix, you guys have been working
> with Felix for a long time, so do you have any adivses about my project idea
> ? If you have any suggestions, please let me know, thank you.
>
> Meanwhile, i want to attend Google Summer of Code 2011 [1] with this
> project, this activity will help open source project development progress,
> but i must find a mentor to help me to participate in this activity
> together, so if you are interested, let me know too :-)
>
>
> [1] http://socghop.appspot.com/
>
>
> --
> Best Regards
> ----------------------------------------------------
> Tiger Gui [tigergui1990@gmail.com]