Skip to content

Common Build Issues

Hannes Wellmann edited this page Sep 21, 2024 · 4 revisions

Common build failures

Error message:

 [ERROR] Cannot resolve project dependencies:
 [ERROR]   Software being installed: org.eclipse.equinox.sdk.product 4.9.0.qualifier
 [ERROR]   Missing requirement: org.eclipse.equinox.serverside.sdk.feature.group 3.15.0.v20180803-1236 requires 'org.eclipse.equinox.p2.iu; org.eclipse.equinox.server.p2.feature.group
 [1.5.0.v20180710-1609,1.5.0.v20180710-1609]' but it could not be found`
 [ERROR]   Cannot satisfy dependency: org.eclipse.equinox.sdk.feature.group 3.15.0.v20180803-1236 depends on: org.eclipse.equinox.p2.iu; org.eclipse.equinox.serverside.sdk.feature.group
 [3.15.0.v20180803-1236,3.15.0.v20180803-1236]
 [ERROR]   Cannot satisfy dependency: org.eclipse.equinox.sdk.product 4.9.0.qualifier depends on: org.eclipse.equinox.p2.iu; org.eclipse.equinox.sdk.feature.group 0.0.0
 [ERROR]

Problem Analysis and solution

This happens when we have nested features, in this case we have the following features nested. org.eclipse.equinox.server.p2 org.eclipse.equinox.serverside.sdk org.eclipse.equinox.server.p2 org.eclipse.equinox.sdk In the above case org.eclipse.equinox.server.p2 got modified and other feature did not recognize that. This causes comparator to replace other three features with baseline and causing above problem. Can be rectified by updating forceQualifierUpdate.txt file present alongside those features. Also raised Bug 537718 against Tycho to address this


Error message:

 Installing org.eclipse.pde.api.tools 1.1.400.v20180727-1338.
 Installing org.eclipse.releng.build.tools.feature.feature.group 1.0.101.v20170602-0639.
 Installing org.eclipse.wtp.releng.tools.feature.feature.group 1.2.0.v201405010053.
 Installing org.apache.derby.core.feature.feature.group 10.11.1.1-v201411092200.
 Cannot complete the install because of a conflicting dependency.
  Software being installed: API Tools 1.1.400.v20180727-1338 (org.eclipse.pde.api.tools 1.1.400.v20180727-1338)
  Software currently installed: Eclipse Platform 4.8.0.I20180611-0500 (org.eclipse.platform.ide 4.8.0.I20180611-0500)
  Only one of the following can be installed at once:
   Debug Core 3.12.0.v20180509-0959 (org.eclipse.debug.core 3.12.0.v20180509-0959)
   Debug Core 3.13.0.v20180728-0102 (org.eclipse.debug.core 3.13.0.v20180728-0102)
  Cannot satisfy dependency:
   From: Java Development Tools Launching Support 3.11.0.v20180728-0103 (org.eclipse.jdt.launching 3.11.0.v20180728-0103)
   To: osgi.bundle; org.eclipse.debug.core [3.13.0,4.0.0)
  Cannot satisfy dependency:
   From: Java Development Tools Launching Support 3.11.0.v20180728-2102 (org.eclipse.jdt.launching 3.11.0.v20180728-2102)
   To: osgi.bundle; org.eclipse.debug.core [3.13.0,4.0.0)
  Cannot satisfy dependency:
   From: API Tools 1.1.400.v20180727-1338 (org.eclipse.pde.api.tools 1.1.400.v20180727-1338)
   To: osgi.bundle; org.eclipse.jdt.launching [3.6.100,4.0.0)
  Cannot satisfy dependency:
   From: Eclipse Platform 4.8.0.v20180611-0656 (org.eclipse.platform.feature.group 4.8.0.v20180611-0656)
   To: org.eclipse.equinox.p2.iu; org.eclipse.debug.core [3.12.0.v20180509-0959,3.12.0.v20180509-0959]
  Cannot satisfy dependency:
   From: Eclipse Platform 4.8.0.I20180611-0500 (org.eclipse.platform.ide 4.8.0.I20180611-0500)
   To: org.eclipse.equinox.p2.iu; org.eclipse.platform.feature.group [4.8.0.v20180611-0656,4.8.0.v20180611-0656]

Problem Analysis and solution

We use an eclipse instance for generating different build reports. This instance is created by adding org.eclipse.pde.api.tools, org.eclipse.releng.build.tools.feature.feature.group, org.apache.derby.core.feature.feature.group and org.eclipse.wtp.releng.tools.feature.feature.group to eclipse platform product. If you see the above error message it implies that one of the above feature requires higher version of eclipse platform product. This errors happens because the p2director cannot upgrade through commandline. This can be fixed by changing the base dir and base label here


Missing version increments

Error message:

Error:  Failed to execute goal tycho-p2-extras:compare-version-with-baselines (compare-artifact-version-with-release)
on project org.eclipse.e4.core.tools.feature:
Only qualifier changed for (org.eclipse.e4.core.tools.feature.feature.jar/4.30.300.v20240921-0828).
Expected to have bigger x.y.z than what is available in baseline (4.30.300.v20240806-1811) -> [Help 1]

Problem Analysis and solution

This error indicates that a change was detected in the affected project compared to the last release (in this case in org.eclipse.e4.core.tools.feature), but the project's version didn't change. According to the rules of semantic versioning at least the service segment of an artifact's version should be increased if an artifact is changed between releases.

The solution to this problem is to increment the service/micro segment of the version by +100 in the project's META-INF/MANFIEST.MF or feature.xml, depending on if it is a Plug-in or Feature project. The change is ideally applied in a separate commit with the standard message: Version bump(s) for <sdk-version> stream.

In general it can also be necessary to increment the minor or major version segment if a project's API is changed, but this is indicated by different errors.

Frequently asked question

  • Why is the service version segment bumped by +100?

    This rule allows orderly versioning in potential maintenance releases. By incrementing the service segment by +100, e.g. from 4.30.300 to 4.30.400, it remains possible to have a service version increments on maintenance branches that are semantically smaller than the version of the following release, even if they are done at a later point in time.

  • What is the benefit of applying the version bump in a separate commit?

    Applying version increments in a separate commit makes it easier to identify a version increment in the Git history. It also eases reverting code changes. If a revert is necessary one can then simply revert a problematic commit without the need to remove version decrements from the reverting commit. This is important because versions must not go backwards, otherwise updates will not work.