Jump to: navigation, search

Difference between revisions of "WhatIsInABuildESE2010"

Line 1: Line 1:
 
This page contains information and documents produced during the "What is In a Build" Symposium at Eclipse Summit Europe 2010.
 
This page contains information and documents produced during the "What is In a Build" Symposium at Eclipse Summit Europe 2010.
  
 +
===Use Cases===
 
[[Image:Primary_Use_Cases.jpg]]
 
[[Image:Primary_Use_Cases.jpg]]
 +
 +
===Process===
 +
[[Image:Process.jpg]]
 +
 +
===Source File===
 +
The source of the diagrams is found here:
  
 
===Target Platform Breakout Session===  
 
===Target Platform Breakout Session===  

Revision as of 08:17, 4 March 2011

This page contains information and documents produced during the "What is In a Build" Symposium at Eclipse Summit Europe 2010.

Use Cases

Primary Use Cases.jpg

Process

Process.jpg

Source File

The source of the diagrams is found here:

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
    • stability
    • 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