Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "EclipseLink/Build/Tycho"

(Using Tycho with EclipseLink (2.4.0))
(When is cut-over?)
Line 12: Line 12:
  
 
=== When is cut-over? ===
 
=== When is cut-over? ===
* after an initial review, and question and answer period the changes will be made in phases
+
* After an initial review and Question & Answer period, the changes will be made in several transactions on Oct 7.
** current cut-over planned to begin: 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+) ==
 
== Possible EclipseLink Build Changes (2.4.0+) ==

Revision as of 13:15, 29 September 2011

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 was made primarily to move to a "manifest-first" build approach (the 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 predifined dependencies and classpaths, then generating an OSGi manifest and bundle post-compile. This paradym change will have profound impact upon development, as package development will no longer be divorced from Manifest maintenance. Also manifest issues will be more visible as they are used to build the product and any problems will be visible much sooner.

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 as a component of the build system. 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 the the default build process. While much of the default assumptions could be overridden, doing so to conform to our existing processes would be counter-productive.
  • Only OSGi plugin builds have changed tooling - much of our build involves processes that do not currently conform to Maven standards (Testing, EclipseLink jar from bundle generation, Eclipse feature generation, P2 generation, publishing, etc). 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. However, doing so forces us to bypass much of the capabilities of Tycho (dynamic hierarchical generation of bundles into features published into a p2 and/or Maven repository). For this reason, among others, we are continuing to evaluate moving towards Maven as the primary build tool with subsections of the build calling out to Ant (testing).
  • 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+)

These 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 full 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.

Back to the top