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]
