Hi Peter, Are you clear about the current algorithm ? In fact, i am a little puzzled about the next step optimize iteration....
2011/7/26 Tiger Gui <tigergui1...@gmail.com>: > 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] > -- Best Regards ---------------------------------------------------- Tiger Gui [tigergui1...@gmail.com]
