Source bundles are still provisioned by tycho-surefire but no longer downloaded during resolution

[tivervac]

Since Tycho 5.0.3, tycho-surefire-plugin:test fails in offline builds (mvn -o, or in our case, a CI setup that first builds all code (online) populating a shared local repository and then runs separate offline jobs that run the tests) whenever the target platform contains bundles whose p2 metadata carries the optional requirement on their own source bundle. This approach worked fine in Tycho 5.0.2.

In our case, the problematic bundles are the felix gogo bundles. Those are coming from mirrored Eclipse SimRel/Orbit content.

<required namespace='osgi.bundle' name='org.apache.felix.gogo.command.source' range='[1.1.2,1.1.2]' optional='true' greedy='true'>
  <filter>(org.eclipse.update.install.sources=true)</filter>
</required>

The failure with 5.0.3:

[ERROR] Failed to execute goal org.eclipse.tycho:tycho-surefire-plugin:5.0.3:test (default-test) on project com.sigasi.hdt.docgen.test: ... failed: Could not mirror artifact osgi.bundle,org.apache.felix.gogo.command.source,1.1.2 into the local Maven repository.
See log output for details. maven is currently in offline mode requested URL https://<mirror>/plugins/org.apache.felix.gogo.command.source_1.1.2.jar does not exist locally!

Analysis

Two behaviors collide:

1. AbstractResolutionStrategy.getEffectiveFilterProperties unconditionally sets org.eclipse.update.install.sources=true (and org.eclipse.update.install.features=true) for every dependency resolution. So the optional filtered requirement above is always satisfied, and the .source bundles silently join every project's resolved dependency set. includeSource="false" and targetDefinitionIncludeSource=ignore in the target file don't prevent this.
2. Tycho 5.0.3 deliberately stops downloading source bundles during classpath validation/resolution (which is great).

Until 5.0.2, behavior 2's downloads were what made behavior 1 harmless: the source jars were already in the local cache by the time tycho-surefire ran. With 5.0.3, they are no longer pre-fetched, but tycho-surefire still provisions all resolved dependency artifacts into the test runtime, source bundles included, and tries to mirror them into the local repository at test time. In offline mode, this fails.

Suggested fix

Preferably both:

• Skip source bundles when provisioning the surefire test runtime, unless sources are explicitly requested. This seems to align well with the work done in 5.0.3 to me.
• Reconsider hardcoding org.eclipse.update.install.sources=true in getEffectiveFilterProperties, or make it configurable.

At minimum, artifacts that will be required during provisioning should be fetched while the build is online, restoring the (accidental) 5.0.2 behavior.

Workaround

Overriding the profile property via target-platform-configuration works:

<dependency-resolution>
      <profileProperties>
              <org.eclipse.update.install.sources>false</org.eclipse.update.install.sources>
      </profileProperties>
</dependency-resolution>

[laeubi]

I conceptional -o can only work if it is used symmetrically. So one can not assume that any thing mvn x work offline afterwards when calling mvn -o y in any case given phase x < phase y or any cli invocations are involved (right now there is no go-offline goal at all).

So the problem is more that they are attempted to be downloaded (not that they are enabled). Enabling only means that if they are there they will be used - so it seems an oversight that they are still attempted to be downloaded independently from -o

[tivervac]

To clarify, in a first job, we run dependency:go-offline (to get all regular Maven dependencies) and a full online build to download all p2 dependencies defined in the target platform. The repository and all build jars are then handed over to test jobs that run with --offline. go-offline support would indeed be an even better solution.

[laeubi]

Do you like to provide an integration test + mojo for your case? It should not be too hard here to iterate over all dependencies and trigger their getFile(true) method what then will force the download (an option to download sources or not would be good to have).