From Fedora Project Wiki

m (Important Notes)
m (Information)
 
(92 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Tycho Integration Into Fedora =
+
= Purpose =
 
 
== Purpose ==
 
  
 
To document and comment upon the integration of Tycho into Fedora.
 
To document and comment upon the integration of Tycho into Fedora.
  
== Information ==
+
= Information =
  
 
Upstream : http://www.eclipse.org/tycho/ <br/>
 
Upstream : http://www.eclipse.org/tycho/ <br/>
Fedora Tycho Repository : http://pkgs.fedoraproject.org/gitweb/?p=tycho.git <br/>
+
Fedora Tycho Repository : http://pkgs.fedoraproject.org/cgit/tycho.git/ <br/>
 
Koji Builds : http://koji.fedoraproject.org/koji/packageinfo?packageID=11939 <br/>
 
Koji Builds : http://koji.fedoraproject.org/koji/packageinfo?packageID=11939 <br/>
Package ACLs : https://admin.fedoraproject.org/pkgdb/acls/name/tycho <br/>
+
Package ACLs : https://admin.fedoraproject.org/pkgdb/package/tycho/ <br/>
Bugs : https://admin.fedoraproject.org/pkgdb/acls/bugs/tycho  
+
Bugs : https://apps.fedoraproject.org/packages/tycho/bugs/  
 +
 
 +
Fedora Tycho versions :
 +
 
 +
* rawhide : 0.23.0
 +
* f22 : 0.23.0
 +
* f21 : 0.21.0
 +
 
 +
Packages currently having a BuildRequire on Tycho :
 +
 
 +
cbi-plugins, cxf, docker-client, eclipse, eclipse-cdt, eclipse-checkstyle, eclipse-color-theme, eclipse-dltk, eclipse-e4-importer, eclipse-eclemma, eclipse-egit, eclipse-egit-github, eclipse-emf-query, eclipse-emf-transaction, eclipse-emf-validation, eclipse-fedorapackager, eclipse-gef, eclipse-jbosstools, eclipse-jgit, eclipse-launchbar, eclipse-license, eclipse-linuxtools, eclipse-moreunit, eclipse-mpc, eclipse-mylyn, eclipse-mylyn-fedora-integration, eclipse-packagekit, eclipse-pdt, eclipse-photran, eclipse-ptp, eclipse-pydev, eclipse-remote, eclipse-rse, eclipse-shelled, eclipse-swtbot, eclipse-tm-terminal, eclipse-xsd, swt-chart, tycho, tycho-extras
 +
 
 +
= Differences from Upstream =
 +
 
 +
== Local vs. Remote Repositories ==
 +
 
 +
Tycho should respect the state from which the maven build was initiated. Launching a maven build through XMvn (xmvn/mvn-build/%mvn_build) should cause the resolution of Fedora Tycho, and depending on whether an online/offline functionality is set, Tycho will resolve its artifacts accordingly. That is :
 +
 
 +
When maven is running through XMvn, and offline mode is set, Tycho will resolve its dependencies using only local resources. (eg. reactor cache, system local p2 repository). When maven is running through XMvn, and offline mode is not set, Tycho will first attempt to resolve its dependencies using local resources. If a resource cannot be found locally, Tycho will check remote repositories and place resources into the reactor cache as needed. In this case, a look through the logs can determine what packages were downloaded remotely.
  
Fedora's Tycho is currently updating and tracking upstream's releases for the following branches :
+
== Local OSGi bundle resolution ==
  
* rawhide
+
Tycho is generally expected to find all OSGi bundles installed on the system in accordance with the Fedora Package Guidelines. These locations will often include : 'usr/share/java', 'usr/lib*/eclipse', 'usr/share/eclipse/dropins' relative to some specified root (eg. '/', or '/opt/my/scl/' )
* f17
 
* f16 (0.10.0)
 
  
 +
You may notice that Tycho newer versions of Fedora Tycho no longer generate a p2 repository of the entire system ( http://pkgs.fedoraproject.org/cgit/tycho.git/commit/?id=3d584e80a15aad3cbcc792d895f76d4e6f90b3dd ) . This is because Fedora Tycho now takes advantage of a plugin called [https://github.com/rgrunber/fedoraproject-p2/ fedoraproject-p2] that allows p2-capable applications to see regular filesystem folders as p2 repositories.
  
Packages currently having a BuildRequire on Tycho :
+
Instead of :
 +
 
 +
[INFO] Scanning for projects...
 +
Building system local p2 repository...
 +
+ java -jar /usr/lib/eclipse/plugins/org.eclipse.equinox.launcher_1.3.0.v20140731-1900.jar -nosplash -application org.eclipse.equinox.p2.publisher.FeaturesAndBundlesPublisher -metadataRepository file:/builddir/build/BUILD/tycho-0.21.0/.m2/p2/repo -artifactRepository file:/builddir/build/BUILD/tycho-0.21.0/.m2/p2/repo -source /builddir/build/BUILD/tycho-0.21.0/.m2/p2/repo-sdk -compress -append -publishArtifacts
 +
Generating metadata for ..
 +
Generation completed with success [226 seconds].
 +
 
 +
You will end up seeing something like :
  
* eclipse-cdt
+
[INFO] Adding repository fedora:/usr/lib64/eclipse/plugins
* eclipse-dltk
+
[INFO] Adding repository fedora:/usr/share/eclipse/dropins
* eclipse-mylyn
+
[INFO] Adding repository fedora:/usr/share/java
* jacoco
+
[INFO] Adding repository fedora:/usr/lib64/eclipse/dropins
* swt-chart
+
[INFO] Adding repository fedora:/usr/lib64/eclipse/features
* tycho
+
[INFO] Adding repository fedora:/usr/lib/java
* tycho-extras
 
  
== Important Notes ==
+
In the event that Tycho is not using a particular filesystem location, or if a user wishes to have other locations added to the build's target platform, there are ways of accomplishing this.
  
'''maven.local.mode and offline'''
+
=== Method 1 (Recommended) ===
  
Tycho should respect maven.local.mode as well as offline mode when doing builds. That is :
+
Fedora Tycho supports the property '''fedora.p2.repos''' , which takes a comma-separated list of additional paths one wishes to have added to the target platform.
  
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.
+
For example :
  
'''Tycho Local OSGi bundle resolution'''
+
xmvn -o -Dfedora.p2.repos=$(pwd)/bootstrap,/opt/some/path \
 +
clean install org.apache.maven.plugins:maven-javadoc-plugin:aggregate
  
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 2 ===
  
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 :
+
An OSGi project wishing to build with Tycho that has OSGi dependencies may provide a local p2 repository on the system holding all of those dependencies. This is accomplished in 3 steps :
# Eclipse's copy-platform script is used to gather the various dependencies needed for the build and place them in a single folder.
+
# The user must gather a the OSGi bundles they wish to use as part of the p2 repository
 
# The [http://help.eclipse.org/indigo/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/p2_publisher.html FeaturesAndBundlesPublisher] application is used to create a p2 repository on the local system.
 
# The [http://help.eclipse.org/indigo/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/p2_publisher.html FeaturesAndBundlesPublisher] application is used to create a p2 repository on the local system.
 
# Tycho is made aware of this repository by specifying it under the list of repositories.
 
# Tycho is made aware of this repository by specifying it under the list of repositories.
Line 51: Line 74:
 
(At the end of the %prep section of the specfile)
 
(At the end of the %prep section of the specfile)
  
  /usr/lib/eclipse/buildscripts/copy-platform SDK \
+
  # Gather the set of OSGi bundles we care about
/usr/lib/eclipse cdt
+
cp /path/to/bundles $PWD/SDK
 
   
 
   
 
  eclipse -debug -consolelog -nosplash -verbose \
 
  eclipse -debug -consolelog -nosplash -verbose \
Line 69: Line 92:
 
  </repository>
 
  </repository>
  
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 [https://bugzilla.redhat.com/show_bug.cgi?id=809575 Bug 809575]
+
== 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.
 +
 
 +
If you are using '''tycho.local.keepTarget''' then you may find that your build is unnecessarily assembling products for platforms that you don't care about. In this case you can use the '''director.running.env.only''' flag to make tycho's p2-director plug-in only assemble products for the running target environment -- all other configured environments are omitted. This saves a lot of build time for large products on slow build environments such as 32bit ARM.
 +
 
 +
== 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 0.16.0 has added the property '''skipTychoVersionCheck''' to disable this check. As of Tycho 0.18.1, Tycho version checking is ignored by default, so no action needs to be taken. In the event that version checking is desired, the '''tycho.enableVersionCheck''' property may be set. (See http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=305eb576d58f1adf8c8f80fee8bdca49da196816 for more details)
 +
 
 +
== Bootstrap Building ==
 +
 
 +
The building of Tycho in Fedora is different from most builds. You may have noticed that upstream Tycho actually uses an pre-existing Tycho instance to build itself. This is because Tycho contains OSGi bundles as reactor projects. As a result Tycho has a dependency on itself. In Fedora we're able to break this chain if necessary to build Tycho cleanly when a build does not already exist (none in the buildroot).
 +
 
 +
To find all Tycho components needed for the build, we look for any components that use ${tychoBootstrapVersion} as their version and add them as well as any dependencies they have on other Tycho components. These are all clearly defined in the pom.xml files and we can then picture a [https://rgrunber.fedorapeople.org/tycho-bootstrap-0.21.0.png dependency graph] of these components. The graph can be generated using the [https://github.com/rgrunber/tycho-bootstrap-reader tycho-bootstrap-reader] maven plugin.
 +
 
 +
In addition to this we add any components that Tycho seems to use at runtime. [http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-core/src/main/java/org/eclipse/tycho/osgi/runtime/TychoOsgiRuntimeMainArtifacts.java TychoOsgiRuntimeArtifacts.java] as well as [http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-maven-plugin/src/main/resources/META-INF/plexus/components.xml components.xml (tycho-maven-plugin)] contain such components. Certain Tycho projects are of an 'eclipse-test-plugin' type, but despite the fact that we can skip tests, resolution and compilation phases are still run. To avoid having to build tycho-surefire-plugin and it's various dependencies for runtime availability, we can modify the actual lifecycle mapping for our bootstrapped Tycho to omit running tycho-surefire-plugin at runtime.
 +
 
 +
Once we've discovered and ordered the necessary components we perform the following steps to create a bootstrapped Tycho build :
 +
 
 +
# Build all required OSGi bundles in the tycho-bundles folder using a combination of javac and jar to properly package them. Where certain Tycho OSGi bundles depend on other Tycho OSGi bundles, or external OSGi bundles we set the classpath appropriately.
 +
# Place the built OSGi Tycho bundles into the reactor cache as if we had run mvn org.apache.maven.plugins:maven-install-plugin:${install-plugin.version}:install
 +
# Build all reactor projects on an individual basis as required using xmvn -f ${proj}/pom.xml -Dmaven.test.skip=true -Dmaven.repo.local=$(pwd)/.m2 install
 +
 
 +
Once this is completed, we may perform a real build ensuring that Tycho will resolve itself entirely from the reactor cache we have built up.
 +
 
 +
Previously, when building a newer Tycho with the same version as the previous, we would first build an intermediary version and then the final version to avoid any cyclic dependencies. Tycho checks reactor projects first when resolving dependencies, so attempting to build a particular version while depending on an identically versioned Tycho would cause a cycle ( See http://dev.eclipse.org/mhonarc/lists/tycho-user/msg02599.html ) . Now we simply modify the version metadata of the Tycho we are depending upon to be different than the one we are attempting to build, thus eliminating the need for an intermediary build. See [http://pkgs.fedoraproject.org/cgit/tycho.git/commit/?id=369a33d447e4cac027a80b94b4b2766008c7e144 Fedora Tycho Commit 369a33 ] for more detail on how this occurs.
  
 +
== Missing Eclipse Parent POM ==
  
'''Tycho Bootstrap Building In Fedora'''
+
Many Eclipse projects building at the foundation use an [http://wiki.eclipse.org/Maven/Parent_POM eclipse parent pom] to reference various things that most projects would have in common. While this is encouraged for upstream builds, Eclipse does not currently ship this parent pom in Fedora and references to it should be removed. See http://wiki.eclipse.org/Maven/Parent_POM for more details.
  
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.
+
== Build Qualifiers ==
  
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.
+
By default tycho-packaging-plugin will generate build qualifiers using a timestamp from the time of the build. It is however also possible to configure the packaging plugin to set the build qualifier for artifacts based on a custom provider. One common timestamp provider uses JGit to get the last modification time for a sub-project (in Git version control). This capability requires that a Git repository exist, but most projects ship their sources with the repository metadata removed. The error seen in these cases is often ''''java.lang.IllegalArgumentException: One of setGitDir or setWorkTree must be called.'''' .
  
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 : http://dev.eclipse.org/mhonarc/lists/tycho-user/msg02599.html
+
To avoid this issue, packagers must decide whether they wish to include some git repository metadata in the sources (by creating a shallow clone of a repository) or to fall back to default functionality (often by disabling the customized declaration of tycho-packaging-plugin).

Latest revision as of 15:05, 20 July 2015

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/cgit/tycho.git/
Koji Builds : http://koji.fedoraproject.org/koji/packageinfo?packageID=11939
Package ACLs : https://admin.fedoraproject.org/pkgdb/package/tycho/
Bugs : https://apps.fedoraproject.org/packages/tycho/bugs/

Fedora Tycho versions :

  • rawhide : 0.23.0
  • f22 : 0.23.0
  • f21 : 0.21.0

Packages currently having a BuildRequire on Tycho :

cbi-plugins, cxf, docker-client, eclipse, eclipse-cdt, eclipse-checkstyle, eclipse-color-theme, eclipse-dltk, eclipse-e4-importer, eclipse-eclemma, eclipse-egit, eclipse-egit-github, eclipse-emf-query, eclipse-emf-transaction, eclipse-emf-validation, eclipse-fedorapackager, eclipse-gef, eclipse-jbosstools, eclipse-jgit, eclipse-launchbar, eclipse-license, eclipse-linuxtools, eclipse-moreunit, eclipse-mpc, eclipse-mylyn, eclipse-mylyn-fedora-integration, eclipse-packagekit, eclipse-pdt, eclipse-photran, eclipse-ptp, eclipse-pydev, eclipse-remote, eclipse-rse, eclipse-shelled, eclipse-swtbot, eclipse-tm-terminal, eclipse-xsd, swt-chart, tycho, tycho-extras

Differences from Upstream

Local vs. Remote Repositories

Tycho should respect the state from which the maven build was initiated. Launching a maven build through XMvn (xmvn/mvn-build/%mvn_build) should cause the resolution of Fedora Tycho, and depending on whether an online/offline functionality is set, Tycho will resolve its artifacts accordingly. That is :

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

Local OSGi bundle resolution

Tycho is generally expected to find all OSGi bundles installed on the system in accordance with the Fedora Package Guidelines. These locations will often include : 'usr/share/java', 'usr/lib*/eclipse', 'usr/share/eclipse/dropins' relative to some specified root (eg. '/', or '/opt/my/scl/' )

You may notice that Tycho newer versions of Fedora Tycho no longer generate a p2 repository of the entire system ( http://pkgs.fedoraproject.org/cgit/tycho.git/commit/?id=3d584e80a15aad3cbcc792d895f76d4e6f90b3dd ) . This is because Fedora Tycho now takes advantage of a plugin called fedoraproject-p2 that allows p2-capable applications to see regular filesystem folders as p2 repositories.

Instead of :

[INFO] Scanning for projects...
Building system local p2 repository...
+ java -jar /usr/lib/eclipse/plugins/org.eclipse.equinox.launcher_1.3.0.v20140731-1900.jar -nosplash -application org.eclipse.equinox.p2.publisher.FeaturesAndBundlesPublisher -metadataRepository file:/builddir/build/BUILD/tycho-0.21.0/.m2/p2/repo -artifactRepository file:/builddir/build/BUILD/tycho-0.21.0/.m2/p2/repo -source /builddir/build/BUILD/tycho-0.21.0/.m2/p2/repo-sdk -compress -append -publishArtifacts
Generating metadata for ..
Generation completed with success [226 seconds].

You will end up seeing something like :

[INFO] Adding repository fedora:/usr/lib64/eclipse/plugins
[INFO] Adding repository fedora:/usr/share/eclipse/dropins
[INFO] Adding repository fedora:/usr/share/java
[INFO] Adding repository fedora:/usr/lib64/eclipse/dropins
[INFO] Adding repository fedora:/usr/lib64/eclipse/features
[INFO] Adding repository fedora:/usr/lib/java

In the event that Tycho is not using a particular filesystem location, or if a user wishes to have other locations added to the build's target platform, there are ways of accomplishing this.

Method 1 (Recommended)

Fedora Tycho supports the property fedora.p2.repos , which takes a comma-separated list of additional paths one wishes to have added to the target platform.

For example :

xmvn -o -Dfedora.p2.repos=$(pwd)/bootstrap,/opt/some/path \
clean install org.apache.maven.plugins:maven-javadoc-plugin:aggregate

Method 2

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

  1. The user must gather a the OSGi bundles they wish to use as part of the p2 repository
  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)

# Gather the set of OSGi bundles we care about
cp /path/to/bundles $PWD/SDK

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>

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.

If you are using tycho.local.keepTarget then you may find that your build is unnecessarily assembling products for platforms that you don't care about. In this case you can use the director.running.env.only flag to make tycho's p2-director plug-in only assemble products for the running target environment -- all other configured environments are omitted. This saves a lot of build time for large products on slow build environments such as 32bit ARM.

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 0.16.0 has added the property skipTychoVersionCheck to disable this check. As of Tycho 0.18.1, Tycho version checking is ignored by default, so no action needs to be taken. In the event that version checking is desired, the tycho.enableVersionCheck property may be set. (See http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=305eb576d58f1adf8c8f80fee8bdca49da196816 for more details)

Bootstrap Building

The building of Tycho in Fedora is different from most builds. You may have noticed that upstream Tycho actually uses an pre-existing Tycho instance to build itself. This is because Tycho contains OSGi bundles as reactor projects. As a result Tycho has a dependency on itself. In Fedora we're able to break this chain if necessary to build Tycho cleanly when a build does not already exist (none in the buildroot).

To find all Tycho components needed for the build, we look for any components that use ${tychoBootstrapVersion} as their version and add them as well as any dependencies they have on other Tycho components. These are all clearly defined in the pom.xml files and we can then picture a dependency graph of these components. The graph can be generated using the tycho-bootstrap-reader maven plugin.

In addition to this we add any components that Tycho seems to use at runtime. TychoOsgiRuntimeArtifacts.java as well as components.xml (tycho-maven-plugin) contain such components. Certain Tycho projects are of an 'eclipse-test-plugin' type, but despite the fact that we can skip tests, resolution and compilation phases are still run. To avoid having to build tycho-surefire-plugin and it's various dependencies for runtime availability, we can modify the actual lifecycle mapping for our bootstrapped Tycho to omit running tycho-surefire-plugin at runtime.

Once we've discovered and ordered the necessary components we perform the following steps to create a bootstrapped Tycho build :

  1. Build all required OSGi bundles in the tycho-bundles folder using a combination of javac and jar to properly package them. Where certain Tycho OSGi bundles depend on other Tycho OSGi bundles, or external OSGi bundles we set the classpath appropriately.
  2. Place the built OSGi Tycho bundles into the reactor cache as if we had run mvn org.apache.maven.plugins:maven-install-plugin:${install-plugin.version}:install
  3. Build all reactor projects on an individual basis as required using xmvn -f ${proj}/pom.xml -Dmaven.test.skip=true -Dmaven.repo.local=$(pwd)/.m2 install

Once this is completed, we may perform a real build ensuring that Tycho will resolve itself entirely from the reactor cache we have built up.

Previously, when building a newer Tycho with the same version as the previous, we would first build an intermediary version and then the final version to avoid any cyclic dependencies. Tycho checks reactor projects first when resolving dependencies, so attempting to build a particular version while depending on an identically versioned Tycho would cause a cycle ( See http://dev.eclipse.org/mhonarc/lists/tycho-user/msg02599.html ) . Now we simply modify the version metadata of the Tycho we are depending upon to be different than the one we are attempting to build, thus eliminating the need for an intermediary build. See Fedora Tycho Commit 369a33 for more detail on how this occurs.

Missing Eclipse Parent POM

Many Eclipse projects building at the foundation use an eclipse parent pom to reference various things that most projects would have in common. While this is encouraged for upstream builds, Eclipse does not currently ship this parent pom in Fedora and references to it should be removed. See http://wiki.eclipse.org/Maven/Parent_POM for more details.

Build Qualifiers

By default tycho-packaging-plugin will generate build qualifiers using a timestamp from the time of the build. It is however also possible to configure the packaging plugin to set the build qualifier for artifacts based on a custom provider. One common timestamp provider uses JGit to get the last modification time for a sub-project (in Git version control). This capability requires that a Git repository exist, but most projects ship their sources with the repository metadata removed. The error seen in these cases is often 'java.lang.IllegalArgumentException: One of setGitDir or setWorkTree must be called.' .

To avoid this issue, packagers must decide whether they wish to include some git repository metadata in the sources (by creating a shallow clone of a repository) or to fall back to default functionality (often by disabling the customized declaration of tycho-packaging-plugin).