This document provides 10 common pitfalls to avoid when using the Eclipse p2 system and how to properly manage plugins and repositories. It emphasizes letting p2 manage installations instead of manual changes, using repositories over zip files, always incrementing version numbers for changes, avoiding modifying released repositories, using categories and version ranges correctly, and utilizing the p2 publisher APIs instead of internal implementations. Overall it offers best practices for developing with p2 in a way that is stable, predictable and considerate of users.
Plug-ins are everywhere in Eclipse so come learn about how to develop them! Depending on the audience, for the first half of the talk, I will discuss what a plug-in is and what tooling is provided around developing plug-ins. For the second half, I will discuss tips and tricks that can save you time in developing plug-ins and will also talk about some lesser known, but extremely useful, parts of PDE.
Plug-ins are everywhere in Eclipse so come learn about how to develop them! Depending on the audience, for the first half of the talk, I will discuss what a plug-in is and what tooling is provided around developing plug-ins. For the second half, I will discuss tips and tricks that can save you time in developing plug-ins and will also talk about some lesser known, but extremely useful, parts of PDE.
L0016 - The Structure of an Eclipse Plug-inTonny Madsen
This is a detailed description of the different parts that makes up an Eclipse plug-in. The module focuses on the purpose of the different files of a plug-in such as plugin.xml and the OSGi manifest file, MANIFEST.MF. The module also describes how plug-ins are developed in Eclipse with PDE, the Plug-in Development Environment
Eclipse plug-in development seminar held by the Bulgarian Java User group covering basic aspects of Eclipse plug-in development and the new stuff in e4
The Tycho project aims to enable Maven to build Eclipse based artifacts (plugins, features, update sites, products). This presentation was held at a public event from itemis in Dortmund, showing how Tycho is used and some news to the upcoming Maven 3 release.
Automating the consumption of Eclipse for internal usePascal Rapicault
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.
Natalie Pistunovich
Engineering Manager – Fraugster
Natalie is an Engineering Manager, Go Developer, Berlin’s Go User Group Lead, GopherCon Europe organizer and Public Speaker. She also describes herself as a Passionate Learner and Professional Questions Asker.
The presentations shows some of the new features and projects of the Eclipse Mars (4.6) release.
This slide deck was presented in Eclipse Day 2015, Bangalore.
L0016 - The Structure of an Eclipse Plug-inTonny Madsen
This is a detailed description of the different parts that makes up an Eclipse plug-in. The module focuses on the purpose of the different files of a plug-in such as plugin.xml and the OSGi manifest file, MANIFEST.MF. The module also describes how plug-ins are developed in Eclipse with PDE, the Plug-in Development Environment
Eclipse plug-in development seminar held by the Bulgarian Java User group covering basic aspects of Eclipse plug-in development and the new stuff in e4
The Tycho project aims to enable Maven to build Eclipse based artifacts (plugins, features, update sites, products). This presentation was held at a public event from itemis in Dortmund, showing how Tycho is used and some news to the upcoming Maven 3 release.
Automating the consumption of Eclipse for internal usePascal Rapicault
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.
Natalie Pistunovich
Engineering Manager – Fraugster
Natalie is an Engineering Manager, Go Developer, Berlin’s Go User Group Lead, GopherCon Europe organizer and Public Speaker. She also describes herself as a Passionate Learner and Professional Questions Asker.
The presentations shows some of the new features and projects of the Eclipse Mars (4.6) release.
This slide deck was presented in Eclipse Day 2015, Bangalore.
Brief training targeted to middle school aged students who are participating in First Lego League robotics and planning to use a version control tool such as EV3Hub
Composer has triggered a renaissance in the PHP community, it has changed the way we deal with other people’s code and it has changed the way we share our code. We are all slowly moving to using Composer, from Wordpress to Joomla and Drupal and frameworks in between. But many of us mistreat composer, follow outdated practices or simply lack a few tricks. In this session i’ll get you the low down on how to use composer the right way.
During 10 years of working with technical sales of Industrial Linux systems I have often been meet with a somewhat religious technical discussion about "which" Linux to use and currently the discussion is normally Debian vs. Yocto based Linux.
This white paper have been made primarily for managers, sales and purchasers regarding the overall (and not to technical deep) differences between Debian and Yocto based Linux usage in industrial applications.
The content of the white paper is build on the my and my colleagues own experiences, based on development of more than 100 Industrial Linux solutions and probably discussion of more than 250 Linux solutions with customers over a period of 10 years at Prevas A/S.
Digital Fabrication Studio.02 _Information @ Aalto Media FactoryMassimo Menichinelli
DIGITAL FABRICATION STUDIO (25438)
The course provides a general understanding on how to design and manufacture products and prototypes in a Fab Lab, using digital fabrication technologies and understanding their features and limits.
Students will learn how information shapes design, manufacturing and collaboration processes and artifacts in a Fab Lab. They will learn how to digitally fabricate a project or how to digitally modify an existing project; students will also learn how to manage, embed and retrieve information about a project. Projects and prototypes developed and manufactured in this course will not be interactive.
The course consists of lectures and a group project to be digitally fabricated, be it a project already designed but not yet realized or be it the modification of an existing project. Every lecture (3 hours) includes time for testing the technologies covered (1 hour) and for developing part of the group project and for receiving feedback about it (1 hour).
http://mlab.taik.fi/studies/courses/course?id=1963
Makefile actually is an old concept from UNIX development. Makefile is based upon compiling rules for a project and improve the project development efficiency. In a big project, there are many files in different folders. Of course you can write a DOS batch file to build whole project. But makefile can judge which steps should be done first, which steps can be ignored, and even more complicated goals. All of these are decided by the rules in makefile, instead of manually specified.
Mining Component Repositories for Installability IssuesRoberto Di Cosmo
Slides of the MSR 2015 presentation on the debcheck tool, that has been used to track installability issues in Debian for almost 10 years, and can be extended to many other repositories, like the Opam and Drupal ones.
"How to Use Bazel to Manage Monorepos: The Grammarly Front-End Team’s Experie...Fwdays
At some point, we reached the limit of the existing build process in the Grammarly Editor monorepo. Build tools required too much time to support, and each new package increased build time and made dependency management harder. To move further, we had to rethink the architecture of the build process. Our solution: We switched to Bazel. In this talk, I will share our findings and how we made the architecture of the build process scalable and predictable.
If you are a performance engineer/network engineer or even security engineer, the chance of you encountering eBPF technology in the future is very high.
After a brief recap of what p2 is and depicting the overall vision, the presenter will show how this vision is realized and how the improvements made to both the runtime (core and UI) and the tooling in Galileo pave the way for a better provisioning solution at Eclipse.
Composer has triggered a renaissance in the PHP community, it has changed the way we deal with other people’s code and it has changed the way we share our code. We are all slowly moving to using Composer, from Wordpress to Joomla and Drupal and frameworks in between. But many of us mistreat composer, follow outdated practices or simply lack a few tricks. In this session i’ll get you the low down on how to use composer the right way.
Composer has triggered a renaissance in the PHP community, it has changed the way we deal with other people’s code and it has changed the way we share our code. We are all slowly moving to using Composer, from Wordpress to Joomla and Drupal and frameworks in between. But many of us mistreat composer, follow outdated practices or simply lack a few tricks. In this session i’ll get you the low down on how to use composer the right way.
Similar to p2, your savior or your achilles heel? Everything an Eclipse team needs to know about p2 (20)
p2, your savior or your achilles heel? Everything an Eclipse team needs to know about p2
1. p2, your savior
or your Achilles
heel?
Everything an
Eclipse team
needs to know
about p2!
R. Ian Bull
Pascal Rapicault
2. 2 3/21/2011
Alternate Titles
10 reasons we closed your p2 bugs as INVALID?
10 ways to get booted from the p2 mailing list!
10 excuses why we didn’t buy you a beer
p2, 10 common pitfalls and how to avoid them.
3. 3 3/21/2011
#1
Move / remove files on disk
Leading cause of p2 failures:
developers tampering with plugins/ folder
If
you no longer need a plugin DO NOT
REMOVE IT BY HAND
Do not move, unzip or change a plug-in in
your plugins/ directory
4. 4 3/21/2011
Instead:
Let p2 manage your install
Other plug-ins may depend on it
If a plug-in is no longer needed, p2 will
remove it
Run the Garbage Collector manually if you
want
# ./eclipse –application
org.eclipse.equinox.p2.garbagecollector.application
5. 5 3/21/2011
#2
Unzip your plug-ins over Eclipse
Do you provide a zip file for your plugins?
Do you instruct your users to unzip over
eclipse
We don’t like you! (And we will sabotage
your wiki page )
6. 6 3/21/2011
Instead:
Provide a repository
Repositories can be zipped and
downloaded!
Users can simply point to the compressed
repository to properly install your plug-in
Avoid the use of drop-ins too
7. 7 3/21/2011
#3
Replace published content
Neverpublish different content with the
same version number!
Do not make a change and use the same
version number
Do not build plug-ins as Foo v1.0.0.HEAD
You’ll never know what your user runs.
8. 8 3/21/2011
Remember:
Version / ID pairs are immutable
If
the Version / ID has not changed, the
content hasn’t changed!
Always publish new metadata and
artifacts for each code change
Use .qualifiers for all bundles / plug-ins and
features
If
you can’t rebuild everything, provide
patches to deliver surgical updates
9. 9 3/21/2011
Reuse:
Tips and Tricks
Context repositories
build.properties:
repoBaseLocation=${buildDirectory}/inputRepositories
transformedRepoLocation=${buildDirectory}/transformedRepo
Qualifier replacement / bundle reuse
forceContextQualifier: Replaces the qualifier of all
your bundles (use build timestamp)
Feature patches:
http://help.eclipse.org/helios/index.jsp?topic=/org.eclips
e.pde.doc.user/guide/tools/project_wizards/new_featur
e_patch.htm
(or google: eclipse p2 feature patch)
10. 10 3/21/2011
#4
Alter a released repository
“Release” repositories are serious stuffs!
People will refer to them from their repo to
avoid duplicating your content
People will refer to them from their build
Removing content from a “release” repo
is a felony!
11. 11 3/21/2011
Instead:
Be mindful of your users / repos
Preserve content at the same URL
If you put out bad bytes, publish a new version.
Don’t remove the old one !
Append new version to existing repo.
Disk is cheap, users not patient (and they’ll blame p2).
For this, use p2 composite repositories.
Define clear retention policies
For example, the policies for the SDK
http://wiki.eclipse.org/Eclipse_Project_Update_Sites
12. 12 3/21/2011
#5
Don’t categorize things
p2 only shows what’s been categorized
Repository designers are responsible for
designing their categories
Classic consumer / producer problem
13. 13 3/21/2011
Remember:
Category tricks
Use categories !
The category publisher is here to help
Use composite repositories where one of
the repo carry the categories
Usemeaningful name, and use the
description. The feature name is shorter
than a tweet.
14. 14 3/21/2011
#6
Ignore your version ranges
Specify
a strict dependency on 3.6.1 and
wonder why your users can’t install on
3.6.2?
Most illegible p2 error messages are a result
of poorly set version ranges
15. 15 3/21/2011
Instead:
Consider your version ranges
Version your packages, bundles and
features
Use version ranges for dependencies:
Up-to by not including [3.6.0, 3.7.0)
Unbounded lower [0.0.0, 3.7.0)
Unbounded higher 2.0
Strict Versions [3.6.1, 3.6.1]
You need to know what the producer does.
16. 16 3/21/2011
#7
Don’t USE API
If you find yourself reaching into internals,
ask yourself why?
If you manually write to the bundles.info
file, ask yourself why?
If you edit content.xml / artifacts.xml by
hand, ask yourself why?
Two problems when you don’t use API:
We could break you
You could break you
17. 17 3/21/2011
Instead:
Be mindful of what you use
Look for provisional API (if real API doesn’t
exist)
Ask on the p2-mailing list
18. 18 3/21/2011
#8
Use the Metadata generator
If
you are using the Metadata
generator… sorry
(org.eclipse.equinox.p2.metadata.generator)
Deprecated two years ago
Removed for Indigo
19. 19 3/21/2011
Instead:
Use the Publisher
Publisher Applications & Ant Tasks
Publish from an Update Site
Publish from Features / Bundles
Publish from a Product
Publish categories
# ./eclipse -application
org.eclipse.equinox.p2.publisher.UpdateSitePublisher
-metadataRepository file:///repo
-artifactRepository file:///repo
-source http://foo/site.xml
-compress
-publishArtifacts
20. 20 3/21/2011
#9
Use legacy update sites
Legacyupdate sites don’t include
complete metadata
Features are downloaded before any
dependency resolution can occur
Biglag at install time.
We will blame you for all p2’s
performance problems
21. 21 3/21/2011
Instead:
Use a real build tool
PDE Build, Tycho and derivatives (Athena,
Buckminster, etc.) all provide facilities to
build p2 repositories.
If you can’t change your build
technology, at lease use the Update Site
Publisher.
22. 22 3/21/2011
#10
Spell it P2
I don’t call your project Mylin, έMF, or BERT