Ankur Sharmaankur.sharma2@emc.com@ankur_sharmablog.ankursharma.org

WHO AM I?

Ex-committer and co-lead to Eclipse PDE project

Currently employed with EMC2

Dealing with Eclipse for last 8 years now

BUILDS ARE NOT EASY

Challenges

• Dependencies

• Versions

• Streams/Branches – I,N,M

• CI

PDE BUILDS

• Eclipse plug-ins (and OSGi bundles) treated as first rate citizens

• Eclipse style Versioning

• Understands PDE artifacts

• build.properties

• Ant based

TANTRUMS

• Dependency hell

• Third party dependencies

• Multiple Target platforms

• Insufficient active development

• Bloated builds

• 32 bit and 64 bit builds?

• Didn’t work too well with Git

NOT ALL IS LOST

• Use build.properties preferences

• Api Baseline

• Make use of API Use scans

MAVEN

• Language independent

• Dependency management is the core

• Modular artifacts instead of interpreted scripts

• Extensible architecture

HIGH MAINTENANCE?

• Cumbersome pom.xml

• Doesn’t understands Eclipse artifacts – plug-ins, bundles,

features, site

• Eclipse builds depends on Tycho and m2e

• Ignores PDE artifacts like build,properties

• Eclipse integration is not fully baked yet

• Tycho does its own packaging

• .m2 cache

THEN WHY?

• Dependence management

• Ability to easily churn out Snapshot and Release builds

• Works well with Git, Perforce and other SCMs

• Can hide Target Platform menace using custom repositories like

Jfrog Artifactory

BEST CHOICE?

• There is no silver bullet

• PDE Builds for simpler and small applications

• Maven for complex and heavy applications.

• Use Maven for CI

• Keep light weight PDE infrastructure at hand for running local

tests and builds