From Fedora Project Wiki

m (Information)
m (Information)
Line 25: Line 25:
* eclipse-cdt
* eclipse-cdt
* eclipse-dltk
* eclipse-dltk
* eclipse-fedorapackager
* eclipse-jbosstools
* eclipse-linuxtools
* eclipse-mylyn
* eclipse-mylyn
* eclipse-swtbot
* jacoco
* jacoco
* swt-chart
* swt-chart

Revision as of 19:26, 10 August 2012

Tycho Integration Into Fedora


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


Upstream :
Fedora Tycho Repository :
Koji Builds :
Package ACLs :
Bugs :

Fedora's Tycho is currently updating and tracking upstream's releases for the following branches :

  • rawhide : 0.16.0 SNAPSHOT
  • f18 : 0.16.0 SNAPSHOT
  • f17 : 0.14.1, but expect 0.15.0 shortly
  • f16 : 0.10.0

Packages currently having a BuildRequire on Tycho :

  • eclipse-cdt
  • eclipse-dltk
  • eclipse-fedorapackager
  • eclipse-jbosstools
  • eclipse-linuxtools
  • eclipse-mylyn
  • eclipse-swtbot
  • jacoco
  • swt-chart
  • tycho
  • tycho-extras

Important Notes

maven.local.mode and offline

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, the m2 cache will be filled with just those resources that could not be found locally.

Tycho Local OSGi bundle resolution

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).

Currently, 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)


Tycho (in rawhide, and f17 soon) will resolve against most system osgi bundles (eclipse bundles, and anything in /usr/share/java) by default. This functionality is tracked at Bug 809575

Tycho Bootstrap Building In Fedora

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), 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.

The first build modifies the version to be different from the previous (often ${version}-SNAPSHOT which is different from ${version}). 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 :