664 eclipse plugin

394 views

Published on

Published in: Technology, Art & Photos
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
394
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
5
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

664 eclipse plugin

  1. 1. The Evolution of Eclipse Plugins Michel Wermelinger, Yijun Yu Centre for Research in Computing The Open University Milton Keynes, UK Presented By: Arnamoy Bhattacharyya
  2. 2. Each release (except for release 1.0) provides one or more high-levelfeatures.
  3. 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.g feature sdk includes feature platform which in turn includes rcp
  4. 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.g feature 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. 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.g feature 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. 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. 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. 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 Y X dynamically depends on Y if X uses an extension point that Y provides
  9. 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 Y X dynamically depends on Y if X uses an extension point that Y providesplugins, extension points, and static and dynamic dependencies arearchitectural elements
  10. 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 Y X 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. 11. logical ordereach release may have multiple logical successors.
  12. 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. 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. 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 relations Crocopat, a relational calculatorproduces output metrics and further relations.
  15. 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 relations Crocopat, a relational calculatorproduces output metrics and further relations.
  16. 16. For each release compute – dynamic dependency relations the missing and unused extensionpoints the missing and unused plugins sizes of those sets.
  17. 17. For each release compute – dynamic dependency relations the missing and unused extensionpoints An element is missing if it is required but the missing and unused plugins not provided, and unused if it is provided sizes of those sets. but not required by any other element.
  18. 18. For each release compute – dynamic dependency relations the missing and unused extensionpoints An element is missing if it is required but the missing and unused plugins not provided, and unused if it is provided sizes 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. 19. For each release compute – dynamic dependency relations the missing and unused extensionpoints An element is missing if it is required but the missing and unused plugins not provided, and unused if it is provided sizes 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. 20. RESULTS AND ANALYSISFor both release sequences, it is found out that thenumber of missing plugins and extension points isalways zero,
  21. 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 previous release (K), kept from r1 (K1), and deleted (D).
  22. 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. 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. 24. Is the architecture changed in maintenance releases? NO plugins or extension points are added or deleted in any maintenance release
  25. 25. Is there anydifference betweenmilestones andrelease candidates,in terms ofarchitecturalevolution? architectural changes can occur in both milestones & release candidates, more changes during milestones.
  26. 26. Are there any deletions, or just additions?Both figures show, additions make the bulk of changes,deletions being comparatively few and small in size.
  27. 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. 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. 29. Most deletions occurred in release 3.0, with many static dependencies being alsoremoved
  30. 30. Most deletions occurred in release 3.0, with many static dependencies being alsoremoved
  31. 31. Eclipse project follows a systematic process most architectural changes process,taking place in milestones, a few in release candidates. Conclusions
  32. 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. 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. 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. 35. Questions?

×