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 <[email protected]>:
> 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 <[email protected]>:
>>> 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 <[email protected]>:
>>>>> I am very interested in this, especially in relation to bnd(tools). Some 
>>>>> thoughts.
>>>>>
>>>>> The trick is to find strongly coupled packages. These are packages that 
>>>>> are in a cycle. A -> B -> C -> A. Normally I find that these packages 
>>>>> should be in the same bundle. In bnd (the current next branch) I already 
>>>>> can calculate those strongly connected packages. In general, I find that 
>>>>> many, especially larger, bundles consist of a number of subsystems.
>>>>>
>>>>> These subsystems have dependencies on each other, however, by definition 
>>>>> there is no cycle between these subsystem dependencies (otherwise they 
>>>>> would be strongly connected and be part of the same subsystem).
>>>>>
>>>>> I find that there are then the following types of subsystems:
>>>>>
>>>>> API - Self contained, no internal dependencies. All exported/imported. 
>>>>> Very few dependencies. The OSGi specification packages are prime 
>>>>> examples. Having imports in these packages is always suspect. In my 
>>>>> experience, API must be maintained independently but carried in the 
>>>>> bundle that implements the API.
>>>>> Library - Exported code == implementation. Few imports, everything is 
>>>>> exported and in general packages are not substitutable.
>>>>> Implementation - Private code. No exports, many imports, If it provides 
>>>>> an API it should carry the API packages.
>>>>> Bridge - Connects an external subsystem to an internal subsystem. Imports 
>>>>> impl. code, no exports. This case is special because they tend to drag in 
>>>>> a lot dependencies that are only required when the dependency is already 
>>>>> there. For example, a subsystem can provide packages that make it useful 
>>>>> in Spring. I.e. it does not require Spring but when other people use 
>>>>> spring the package can be used in that connected world. Another example 
>>>>> is bnd. It is an ant task but it should only require ant when it runs 
>>>>> inside ant.
>>>>>
>>>>> What I am looking for is an extension to bndtools that allows me to 
>>>>> visualize this model and refactor the code accordingly. The techniques 
>>>>> should be in bnd (which is a restricted environment) and the GUI should 
>>>>> be in bndtools, If you're willing to work this way then I'd love to be 
>>>>> your Google code mentor.
>>>>>
>>>>> Kind regards,
>>>>>
>>>>>        Peter Kriens
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 17 mrt 2011, at 03:58, Tiger Gui wrote:
>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> Recently, i am working on split my huge project in to many small
>>>>>> sub-projects on OSGi way. Obviously, i want to use Felix as my OSGi
>>>>>> framework, but as you know, this splitting job is a long and boring 
>>>>>> process.
>>>>>> So, i am thinking that why can we build some tools for us to do this job 
>>>>>> ?
>>>>>> I want to develop such a tool for Apache Felix, you guys have been 
>>>>>> working
>>>>>> with Felix for a long time, so do you have any adivses about my project 
>>>>>> idea
>>>>>> ?  If you have any suggestions, please let me know, thank you.
>>>>>>
>>>>>> Meanwhile, i want to attend Google Summer of Code 2011 [1] with this
>>>>>> project, this activity will help open source project development 
>>>>>> progress,
>>>>>> but i must find a mentor to help me to participate in this activity
>>>>>> together, so if you are interested, let me know too :-)
>>>>>>
>>>>>>
>>>>>> [1] http://socghop.appspot.com/
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best Regards
>>>>>> ----------------------------------------------------
>>>>>> Tiger Gui [[email protected]]
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best Regards
>>>> ----------------------------------------------------
>>>> Tiger Gui [[email protected]]
>>>
>>>
>>
>>
>>
>> --
>> Best Regards
>> ----------------------------------------------------
>> Tiger Gui [[email protected]]
>
>



-- 
Best Regards
----------------------------------------------------
Tiger Gui [[email protected]]

Reply via email to