Jump to: navigation, search


< EclipseLink‎ | Build
Revision as of 08:15, 6 October 2011 by Eric.gwin.oracle.com (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Using Tycho with EclipseLink (2.4.0)

Tycho is a Maven plugin designed to generate OSGi bundles and Eclipse plugins. It's use is fairly transparent both in the automated system, and with the Eclipse IDE. However, this change is focused on the automated system, and was made primarily to move to a "manifest-first" build approach (the checked-in OSGi manifest files are parsed to determine dependencies and to build the software). This is a fundimental change from the previous methodology of building the software using predefined dependencies and classpaths, then generating an OSGi manifest and bundle post-compile. This paradym change will have profound impact upon development, but also on the quality and compatibility of our OSGi offering.


  • Package development will no longer be divorced from manifest maintenance, thereby allowing:
    • in-IDE debugging of general OSGi issues.
    • Compile-time verification of packaging access.
    • Tighter coupling and better control of dependencies.
  • Better control over OSGi platform compatibility issues.
  • Dependency issues will be more visible. Because they will be used to build the product, any dependency issues will be found sooner.


In general Maven approaches building quite differently from Ant. Rather than being a general "toolbox" like Ant, Maven is a "build framework" where one defines specifics of the project, while the project type determines the default build process. Much of the default assumptions could be overridden, but doing so to conform to our existing processes would be counter-productive. However, with those assumptions in place, utilizing Maven fully would impact many aspects of our project (Directory hierarchy, naming and versioning conventions, build cronology).

  • This effects many aspects of the build namely: Testing, EclipseLink jar from bundle generation, Eclipse feature generation, Zip and P2 generation and publishing, and more.
  • As a result, this solution is a compromise. Allowing the primary goal of manifest-first development, but sacrificing many advantages Maven/Tycho would provide; such as in-IDE bundle generation, dynamic hierarchical generation of bundles into features, dynamic publishing into a p2 and/or Maven repository.

For these reasons, among others, we are continuing to evaluate moving towards Maven as the primary build tool with subsections of the build calling out to Ant (EclipseLink jar creation, and testing).

What changes?

  • OSGi manifests are no longer generated - This is the single biggest change to the process, and the one that will effect development the most. OSGi manifests will now be maintained by developers (imports, exports, version ranges, etc).
    • Manifest version ranges need to change - Because Tycho will only modify the "Bundle-Version" with current build data, the exported versions, required bundles, and even import ranges will need to move to static values (no qualifier specified).
  • A new build tool is needed - Since Tycho is a Maven plugin, this change means adding Maven 3.x as a component of the build system. For local builds Maven will need to be available in your path. It can be downloaded from http://maven.apache.org/download.html.
  • Only OSGi plugin builds have changed tooling - much of our build involves processes that do not currently conform to Maven standards. Therefore, we currently are only adopting Maven/Tycho for the bundle generation portion of the build. The Maven build is called by Ant, which continues to provide the majority of the build infrastructure.
  • Tycho POMs hard-coded to use outside IDE - it may be possible to define different configurations, but this is not planned for the initial iteration.
  • Tycho needs Maven/P2 access to compile dependencies - A p2 repository has been setup to hold our non-Orbit (and non-proprietary) dependencies. This means also that some plugins (ASM/ANTLR specifically) that are currently build during every build are now going to be built outside the nightly process similar to javax.persistence.
    • ASM/ANTLR version changes - since they will be built on demand. ASM and ANTLR move to different versioning schemes based upon the version of the codebase used to repackage the libraries plus the build qualifier.

When is cut-over?

  • After an initial review and Question & Answer period, the changes will be made in several transactions on Oct 7.
    • This will allow several days to clean-up any issues, before the branch is used again in earnest.

Possible EclipseLink Build Changes (2.4.0+)

The following changes are not currently planned for 2.4.0:

  • Remove checked in plugins - Since dependant jars would come from Orbit or other P2 repos, all plugin dirs could be removed.
    • This assumes either an ant based system to locate dependencies for testing and utils targets, or a complete shift to Maven.
  • Move other sections of the build to Maven
    • Utils is an easy target. It is distinct from the runtime, changes effect a subset of committers, and since testing appears to be fairly standard. Migration here would be a good warm-up exersize, and could probably be done with minimal restructuring.
  • Repo restructuring
    • Project level organization - Maven (like Eclipse, Git and others) expects a flatter tree than we currently utilize. Organized on a project (component object) level. To fully utilize Maven's capabilities, we'd need to reorganize our tree. Project dirs under trunk would move from ~12 to ~39 directories initially. As testing project migrated and other 'project data' was reorganized this number could be reduced.