PDE Good Practices Ankur Sharma Eclipse PDE co-lead @ankur_sharma http://blog.ankursharma.org
#1 Separation of Concerns <ul><li>A plug-in is used to group your code into a modular, extendable and sharable unit.
Do not create monolithic plug-ins
Separate the platform/locale code into fragments
Separate Core, UI, Doc, etc </li></ul>
#2 bundle-localization <ul><li>Externalize bundle strings
‘Usage of non-externalized strings’ preference </li></ul>
 
 
 
 
#3 Lazy-loading <ul><li>Prefer to have lazy loading plug-ins </li><ul><li>Helps reduce memory footprint
Every plug-in loads with a dependency baggage
Judiciously make plug-ins reusable </li></ul></ul>
#3 Singletons <ul><li>Prefer singleton plug-ins </li><ul><li>but there is a cost involved
singleton plug-ins can not be dynamically installed </li></ul></ul>
 
 
#4 Use startup code carefully <ul><li>Plug-in startup and constructor
org.eclipse.ui.startup extension </li></ul>
#5 Prefer target over workspace <ul><li>Prefer adding the required plug-ins to Target Platform
Adding them to workspace makes it difficult to track and manage. </li></ul>
Upcoming SlideShare
Loading in...5
×

PDE Good Practices

478

Published on

presented at Eclipse Day India 2011

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

  • Be the first to like this

No Downloads
Views
Total Views
478
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

PDE Good Practices

  1. 1. PDE Good Practices Ankur Sharma Eclipse PDE co-lead @ankur_sharma http://blog.ankursharma.org
  2. 2. #1 Separation of Concerns <ul><li>A plug-in is used to group your code into a modular, extendable and sharable unit.
  3. 3. Do not create monolithic plug-ins
  4. 4. Separate the platform/locale code into fragments
  5. 5. Separate Core, UI, Doc, etc </li></ul>
  6. 6. #2 bundle-localization <ul><li>Externalize bundle strings
  7. 7. ‘Usage of non-externalized strings’ preference </li></ul>
  8. 12. #3 Lazy-loading <ul><li>Prefer to have lazy loading plug-ins </li><ul><li>Helps reduce memory footprint
  9. 13. Every plug-in loads with a dependency baggage
  10. 14. Judiciously make plug-ins reusable </li></ul></ul>
  11. 15. #3 Singletons <ul><li>Prefer singleton plug-ins </li><ul><li>but there is a cost involved
  12. 16. singleton plug-ins can not be dynamically installed </li></ul></ul>
  13. 19. #4 Use startup code carefully <ul><li>Plug-in startup and constructor
  14. 20. org.eclipse.ui.startup extension </li></ul>
  15. 21. #5 Prefer target over workspace <ul><li>Prefer adding the required plug-ins to Target Platform
  16. 22. Adding them to workspace makes it difficult to track and manage. </li></ul>
  17. 23. #6 Share target definitions
  18. 24. #7 Keep build.properties synced <ul><li>Export wizard and headless build uses build.properties
  19. 25. Use build preferences to keep it in sync with classpath
  20. 26. This helps avoid “ …but it was working in my workspace! ” situations. </li></ul>
  21. 28. #8 EE and Java compliance <ul><li>Set the Execution Environments to the lowest required JRE version.
  22. 29. Set the appropriate Java Compiler preferences </li></ul>
  23. 30. #9 Use proper version ranges <ul><li>Use proper version restrictions
  24. 31. Also helps in catching API breakages </li></ul>
  25. 32. #10 Versions are not for marketing <ul><li>Version numbering is very important
  26. 33. Version numbers are not meant for marketing
  27. 34. Stick to major.minor.micro-qualifier
  28. 35. Bump up the correct number in version on releases. </li></ul>
  29. 36. #11 Define API carefully <ul><li>Put classes in correct packages
  30. 37. Public, internal and x-friends
  31. 38. Don’t re-export everything
  32. 39. An Eclipse API is forever </li></ul>
  33. 40. #12 Use API Tools <ul><li>API Tools will help you with </li><ul><li>#9 Use proper version ranges
  34. 41. #10 Versions are not for marketing
  35. 42. #11 Define API carefully </li></ul></ul>
  36. 43. thank you

×