And this attach file is Tomcat's initial package relationship figure,
as there are too many packages in Tomat, so this figure is a little
too complex, but we can find out the grossly situation
2011/8/9 Tiger Gui <tigergui1...@gmail.com>:
> Hi Peter,
>
> This is Tomcat's bundles relationship figure, i use Jung to visualize
> the dependencies, arrow from A to B means bundle A need bundle B. And
> the html attach file is the bundles relationship report
>
> 2011/8/2 Tiger Gui <tigergui1...@gmail.com>:
>> Yeah, the imports are too much, but there is not any problem.
>>
>> The good new is that i am working for the visualize job of the
>> dependencies, it will give us a more clear graph about the bundles
>> relationship, just wait for 2 -3 days, I am on my way of playing with
>> JUNG
>>
>> 2011/8/2 Peter Kriens <peter.kri...@aqute.biz>:
>>> Can you take a look at the imports? There seems to be many class names?
>>>
>>> I also think you should try to shorten the package names. Maybe names like
>>> oac.comet (org.apache.catalina.comet) would already help.
>>>
>>> And we really need visualize the dependencies ... This is however a great
>>> start.
>>>
>>> Kind regards,
>>>
>>> Peter Kriens
>>>
>>> On 30 jul 2011, at 16:02, Tiger Gui wrote:
>>>
>>>> Hi Peter,
>>>>
>>>> I changed the merge situation a little,
>>>>
>>>> FROM:
>>>> boolean condition4 = 4 * sameUB >= one.usedByList.size() +
>>>> two.usedByList.size();
>>>> TO:
>>>> boolean condition4 = 3 * sameUB >= one.usedByList.size() +
>>>> two.usedByList.size();
>>>>
>>>> Try the analyse and split algorithm in Tomcat application again, and
>>>> we got another report, in the attach file. It seems that this bundle
>>>> structure is more reasonable
>>>>
>>>> 2011/7/30 Tiger Gui <tigergui1...@gmail.com>:
>>>>> Hi Peter,
>>>>>
>>>>> I have generated the report for Tomcat too, in the attach file, and
>>>>> improve the report as you wish, just see the comments
>>>>>
>>>>> 2011/7/29 Peter Kriens <peter.kri...@aqute.biz>:
>>>>>> Now we're getting somewhere! Could you:
>>>>>>
>>>>>> 1) Please rename names like round1MergeBundle8 to just R18 or so ...
>>>>>
>>>>> I have renamed round1MergeBundle8 to just R1B8, BTW, you should know
>>>>> that users can change the bundle name as he wish in our tools,
>>>>> OSGiMaker has supplies the feature already, we have a GUI bundle edit
>>>>> editor
>>>>>
>>>>>> 2) The imports look like they sometimes contain classes? And it would be
>>>>>> nice if you put a </br> after each one of them (maybe combine the ones
>>>>>> with the same prefix?)
>>>>>
>>>>> No, the imports are all package, i add a "<br />" every 5 imports, if
>>>>> we add a "<br/>" after each of them, it will be a long list, not very
>>>>> comfortable to read
>>>>>
>>>>>> 3) Can you sort on the number of contains entries? I.e. biggest bundle
>>>>>> first
>>>>>
>>>>> Yeah, i have sorted it already, the biggest first
>>>>>
>>>>>> 4) Could you link the bundles with an <a href="..">R18</a>?
>>>>>
>>>>> Yeah, i have add the http link already in the report
>>>>>
>>>>>> 5) Could you make the names of the
>>>>>
>>>>> ???
>>>>>
>>>>>
>>>>>> 6) Get rid of the .*?
>>>>>
>>>>> It is easy to get rid of the .*, but i think it make things more
>>>>> clear, make us know, the bundles includes all the classes in the
>>>>> packages
>>>>>
>>>>>> 7) Also generate one of these for catalina/Tomcat?
>>>>>>
>>>>>> Actually, this spring one is pretty neat.
>>>>>>
>>>>>> I am a bit curious about the jdbc stuff. I assume all the packages in
>>>>>> org.springframework.jdbc11 are strongly connected? What are the packages
>>>>>> that refer to com.ibm.websphere.rsadapter and com.mchange.v2.c3p0, etc?
>>>>>> These are the VERY expensive dependencies and I wonder how they get
>>>>>> merged in so badly in this bundle.
>>>>>>
>>>>>> Similar to the orm bundle, who is the culprit (class?) that points to
>>>>>> hibernate? You see why this is bad? In a good design the
>>>>>> org.springframework.orm should not be strongly connected to something
>>>>>> like hibernate. The hibernate should be a bridge package but not have
>>>>>> internal references.
>>>>>
>>>>>>
>>>>>> Interesting! Kind regards,
>>>>>>
>>>>>> Peter Kriens
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 29 jul 2011, at 11:32, Tiger Gui wrote:
>>>>>>
>>>>>>> Hi Peter,
>>>>>>>
>>>>>>> To visualize things, i have a simple review to JUNG, it seems that it
>>>>>>> is good solution for display graph or tree in a canvas, but it is a
>>>>>>> problem that JUNG is developed for AWT/SWING, not suitable for Eclipse
>>>>>>> SWT/JFace environment, so, i will continue searching for the best
>>>>>>> solution, may be we can even consider Eclipse GMF technology
>>>>>>>
>>>>>>>
>>>>>>> To report things:
>>>>>>> I have changed the report to a HTML file in the attach file, it's
>>>>>>> still Spring's OSGi split report, it looks much better :-)
>>>>>>>
>>>>>>> 2011/7/29 Peter Kriens <peter.kri...@aqute.biz>:
>>>>>>>> Rule #1, as long as I see you're engaged you do not have to worry
>>>>>>>> about the evaluation. So do not do things for my sake, do them because
>>>>>>>> you believe it is the best way forward. I think Tinkerpop and JUNG are
>>>>>>>> a great way to visualize, but do not take my word. I have the greatest
>>>>>>>> respect for people who do not listen to me because they are convinced
>>>>>>>> they know better. That out of the way.
>>>>>>>>
>>>>>>>> This whole things is very much about understanding and our visual
>>>>>>>> brains is by far the most powerful tool on earth to understand things.
>>>>>>>> And you're not taking advantage of it :-) We are looking for structure
>>>>>>>> here, the names are only relevant later. So to see structure, tables
>>>>>>>> are perfect. Which means you have to have short names. Just using the
>>>>>>>> last part of a package (com.springframework.jca, take jca). I.e. a
>>>>>>>> name like round1MergeBundle8 is ok to call b8. You can always later
>>>>>>>> provide a list of translations. This is also the reason why we need to
>>>>>>>> use packages, classes are too many off. Visualization is everything in
>>>>>>>> this phase because we need to find the rules of the structure.
>>>>>>>>
>>>>>>>> So lets retry. First give me a list of all groups (named g1 .. gn) and
>>>>>>>> their package content
>>>>>>>>
>>>>>>>>
>>>>>>>> Group Contains Uses Used By
>>>>>>>> External
>>>>>>>> g3 com.springframework.{jca,jdbc,...}, g4, g5, g7 g2
>>>>>>>> org.w3.xml, javax.persistence,
>>>>>>>> ...
>>>>>>>> com.oracle.g11.{impl,whatever}
>>>>>>>>
>>>>>>>> It might be easiest to generate HTML so you can use tables. Don't make
>>>>>>>> it look fancy, just use the tools to get insight in the structure:
>>>>>>>>
>>>>>>>> <html>
>>>>>>>> <body>
>>>>>>>> <table>
>>>>>>>> <tr>
>>>>>>>> <th>Group</th>
>>>>>>>> <th>Contains</th>
>>>>>>>> <th>Uses</th>
>>>>>>>> <th>Used By</th>
>>>>>>>> <th>External</th>
>>>>>>>> </tr>
>>>>>>>> <tr>
>>>>>>>> <td>g3</td>
>>>>>>>> <td>com.springframework.{jca,jdbc,...},...</td>
>>>>>>>> <td>g4, g5, g7</td>
>>>>>>>> <td>g2</td>
>>>>>>>> <td>org.w3.xml,
>>>>>>>> javax.persistence,com.oracle.g11.{impl,whatever}</td>
>>>>>>>> </tr>
>>>>>>>> </table>
>>>>>>>> </body>
>>>>>>>> </html>
>>>>>>>>
>>>>>>>> Shortening the names is everything or else your eyes drown in a sea of
>>>>>>>> characters.
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>>
>>>>>>>> Peter Kriens
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 29 jul 2011, at 05:16, Tiger Gui wrote:
>>>>>>>>
>>>>>>>>> Hi Peter,
>>>>>>>>>
>>>>>>>>> Thank you for your reply first, please see the following comments
>>>>>>>>>
>>>>>>>>> 2011/7/28 Peter Kriens <peter.kri...@aqute.biz>:
>>>>>>>>>> It is good that you use a real project now. What I like to see how
>>>>>>>>>> many "bundles" we have after the first round, where you group
>>>>>>>>>> strongly connected packages. This should already simplify because
>>>>>>>>>> the nr of entities will be smaller.
>>>>>>>>>>
>>>>>>>>>> I need to see a real case. Step 1 is ok, but maybe you can add
>>>>>>>>>> merging of bundles that have identical usesExternal (imports).
>>>>>>>>>
>>>>>>>>> Yes, I do merge the bundles that have identical usesExternal
>>>>>>>>> (imports), i described in the former mail,
>>>>>>>>>
>>>>>>>>> We define sameUE: it menas the number of two bundles have same
>>>>>>>>> usedExternal external package rely elements.
>>>>>>>>>
>>>>>>>>> boolean condition2 = 3 * sameUE >= one.usedExternalList.size() +
>>>>>>>>> two.usedExternalList.size();
>>>>>>>>>
>>>>>>>>> if(condition2 == true) i will merge bundles one and two,In the process
>>>>>>>>> of real case test(Spring and Tomcat), i found that it's hardly to find
>>>>>>>>> two bundles which have exactly the same usesExternal items, we should
>>>>>>>>> also merge bundles who have *proportional* usesExternal items. In my
>>>>>>>>> test case, it works good.
>>>>>>>>>
>>>>>>>>>> And make sure you ignore all java.* to make the info smaller (in
>>>>>>>>>> OSGi, java is always provided by the VM). Can you just print out
>>>>>>>>>> something like
>>>>>>>>>
>>>>>>>>> Yes, i have considered this situation, in the whole merge process, we
>>>>>>>>> do not consider jdk supplies java.* classes.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> name usesInternal usesExternal
>>>>>>>>>> g1 g2 a,b,c
>>>>>>>>>> g2 d,e,f
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Let's take example of Spring, this report is like this:
>>>>>>>>> Name ---
>>>>>>>>> usesInternal
>>>>>>>>> org.springframework.jms2
>>>>>>>>> ---round1MergeBundle8,mergedBundle9,org.springframework.jca22,org.springframework.scheduling15,org.springframework.context14,round1MergeBundle5
>>>>>>>>> org.springframework.jdbc11 ---
>>>>>>>>> round1MergeBundle8,mergedBundle9
>>>>>>>>> org.springframework.orm13
>>>>>>>>> ---
>>>>>>>>> round1MergeBundle8,org.springframework.jdbc11,mergedBundle9,round1MergeBundle3
>>>>>>>>> org.springframework.context14
>>>>>>>>> --- round1MergeBundle8,round1MergeBundle1,mergedBundle9
>>>>>>>>> org.springframework.scheduling15
>>>>>>>>> ---
>>>>>>>>> round1MergeBundle8,mergedBundle9,org.springframework.context14,org.springframework.jdbc11
>>>>>>>>> org.springframework.jca22
>>>>>>>>> ---
>>>>>>>>> round1MergeBundle8,mergedBundle9,org.springframework.context14,org.springframework.scheduling15
>>>>>>>>> round1MergeBundle1
>>>>>>>>> ---
>>>>>>>>> round1MergeBundle8,mergedBundle9,org.springframework.metadata7
>>>>>>>>> round1MergeBundle3
>>>>>>>>> ---
>>>>>>>>> round1MergeBundle8,org.springframework.context14,round1MergeBundle5
>>>>>>>>> round1MergeBundle4 ---
>>>>>>>>> round1MergeBundle8,org.springframework.context14
>>>>>>>>> round1MergeBundle5
>>>>>>>>> ---
>>>>>>>>> round1MergeBundle8,round1MergeBundle3,org.springframework.context14,mergedBundle9
>>>>>>>>> mergedBundle9
>>>>>>>>> ---
>>>>>>>>> round1MergeBundle8,round1MergeBundle5,org.springframework.context14,org.springframework.metadata7
>>>>>>>>> org.springframework.metadata7 --- none
>>>>>>>>> round1MergeBundle8 --- none
>>>>>>>>>
>>>>>>>>> As usesExternal element list is too long, i abridged them, you can get
>>>>>>>>> the report details with usesExternal elements in attach file
>>>>>>>>> "bundles_relation.txt", and get the bundles details in attach file
>>>>>>>>> "SpringSplitTest.analyse"
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I hope we see one big bundle which is the core and then have to find
>>>>>>>>>> rules to classify the remaining bundles. I expect there are the
>>>>>>>>>> following categories:
>>>>>>>>>>
>>>>>>>>>> core implementation classes, lots of strongly connected
>>>>>>>>>> packages
>>>>>>>>>> api api classes, do not refer to core, very few imports
>>>>>>>>>> bridge refer strongly to core and have expensive imports
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> At this stage, the trick is to do some work by hand until you find
>>>>>>>>>> you really understand the problem.
>>>>>>>>>>
>>>>>>>>>> It would be perfect if you could take a look at Tinkerpop and JUNG.
>>>>>>>>>> I think it would be quite easy to visualize the graph of
>>>>>>>>>> dependencies.
>>>>>>>>>
>>>>>>>>> You mean my next step is developing a Tinkerpop or JUNG graphical view
>>>>>>>>> for this report for user to adjust the bundles details manully ? Am i
>>>>>>>>> right ? I will start learn Jung and start this job soon
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Kind regards,
>>>>>>>>>>
>>>>>>>>>> Peter Kriens
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 26 jul 2011, at 16:24, Tiger Gui wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Peter,
>>>>>>>>>>>
>>>>>>>>>>> This is the whole application split algorithm here. After
>>>>>>>>>>> application
>>>>>>>>>>> source code analyse algorithm described here[1], we can know each
>>>>>>>>>>> package/class use which packages/classes and be used by which
>>>>>>>>>>> packages/classes. Now, we just discuss package here, we treat
>>>>>>>>>>> package
>>>>>>>>>>> as a single atom, each package has three important attributes,
>>>>>>>>>>> usedBy,
>>>>>>>>>>> usesExternal and usesInternal, just like below:
>>>>>>>>>>>
>>>>>>>>>>> <package name="org.apache.catalina.deploy"
>>>>>>>>>>> sources="/E:/GSoC/gsoc2011osgi/runtime-New_configuration/TomcatJava/bin"
>>>>>>>>>>> size="30" usedBy="8" usesInternal="11" usesExternal="14" layer="6"
>>>>>>>>>>> cycle="org.apache.catalina et al.">
>>>>>>>>>>> <packageRef name="org.apache.catalina.core" type="usedBy"/>
>>>>>>>>>>> <packageRef name="org.apache.catalina.startup" type="usedBy"/>
>>>>>>>>>>> <packageRef name="org.apache.catalina.deploy" type="usedBy"/>
>>>>>>>>>>> <packageRef name="org.apache.catalina.authenticator"
>>>>>>>>>>> type="usedBy"/>
>>>>>>>>>>> <packageRef name="org.apache.catalina" type="usedBy"/>
>>>>>>>>>>> <packageRef name="org.apache.catalina.mbeans" type="usedBy"/>
>>>>>>>>>>> <packageRef name="org.apache.catalina.connector"
>>>>>>>>>>> type="usedBy"/>
>>>>>>>>>>> <packageRef name="org.apache.catalina.realm" type="usedBy"/>
>>>>>>>>>>> <packageRef name="java.lang" type="usesExternal"/>
>>>>>>>>>>> <packageRef name="java.io" type="usesExternal"/>
>>>>>>>>>>> <packageRef name="org.apache.catalina.deploy"
>>>>>>>>>>> type="usesInternal"/>
>>>>>>>>>>> <packageRef name="org.apache.catalina.util"
>>>>>>>>>>> type="usesInternal"/>
>>>>>>>>>>> <packageRef name="java.util" type="usesExternal"/>
>>>>>>>>>>> <packageRef name="org.apache.juli.logging"
>>>>>>>>>>> type="usesInternal"/>
>>>>>>>>>>> <packageRef name="org.apache.tomcat.util.res"
>>>>>>>>>>> type="usesInternal"/>
>>>>>>>>>>> <packageRef name="java.beans" type="usesExternal"/>
>>>>>>>>>>> <packageRef name="(default package)" type="usesExternal"/>
>>>>>>>>>>> <packageRef name="org.apache.catalina" type="usesInternal"/>
>>>>>>>>>>> <packageRef name="org.apache.catalina.mbeans"
>>>>>>>>>>> type="usesInternal"/>
>>>>>>>>>>> <packageRef name="javax.management" type="usesExternal"/>
>>>>>>>>>>> <packageRef name="namingResources" type="usesExternal"/>
>>>>>>>>>>> <packageRef name="javax.naming" type="usesExternal"/>
>>>>>>>>>>> <packageRef name="org.apache.naming" type="usesInternal"/>
>>>>>>>>>>> <packageRef name="java.lang.reflect" type="usesExternal"/>
>>>>>>>>>>> <packageRef name="javax.servlet" type="usesInternal"/>
>>>>>>>>>>> <packageRef name="javax.servlet.annotation"
>>>>>>>>>>> type="usesInternal"/>
>>>>>>>>>>> <packageRef name="org.apache.catalina.order"
>>>>>>>>>>> type="usesExternal"/>
>>>>>>>>>>> <packageRef name="java.net" type="usesExternal"/>
>>>>>>>>>>> <packageRef name="webXml" type="usesExternal"/>
>>>>>>>>>>> <packageRef name="webXml.version" type="usesExternal"/>
>>>>>>>>>>> <packageRef name="webxml" type="usesExternal"/>
>>>>>>>>>>> <packageRef name="org.apache.catalina.core"
>>>>>>>>>>> type="usesInternal"/>
>>>>>>>>>>> <packageRef name="javax.servlet.descriptor"
>>>>>>>>>>> type="usesInternal"/>
>>>>>>>>>>> </package>
>>>>>>>>>>>
>>>>>>>>>>> usedBy means who use current package;
>>>>>>>>>>> usesInternal means which packages current package use in current
>>>>>>>>>>> application source code;
>>>>>>>>>>> usesExternal means which packages current pakcage use not in current
>>>>>>>>>>> application's source code.
>>>>>>>>>>>
>>>>>>>>>>> Now, we start split the whole application in to bundles, according
>>>>>>>>>>> to
>>>>>>>>>>> above algorithm source code analyse algorithm, we can also know
>>>>>>>>>>> package cycles in current application.
>>>>>>>>>>>
>>>>>>>>>>> 1. Treat each package cycle as a single bundle;
>>>>>>>>>>> 2. Treat each packages not in cycle as a single bundle;
>>>>>>>>>>> 3. Then we should decide which bundles can be merged into one new
>>>>>>>>>>> bundle;
>>>>>>>>>>>
>>>>>>>>>>> First round merge job:
>>>>>>>>>>> 4. If one bundle's all usesInternal elements are in the other
>>>>>>>>>>> bundle,
>>>>>>>>>>> these two bundles should be merged into a new bundle;
>>>>>>>>>>>
>>>>>>>>>>> Think about how to merge used by only bundle (bundle be used only by
>>>>>>>>>>> other bundle, it does not rely on any other bundle):
>>>>>>>>>>> Define two variable for used by only bundle:
>>>>>>>>>>> sameUB: it means the number of two bundles have same usedBy
>>>>>>>>>>> elements.
>>>>>>>>>>> sameUE: it menas the number of two bundles have same usedExternal
>>>>>>>>>>> external package rely elements.
>>>>>>>>>>>
>>>>>>>>>>> boolean condition1 = 4 * sameUB >= one.usedByList.size() +
>>>>>>>>>>> two.usedByList.size();
>>>>>>>>>>> boolean condition2 = 2 * sameUE >= one.usedExternalList.size() +
>>>>>>>>>>> two.usedExternalList.size();
>>>>>>>>>>>
>>>>>>>>>>> if condition1 or condition2 is true, we should merge these two
>>>>>>>>>>> usedBy
>>>>>>>>>>> only bundle.
>>>>>>>>>>>
>>>>>>>>>>> Merge the other bundles:
>>>>>>>>>>> 5.The core problem is how to decide two bundles(bundle one and
>>>>>>>>>>> bundle
>>>>>>>>>>> two) can be merged or not.
>>>>>>>>>>>
>>>>>>>>>>> Define 5 variables:
>>>>>>>>>>> uiNumber: the sum of bundle one's usesInternal elements in bundle
>>>>>>>>>>> two
>>>>>>>>>>> number and bundle two's usesInternal elements in bundle one number;
>>>>>>>>>>>
>>>>>>>>>>> ubNumber:the sum of bundle one's usedBy elements in bundle two
>>>>>>>>>>> number
>>>>>>>>>>> and bundle two's usedBy elements in bundle one number;
>>>>>>>>>>>
>>>>>>>>>>> sameUI: the same usesInternal number bundle one and two have
>>>>>>>>>>>
>>>>>>>>>>> sameUB: Be similar with used by only bundle's this variable
>>>>>>>>>>>
>>>>>>>>>>> sameUE: Be similar with used by only bundle's this variable
>>>>>>>>>>>
>>>>>>>>>>> Define these conditions:
>>>>>>>>>>> boolean condition1 = 2 * uiNumber >= one.usesInternalList.size() +
>>>>>>>>>>> two.usesInternalList.size();
>>>>>>>>>>> boolean condition2 = 2 * ubNumber >= one.usedByList.size() +
>>>>>>>>>>> two.usedByList.size() ;
>>>>>>>>>>> boolean condition3 = 3.5 * sameUI >= one.usesInternalList.size() +
>>>>>>>>>>> two.usesInternalList.size();
>>>>>>>>>>> boolean condition4 = 4 * sameUB >= one.usedByList.size() +
>>>>>>>>>>> two.usedByList.size();
>>>>>>>>>>> boolean condition5 = 3 * sameUE >= one.usedExternalList.size() +
>>>>>>>>>>> two.usedExternalList.size();
>>>>>>>>>>>
>>>>>>>>>>> If any above condition is true, these two bundles can be merged. But
>>>>>>>>>>> these are another problem, if bundle A can be merged with B, but it
>>>>>>>>>>> also can be merged with C, now, we should decide merge A with B or A
>>>>>>>>>>> with C.
>>>>>>>>>>>
>>>>>>>>>>> Define the follow attribute:
>>>>>>>>>>> int mergeFactor= 2 * (uiNumber + ubNumber) + 0.4 * (sameUI +
>>>>>>>>>>> sameUB) +
>>>>>>>>>>> 0.2 * sameUE - number;
>>>>>>>>>>>
>>>>>>>>>>> If A and B's mergeFactor is 20 and A and C's mergeFactor is 30, we
>>>>>>>>>>> should merge A and C.
>>>>>>>>>>>
>>>>>>>>>>> This is current merge algorithm in OSGiMaker, i will keep on
>>>>>>>>>>> improving
>>>>>>>>>>> it, use class relationship factors or etc. You can find the source
>>>>>>>>>>> code detail of this algorithm in class AnalyseJob of our project.
>>>>>>>>>>>
>>>>>>>>>>> The attach file is the analyse result document OSGiMaker analyse
>>>>>>>>>>> Tomcat's source code and split it into bundles, you can have a
>>>>>>>>>>> review.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> In fact, i did not want to bother you too much, but it seems that
>>>>>>>>>>> you
>>>>>>>>>>> have enough time to help me to improve it, this is a good thing. If
>>>>>>>>>>> you have any advises, please let me know, let's improving it
>>>>>>>>>>> together
>>>>>>>>>>> :-)
>>>>>>>>>>>
>>>>>>>>>>> Thank you
>>>>>>>>>>>
>>>>>>>>>>> [1]
>>>>>>>>>>> http://code.google.com/p/osgimaker/wiki/Implement_of_project_analyse_algorithm
>>>>>>>>>>>
>>>>>>>>>>> 2011/7/26 Peter Kriens <peter.kri...@aqute.biz>:
>>>>>>>>>>>> Well, I do not think I am eager but I have a hard time getting a
>>>>>>>>>>>> feeling where you are. You do not have to send reports, I want to
>>>>>>>>>>>> see intermediate results and discuss issues if there are any. As I
>>>>>>>>>>>> said earlier, it is not clear to me yet what the best algorithm is
>>>>>>>>>>>> so that need to be worked out before we do the gui stuff.
>>>>>>>>>>>>
>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Peter Kriens
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 26 jul 2011, at 11:24, Tiger Gui wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> In my schedule, i will report current status to you tomorrow as i
>>>>>>>>>>>>> think i can get a usable version today, the whole analyse and
>>>>>>>>>>>>> split
>>>>>>>>>>>>> algorithm is complex i have to organize a document to describe it
>>>>>>>>>>>>> clearly. As you are really eager to see its progress, it is OK, i
>>>>>>>>>>>>> will
>>>>>>>>>>>>> start the report now
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2011/7/26 Peter Kriens <peter.kri...@aqute.biz>:
>>>>>>>>>>>>>> If that is the case you have to provide more on going feedback.
>>>>>>>>>>>>>> What happened to the analysis by hand?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Peter Kriens
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 26 jul 2011, at 11:02, Tiger Gui wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, Peter, i am really working hard for this project, you can
>>>>>>>>>>>>>>> check
>>>>>>>>>>>>>>> the progress here[1]. Now, this tool can analyse a whole
>>>>>>>>>>>>>>> project and
>>>>>>>>>>>>>>> export the its analyse result to bundles( I test it in Spring
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> Tomcat project), if possible, you can install it in your
>>>>>>>>>>>>>>> Eclipse and
>>>>>>>>>>>>>>> have a trial of it. But, i am still improving the split
>>>>>>>>>>>>>>> algorithm as
>>>>>>>>>>>>>>> the current algorithm is not working perfect.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I will supply a document about the current status of this
>>>>>>>>>>>>>>> project and
>>>>>>>>>>>>>>> a simple guide for you to have a trial of it. I am really
>>>>>>>>>>>>>>> working very
>>>>>>>>>>>>>>> hard for it these days :-(
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [1] http://code.google.com/p/osgimaker/updates/list
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2011/7/26 Peter Kriens <peter.kri...@aqute.biz>:
>>>>>>>>>>>>>>>> I am getting the feeling that you're not working very hard on
>>>>>>>>>>>>>>>> this project and only does something just for the evaluations
>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Peter Kriens
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Best Regards
>>>>>>>>>>>>>>> ----------------------------------------------------
>>>>>>>>>>>>>>> Tiger Gui [tigergui1...@gmail.com]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Best Regards
>>>>>>>>>>>>> ----------------------------------------------------
>>>>>>>>>>>>> Tiger Gui [tigergui1...@gmail.com]
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Best Regards
>>>>>>>>>>> ----------------------------------------------------
>>>>>>>>>>> Tiger Gui [tigergui1...@gmail.com]
>>>>>>>>>>> <TomcatJava.analyse>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Best Regards
>>>>>>>>> ----------------------------------------------------
>>>>>>>>> Tiger Gui [tigergui1...@gmail.com]
>>>>>>>>> <bundles_relation.txt><SpringSplitTest.analyse>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Best Regards
>>>>>>> ----------------------------------------------------
>>>>>>> Tiger Gui [tigergui1...@gmail.com]
>>>>>>> <SpringSplitTest.html>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best Regards
>>>>> ----------------------------------------------------
>>>>> Tiger Gui [tigergui1...@gmail.com]
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best Regards
>>>> ----------------------------------------------------
>>>> Tiger Gui [tigergui1...@gmail.com]
>>>> <TomcatJava.html>
>>>
>>>
>>
>>
>>
>> --
>> Best Regards
>> ----------------------------------------------------
>> Tiger Gui [tigergui1...@gmail.com]
>>
>
>
>
> --
> Best Regards
> ----------------------------------------------------
> Tiger Gui [tigergui1...@gmail.com]
>
--
Best Regards
----------------------------------------------------
Tiger Gui [tigergui1...@gmail.com]
