What would be nice if you could zoom into a bundle and see the package relations inside the bundle/group. Then zoom in the packages and see the classes. The connections between the classes/packages/bundles could also use some color/transparency coding. So that an expensive connection would look dark red and an expensive connection light gray. Note hat expensive is not many but shared by very few entities inside the enclosure. I.e. if only one class in a package of 10 classes causes a certain dependency then that is an expensive dependency.
You could also take a loot at this article for ideas how to visualize classes/packages/modules: https://docs.google.com/document/pub?id=1_yOUl4mGq9ZTPIAR-sB2Q1kcS7N0U0D5z97zUx0hCDY Kind regards, Peter Kriens On 11 aug 2011, at 08:14, Tiger Gui wrote: > Ok, i will keep on improving the visualization things and improve the > split algorithm according to the visualization result :-) > > 2011/8/10 Peter Kriens <peter.kri...@aqute.biz>: >> Make sure you get the naming + layout right on these examples before you >> take other products. This is the stage where you really want to focus on the >> tool. You now get more understanding of the problem because you now know the >> structure. So I really think we now should do: >> >> - better visualization of the contents (naming mostly, maybe show the >> inside package names when zoomed) >> - show the imports somehow >> >> It is not that useful to now analyze a lot of projects, it is understanding >> the structure of the projects that counts. These lessons must then be >> applied to other projects, which will give new problems, solve them, ad >> nauseum. >> >> But this is really starting to look interestingly. >> >> Kind regards, >> >> Peter Kriens >> >> >> On 10 aug 2011, at 08:29, Tiger Gui wrote: >> >>> And this is Spring's packages relation figure and bundles relationship >>> figure in the attach png files. And you can get the bundle details in >>> the html split report generated by OSGiMaker. >>> >>> Now, we use Jung to read the visualize the split result of OSGiMaker, >>> in the next few days, i will integrate the visualize tool with >>> OSGiMaker, help users to check the bundles relation in the Eclipse >>> once he use OSGiMaker to split the application. >>> >>> 2011/8/9 Peter Kriens <peter.kri...@aqute.biz>: >>>> This is starting to look really interesting! >>>> >>>> Can you make your own layout? Would be nice to sort the "bundles" in >>>> layers. The core should be at the bottom and when you go up, you should >>>> see the higher layers depend on the lower layers. This is never perfect >>>> but you cannot have cycles by definition, they've been removed earlier. >>>> >>>> It is important to minimize the number of imports so they need also be >>>> grouped in such a way that you have a minimum set of import groups. They >>>> should be visible on the edge of the picture >>>> >>>> Also spend some time on shortening the names without loosing the >>>> recognition. >>>> >>>> Good work! As I said, visualizing this stuff is all important. >>>> >>>> Kind regards, >>>> >>>> Peter Kriens >>>> >>>> >>>> On 9 aug 2011, at 08:43, Tiger Gui wrote: >>>> >>>>> 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] >>>>> <TomcatJava.html><tomat.png><tomcat2.png> >>>> >>>> >>> >>> >>> >>> -- >>> Best Regards >>> ---------------------------------------------------- >>> Tiger Gui [tigergui1...@gmail.com] >> >> > > > > -- > Best Regards > ---------------------------------------------------- > Tiger Gui [tigergui1...@gmail.com]
