From Fedora Project Wiki

Purpose

To document and comment upon the integration of Tycho into Fedora.

Information

Upstream : http://www.eclipse.org/tycho/
Fedora Tycho Repository : http://pkgs.fedoraproject.org/gitweb/?p=tycho.git
Koji Builds : http://koji.fedoraproject.org/koji/packageinfo?packageID=11939
Package ACLs : https://admin.fedoraproject.org/pkgdb/acls/name/tycho
Bugs : https://admin.fedoraproject.org/pkgdb/acls/bugs/tycho

Fedora Tycho versions per branch :

  • rawhide : 0.17.0
  • f19 : 0.17.0
  • f18 : 0.16.0
  • f17 : 0.15.0

Packages currently having a BuildRequire on Tycho :

  • cbi-plugins
  • eclipse
  • eclipse-cdt
  • eclipse-dltk
  • eclipse-fedorapackager
  • eclipse-gef
  • eclipse-jbosstools
  • eclipse-linuxtools
  • eclipse-m2e-core
  • eclipse-moreunit
  • eclipse-mylyn
  • eclipse-ptp
  • eclipse-shelled
  • eclipse-swtbot
  • jacoco
  • swt-chart
  • tycho
  • tycho-extras

Differences from Upstream

Criteria For A New Build

As Tycho becomes more common for building Eclipse plugins, a set of standards should be set in place so as to minimize failures resulting from changes in this package (upstream or Fedora specific).

  1. Avoid pushing changes that would break other builds
  2. In the case where (1) cannot be done, provide some way (perhaps a build flag) for consumers to maintain their old functionality
  3. In the case where (2) cannot be done, inform affected Fedora maintainers of the situation so that they may make an informed decision ahead of time

Local vs. Remote Repositories

Tycho should respect maven.local.mode as well as offline mode when doing builds. That is :

When maven.local.mode is set, and offline mode is set (eg. mvn-rpmbuild), Tycho will resolve its dependencies using only local resources. (eg. m2 cache, local p2 repository). When maven.local.mode is set, and offline mode is not set (eg. mvn-local), Tycho will first attempt to resolve its dependencies using local resources. If a resource cannot be found locally, Tycho will check remote repositories and bring it into the m2 cache as needed. In this case, a look through the logs can determine what packages were downloaded remotely.

Important.png
It is not recommended to set or unset maven.local.mode, or any property performing a similar function as it may have some unexpected effects.

Local OSGi bundle resolution

Note.png
Tycho should detect all system osgi bundles
Tycho (in rawhide, f18 and f17) should resolve against most system osgi bundles (eclipse bundles, and anything in /usr/share/java) by default. If Tycho is not resolving certain OSGi bundles, this heading is kept as a potential workaround in the event that a solution is not readily available.

Much like Maven, Tycho must resolve its dependencies from other packages already available in Fedora if it is going to be used to build other OSGi bundles. To do this a local resolution mode has been implement similar to how it is done for Maven. When running mvn-rpmbuild (provided by Maven), Tycho will resolve maven dependencies in the same way as Maven. In the case of remote p2 repositories Tycho will also ignore them when running in local mode (mvn-rpmbuild, mvn-local).

Method 1

An OSGi project wishing to build with Tycho that has OSGi dependencies must provide a local p2 repository on the system holding all of those dependencies. This is accomplished in 3 steps :

  1. Eclipse's copy-platform script is used to gather the various dependencies needed for the build and place them in a single folder.
  2. The FeaturesAndBundlesPublisher application is used to create a p2 repository on the local system.
  3. Tycho is made aware of this repository by specifying it under the list of repositories.

A rough boilerplate for the above steps would be :

(At the end of the %prep section of the specfile)

/usr/lib/eclipse/buildscripts/copy-platform SDK \
/usr/lib/eclipse cdt

eclipse -debug -consolelog -nosplash -verbose \
-application org.eclipse.equinox.p2.publisher.FeaturesAndBundlesPublisher \
-metadataRepository file:/path/to/myrepo \
-artifactRepository file:/path/to/myrepo \
-source $PWD/SDK \
-compress -append -publishArtifacts

(In the project's top-level pom.xml, and within the <repositories> tag)

<repository>
 <id>my_local_rpmbuild_repo</id>
 <layout>p2</layout>
 <url>file:/path/to/myrepo</url>
</repository>

Method 2

A strictly simpler way of accomplishing the above (but maybe not as resilient to implementation-specifc changes) is to place the desired OSGi bundles in .m2/p2/repo-sdk . This folder should be relative to the top level pom.xml from which Maven will be executed.

mkdir -p .m2/p2/repo-sdk
ln -s *.jar .m2/p2/repo-sdk

Target Platform Configuration

By default, upstream's offering of Tycho will attempt to resolve dependencies for every environment defined for the pom's target-platform-configuration. So for example, if your plugin needs Eclipse SWT, then the build will need to have the SWT fragment for every environment defined.

With access to remote p2 repositories, we could build for any environment, but in Fedora we must only use packages already packaged, and for that particular environment. As a result building for multiple environments at once isn't easily achievable, and in some cases the environment isn't supported by Fedora at all. This can cause all sorts of failures when running a build due to environment-specific dependencies not being available.

To get around this, Fedora's Tycho will (by default) set the target platform environment to be the same as the currently running system. In some cases, certain plugins being built are tied to a certain environment, and if this does not match the system's running environment, they will fail to build. Ideally upstream should have build profiles which allow customization of what is being built. As a last resort, Fedora Tycho has the flag tycho.local.keepTarget. With this flag enabled, Fedora Tycho will behave as an upstream Tycho with regard to target platform configuration. That is, Tycho will set the target platform environment as specified in the project poms.


Multiple Tycho Versions Specified

As of Tycho 0.16.0, when a project depends upon a version of Tycho that doesn't match the system's version, it will fail. Upstream has implemented this to avoid scenarios where a project might specify multiple versions and fail at runtime with cryptic error messages. This seems to be triggered even when using a lower version and expecting any higher available version to be resolved. Fedora Tycho has added the flag skipTychoVersionCheck to disable this check. (See http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=305eb576d58f1adf8c8f80fee8bdca49da196816 for more details)


Intermediary Building

The building of Tycho in Fedora is different from most builds. Since Tycho itself has subprojects that are OSGi bundles, it must do a bootstrap build of the modules needed for building OSGi bundles, before it can build everything else. As a result it has a dependency on itself.

In Fedora the first build was accomplished by providing a pre-built (from sources) version of Tycho (0.13.0) in its m2 cache so that it may resolve its dependency on itself. All subsequent builds simply depended on the previously built version (BuildRequires: %{name}). This actually causes a problem because when the previous version is not different from the version about to be built (as is the case during release bumps). In this case the Maven resolver enters a cyclic dependency. It does not resolve the necessary artifact from the system, but rather from the reactor project, and thus fails. To work around this issue we build twice.

(Note that during new version releases, a single build is sufficient)

The first build modifies the version to be different from the previous (often ${version}-SNAPSHOT which is different from ${version}). We can think of this first built version as an "intermediary" build. The second build removes the "SNAPSHOT" so that a proper build may take place. Note that upstream has confirmed this would have to be done : http://dev.eclipse.org/mhonarc/lists/tycho-user/msg02599.html

Initially, it was necessary to issue two Koji builds in order to build a proper version of Tycho. The first version was an intermediary version used to build the second (final version). With a fix to Bug 865599 , Tycho can now build properly in a single Koji build by combining the two builds into one RPM build if necessary.