Your SlideShare is downloading. ×
PDE Good Practices
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

PDE Good Practices

449
views

Published on

presented at Eclipse Day India 2011

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
449
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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