Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
This page contains information and documents produced during the "What is In a Build" Symposium at Eclipse Summit Europe 2010. Many thanks to John Gunnarsson, Purple Scout AB, for producing diagrams, and to everyone that helped make this a great event.
During the last year there has been many questions about how projects perform their builds, and how they manage the process from developer builds, nightly, milestone and release, and what the best practices are. Several projects have documented their set up which has served as valuable information to other projects. There is lots of opportunity to collaborate to provide good and shared documentation. In this seminar we will be working on gathering and documenting best practises and requirements for Eclipse centric build and release tools and processes. If you have experiences to share, or feel strongly about an under developed area - please join in. The format of this session will be similar to this agenda:
Organize topics for breakout sessions - brainstorm Work in groups - produce content Each group presents result Discussion Next steps The idea is that the groups work on a particular area, brainstorming and gathering best practices and requirements. Participants will get an opportunity to prepare material in advance (but this is not a requirement for participation).
The source of the diagrams is found here: Media:Process.EAP.zip
Target Platform Breakout Session
- assumption: target platform is used to define the universe for my project
- especially the .target file
- .target file format is internal, there is no API and no clear definition about functionality -> makes it difficult for build systems to interpret .target files correctly
- used for compilation, for running and for testing - but often different target platforms are needed
- Du we need scoping for dependencies (similar to dependency scopes in maven)?
- workaround: define multiple target platforms for your project
- reuse target definitions
- reference another target definition in my target definition file
- sort of target fragments (e.g. define target fragment with EMF bundles but without Eclipse platform)
- Target platform editor insufficient
- support for slicer mode and multiple platforms
- adding bundles (today, you can only add features)
- support multiple P2 repos per location (is supported in .target file but not by editor)
- -> PDE contributions needed
- multiple target definitions per workspace
- e.g. per project, per group of projects
Tycho Breakout Session
Some Tycho pain points, in no particular order:
- How to Release - use tycho versions plugin (with care) ?
- Product / Application Builds - Pascal says YES (from .product file using eclipse-application mojo) eclipse-application-new-something (still in progress; may be released as new mojo or replace eclipse-application)
- Source feature/bundles - Pascal says NO, not working. Rumours abound - supposed working for egit source plugins (but can't yet generate source features)
- pom to manifest synchronization - use tycho versions plugin? Will this need to synch ever go away (that is, pom.xml need not include a <version>
- documentation is lacking or out of date
- p2 artifacts in a m2 repo -- not yet doable [b3 aggregator can do a hybrid p2-m2 repo], though SAP has a hackaround to allow this in Nexus
- no support for remote zipped repos (p2 problem) - again, SAP/Nexus hackaround
- p2 sucks for network support / proxies / mirrors, so Tycho builds can fail w/o ability to be restarted (like Maven), and sometimes require ~/.m2 cache to be purged to clean out zero-length files pulled from bad mirrors