664 eclipse plugin

Download 664 eclipse plugin

Post on 19-Jun-2015

158 views

Category:

Technology

2 download

Embed Size (px)

TRANSCRIPT

<ul><li> 1. The Evolution of Eclipse PluginsMichel Wermelinger, Yijun Yu Centre for Research in Computing The Open University Milton Keynes, UK Presented By: Arnamoy Bhattacharyya</li></ul> <p> 2. Each release (except for release 1.0) provides one or more high-levelfeatures. 3. Each release (except for release 1.0) provides one or more high-levelfeatures.Each feature may be composed of other, more specialized, features. E.gfeature sdk includes feature platform which in turn includes rcp 4. Each release (except for release 1.0) provides one or more high-levelfeatures.Each feature may be composed of other, more specialized, features. E.gfeature sdk includes feature platform which in turn includes rcp Each feature is implemented by a set of plugins, e.g feature platform is implemented by more than 70 plugins 5. Each release (except for release 1.0) provides one or more high-levelfeatures.Each feature may be composed of other, more specialized, features. E.gfeature sdk includes feature platform which in turn includes rcp Each feature is implemented by a set of plugins, e.g feature platform is implemented by more than 70 plugins Each plugin may depend for its compilation on Java classes that belong to other plugins. E.g, the implementation of plugin platform depends on eight other plugins 6. Each plugin provides zero or more extension points. These can be usedat run-time by other plugins in order to extend the functionality. E.g theextension points provided by the ui plugin allow other plugins to add atruntime new GUI elements (menu bars, buttons, etc.). 7. Each plugin provides zero or more extension points. These can be usedat run-time by other plugins in order to extend the functionality. E.g theextension points provided by the ui plugin allow other plugins to add atruntime new GUI elements (menu bars, buttons, etc.). plugin X statically depends on plugin Y - if the compilation of X requires Y 8. Each plugin provides zero or more extension points. These can be usedat run-time by other plugins in order to extend the functionality. E.g theextension points provided by the ui plugin allow other plugins to add atruntime new GUI elements (menu bars, buttons, etc.). plugin X statically depends on plugin Y - if the compilation of X requires YX dynamically depends on Y if X uses an extension point that Y provides 9. Each plugin provides zero or more extension points. These can be usedat run-time by other plugins in order to extend the functionality. E.g theextension points provided by the ui plugin allow other plugins to add atruntime new GUI elements (menu bars, buttons, etc.). plugin X statically depends on plugin Y - if the compilation of X requires YX dynamically depends on Y if X uses an extension point that Y providesplugins, extension points, and static and dynamic dependencies arearchitectural elements 10. Each plugin provides zero or more extension points. These can be usedat run-time by other plugins in order to extend the functionality. E.g theextension points provided by the ui plugin allow other plugins to add atruntime new GUI elements (menu bars, buttons, etc.). plugin X statically depends on plugin Y - if the compilation of X requires YX dynamically depends on Y if X uses an extension point that Y providesplugins, extension points, and static and dynamic dependencies arearchitectural elements In parallel to the maintenance of the current major release, the preparation of the next major release starts. The preparation consists of some milestones, followed by some release candidates. 3.2M1 3.2RC1 11. logical ordereach release may have multiple logical successors. 12. DATA PROCESSINGFor each plugin there is an XML file, called plugin.xml that lists the plugin.xml,extension points provided and used by that plugin, and the otherplugins it depends on for compilation. 13. DATA PROCESSINGFor each plugin there is an XML file, called plugin.xml that lists the plugin.xml,extension points provided and used by that plugin, and the otherplugins it depends on for compilation.Since release 3.0, the static dependency is in another file,MANIFEST.MF,MANIFEST.MF which is not in XML format. 14. DATA PROCESSING download the source code of the whole SDK Some shell, AWK and XSLT scripts extract the information about theexisting architectural elements from the plugin.xml filesThe result of this processing is a text file in Rigi Standard Format (RSF) that captures the relationsCrocopat, a relational calculatorproduces output metrics and further relations. 15. DATA PROCESSING download the source code of the whole SDK Some shell, AWK and XSLT scripts extract the information about theexisting architectural elements from the plugin.xml filesThe result of this processing is a text file in Rigi Standard Format (RSF) that captures the relationsCrocopat, a relational calculatorproduces output metrics and further relations. 16. For each release compute dynamic dependency relationsthe missing and unused extensionpointsthe missing and unused pluginssizes of those sets. 17. For each release compute dynamic dependency relationsthe missing and unused extensionpoints An element is missing if it is required butthe missing and unused plugins not provided, and unused if it is providedsizes of those sets. but not required by any other element. 18. For each release compute dynamic dependency relationsthe missing and unused extensionpointsAn element is missing if it is required butthe missing and unused pluginsnot provided, and unused if it is providedsizes of those sets.but not required by any other element. The missing plugins and extension points enable to detect compile- and run- time problems, whereas the unused plugins and extension points tell us how extensible the architecture is. 19. For each release compute dynamic dependency relationsthe missing and unused extensionpointsAn element is missing if it is required butthe missing and unused pluginsnot provided, and unused if it is providedsizes of those sets.but not required by any other element. The missing plugins and extension points enable to detect compile- and run- time problems, whereas the unused plugins and extension points tell us how extensible the architecture is. A completely self-contained and closed architecture would have no missing nor unused elements. 20. RESULTS AND ANALYSISFor both release sequences, it is found out that thenumber of missing plugins and extension points isalways zero, 21. RESULTS AND ANALYSISFor both release sequences, it is found out that thenumber of missing plugins and extension points isalways zero, number of plugins (NP), extension points (NE), static dependencies (NSD), dynamic dependencies (NDD), and unused extension points (NUE).number of elements added (A), kept from the previousrelease (K), kept from r1 (K1), and deleted (D). 22. How many architectural changes occur between majorreleases and what is the overall growth of the system? the architecture has grown by a factor between four and five. The highest growth rate occurred from release 1.0 to release 2.0. 23. the architecture has grown by a factor between four and five. Thehighest growth rate occurred from release 1.0 to release 2.0. 24. Is the architecture changed in maintenance releases? NO plugins or extension points are added or deleted in any maintenance release 25. Is there anydifference betweenmilestones andrelease candidates,in terms ofarchitecturalevolution? architectural changes can occur in both milestones &amp; release candidates, more changes during milestones. 26. Are thereanydeletions, orjustadditions?Both figures show, additions make the bulk of changes,deletions being comparatively few and small in size. 27. Is there any substantial architectural core that is stable, i.e. thatremains throughout all releases? 11% (= 24) of the plugins and 14% of the extensions points of release 3.3.1.1 come from release 1.0. 28. Is there any substantial architectural core that is stable, i.e. thatremains throughout all releases? 11% (= 24) of the plugins and 14% of the extensions points of release 3.3.1.1 come from release 1.0. 29. Most deletions occurred in release 3.0, with many static dependencies being alsoremoved 30. Most deletions occurred in release 3.0, with many static dependencies being alsoremoved 31. Eclipse project follows a systematic process most architectural changes process,taking place in milestones, a few in release candidates. Conclusions 32. Eclipse project follows a systematic process most architectural changes process,taking place in milestones, a few in release candidates.Release 3.0 introduced major architectural changes with many additions changes,and deletions to all elements. Conclusions 33. Eclipse project follows a systematic process most architectural changes process,taking place in milestones, a few in release candidates.Release 3.0 introduced major architectural changes with many additions changes,and deletions to all elements. Conclusions 34. Eclipse project follows a systematic process most architectural changes process,taking place in milestones, a few in release candidates.Release 3.0 introduced major architectural changes with many additions changes,and deletions to all elements. Conclusions 35. Questions?</p>

Recommended

View more >