Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Automating the consumption of Eclipse for internal use


Published on

Supporting a large user base implies catering to a lot of different needs.

In Ericsson's case this means building over 20 different eclipse distributions and creating a corporate wide p2 repository to make it easy for our users to get all the plugins they need.
To achieve the necessary customization of each eclipse distro with a high degree of automation, a wide variety of technologies has been used: product files, jenkins, tycho, jbehave, p2 tools, etc.

In this talk, we give an overview of our semi-automated workflow, where each technology fits and give you our tips and tricks.

Published in: Software
  • Be the first to comment

Automating the consumption of Eclipse for internal use

  1. 1. Automating the consumption of Eclipse for internal use Pascal Rapicault Emilio Palmiero
  2. 2. › Building Eclipse distros › Creating an aggregated update site › End-2-end automation Outline
  3. 3. Building Eclipse Distros › Key concepts – Product file – Product extension – .eclipseproduct – Plugin customization (aka default preferences) – p2.inf › Tools used – Tycho – PDE – JBehave
  4. 4. › Describes a complete eclipse installation › Facade over multiple concerns – Features / plugins – Branding (icon, splash, about dialog) – Configuration (start level, VM settings, system property) › Development time “artefact” – Spread in product extension and p2 metadata Product file
  5. 5. › Product extension (extends org.eclipse.core.runtime.products xpt) – Reference branding images – Default preferences – Default application – Extensible set of key/value pairs › Available at runtime (e.g. accessed by the workbench, see IProduct API) Note: There can be multiple products in an installation, but only one runs. Product extension
  6. 6. Plug-in for branding Product extension Features being used org.eclipse.sdk Product file
  7. 7. › Customizing default preferences › Removing undesirable root files (or p2 IUs) › Adding root files › Adding a default repo <demo>
  8. 8. › Marker file used when install is read-only to compute the folder where eclipse will store configuration information. Should be changed. <demo support> .eclipseproduct E.g. ~/.eclipse/org.eclipse.platform_4.3.0_1354634885…
  9. 9. › You may want to replace or remove – bundles, features, root files, … › Several possibilities – Re-create feature – Create feature patches (only add and replace) – Forge identity CHANGE / REPLACE THINGS
  10. 10. FORGING IUs org.eclipse.sdk org.eclipse.platform_root Product IU
  11. 11. BDD-based testing It is about implementing an application by describing it from the point of view of its stakeholders. BDD chooses to use a semi-formal format for behavioral specification which is borrowed from user story specifications from the field of object-oriented analysis and design. Definition Scenario: check proxy setting Given eclipse Then the proxy for <protocol> should be <proxy> on port <port> Examples: |protocol|proxy|port| |http||8080| |https||8080|
  12. 12. Lessons learnED › Building a product is a detail oriented task – Start by the details! Prototype in the IDE using product editor and export from there. Adding all the plugins will slow down the feedback loop because the export will be slower. › Production build with Tycho › BDD is great way to get readable tests – Positive experience with JBehave community › Problems – Discrepancies between the real exported product and PDE and Tycho – The product file could use some improvements.
  13. 13. › What we build? – Standalone repository – Pre-validated for a given stream – Categorized for our users › Key concepts – p2 repository – Category › Tools used – b3 – p2 mirror – p2 category publisher One Update site to RULE tHEM ALL
  14. 14. › Each entry in the site must install › b3 – Validate, aggregate - Works great for “one-offs” › Problems – Not able to append to an existing repo Gather / ValidatE aggregation
  15. 15. › Entries must be categorized for our users › Category publisher – Write a category.xml – Run p2 category publisher › Category IUs are added by a composite repo categorization categories composite aggregation
  16. 16. › Don’t assume anything about repos (unless being told otherwise) › Completely isolate yourself from external repos –Mirror internally –Remove references › Problems –Duplication of the feature IDs between categories and aggregation Lessons LEARNED
  17. 17. › Key concepts – CI – Matrix jobs › Tool used – Jenkins + plugins End-2-end automation
  18. 18. WORKFLOW Merge with previous repo Create categories Mirror in Ericsson (p2 and legacy) Validate Aggregate Generate webpage Composite repo
  19. 19. › Jenkins is not an SCM – Keep the list of sites to mirror in your SCM › Minimize the number of jobs – E.g. we use Matrix builds › Work on a shared drive or specific Jenkins workspace – Save time by saving on files copy – Does not clutter slaves › Problems – Some duplication of URLs between what the b3 files refers to and our list of sites. – Build avoidance not supported on p2 metadata LESSONS LEARNED
  20. 20. Future WORK
  21. 21. Future WoRK › Contribute where there are limitations – B3 to generate the categories separately – Product file – Build avoidance › Express workflows using Jenkins’ Jenkow plug-in › “Standardize” structure of Eclipse repos to make discovery more easy.
  22. 22. › Many tools with their strengths and weaknesses but we love them for what they are ConcLUSION p2