Unresolved requirement from indirect dependencies

[jkoch70]

We have the following problem after switching form tycho 2.6.0 to tycho 3.0.3:
Assume we have a project com.some.A and this project has a dependency to org.eclipse.ui.
All Eclipse dependencies in this project are resolved via a target-platform-configuration with P2 repositories.
The Build of project A works fine.

We have an additional project com.some.B with a dependency to project A.
Project B contains the same target-platform-configuration as project A.
When we now want to build project B without having built project A before in the same local m2 repository, the build fails with:
[ERROR] Unresolved requirement: Require-Bundle: com.some.A
[ERROR] -> Bundle-SymbolicName: com.some.A; bundle-version="1.2.3"; singleton:="true"
[ERROR] com.some.A [53]
[ERROR] Unresolved requirement: Require-Bundle: org.eclipse.ui

Why is tycho not resolving this dependency again from the target-platform-configuration and fetching from P2 like it does with project A?
When we build project A before project B with the same local Maven m2 repository, there is no issue.
Project A and B are configured as eclipse-plugin.

We haven't had this problem with tycho 2.6.0.

[laeubi]

Can you provide your example as an integration-test to demonstrate the issue?

[jkoch70]

Unfortunately, this is really hard to achieve as we have a very complex build environment but I think that I added all relevant facts to my description.
Is there any new parameter (since version 3.x) that must be added e.g. to the target-platform-configuration to make indirect dependencies available?

[laeubi]

Unfortunately, this is really hard to achieve as we have a very complex build environment but I think that I added all relevant facts to my description.

If you are seeing the issue but find it to complex to reproduce, how should one be able to reproduce it without even seeing the issue? Tycho includes > 300 integration tests, none of them currently fails, beside that it builds two complex build setups of the eclipse-platform and some demo projects, all of them succeed.

Is there any new parameter (since version 3.x) that must be added e.g. to the target-platform-configuration to make indirect dependencies available?

There is no such thing I'm aware of, so maybe it is some configuration error, maybe you are using some deprecated or removed function and the error is just a consequence of this, that's impossible to tell without a runable example.

[jkoch70]

After breaking down the problem into two very small projects I have some new findings:

The problem came in between Tycho version 2.6.0 and version 2.7.0.

The problem is, that, beginning from version 2.7.0, once we use a dependency that gets resolved via Maven coordinates, its own dependencies get again resolved only via Maven coordinates and not via P2 repositories.
This was different in version 2.6.0.

In our case, we deploy our own projects into a binary Maven repository and these projects do have dependencies to Eclipse and therefore these dependencies have to be resolved via P2.

Unfortunately, I am still unable to provide an example because I don't have a binary Maven repository where I can give you access to.

[jkoch70]

The pom.xml in the broke down example file that causes the problem looks like this:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>

	<groupId>com.some</groupId>
	<artifactId>B</artifactId>
	<version>1.0.0</version>
	<packaging>eclipse-plugin</packaging>
	
	<properties>
		<tycho-version>2.7.0</tycho-version>
	</properties>
	
	<dependencies>
		<dependency>
			<groupId>com.some</groupId>
			<artifactId>A</artifactId>
			<version>1.0.0</version>
			<scope>provided</scope>
		</dependency>
	</dependencies>
    
	<build>
		<plugins>
			<plugin>
				<groupId>org.eclipse.tycho</groupId>
				<artifactId>target-platform-configuration</artifactId>
				<version>${tycho-version}</version>
				<configuration>
					<resolver>p2</resolver>
					<pomDependencies>consider</pomDependencies>
					<target>
						<artifact>
							<groupId>com.some</groupId>
							<artifactId>eclipse-target</artifactId>
							<version>2022.12.1</version>
						</artifact>
					</target>
				</configuration>
			</plugin>
					
					
			<plugin>
				<groupId>org.eclipse.tycho</groupId>
				<artifactId>tycho-maven-plugin</artifactId>
				<version>${tycho-version}</version>
				<extensions>true</extensions>
			</plugin>

			<plugin>
			  <groupId>org.eclipse.tycho</groupId>
			  <artifactId>tycho-compiler-plugin</artifactId>
			  <version>${tycho-version}</version>
			</plugin>
			<plugin>
				<groupId>org.eclipse.tycho.extras</groupId>
				<artifactId>tycho-eclipserun-plugin</artifactId>
				<version>${tycho-version}</version>
			</plugin>
					
		</plugins>
		
	</build>	
	
	<repositories>
		<repository>
			<id>artifactory</id>
			<name>DevCloudArtifactory</name>
			<url>https://artifactory...</url>
		</repository>
	</repositories>
</project>

[jkoch70]

Would it be possible to get an update on this issue?

[CasperNLD]

I was wondering if a problem we have is related to this issue. However there is no activity since last year. Is there something to report?

[laeubi]

@CasperNLD can you provide an integration-test to demonstrate the issue? We only have fragmentary information here.

Also make sure to always test against latest Tycho (what is 4.0.4 at the moment) if the problem persist there.

[CasperNLD]

As you have suggested, I've tried to get it working with 4.0.4. Unfortunately we use maven-plugins that don't work on maven 3.9. This is already a issue for our backlog for next quarter. If this problem persists after the update, I'll come back with logs.
At this point I cannot confirm if this problem still exists or not.

[jkoch70]

@CasperNLD, our problem is actually pretty simple.
If you once resolve a dependency via Maven (our own bundles) then their dependencies will not be resolved by the target platforms P2 repositories anymore.
This problem came in with Tycho version 2.7.0.
We get an error that "org.eclipse.ui" cannot be found but the Eclipse P2 repositories are in the target platform, of course.
This bundle does also get resolved by any other of our bundles that directly reference this bundle in Manifest.mf.
Our ugly workaround is, we added a new P2 repository to the target platform for our own bundles with Maven as source.
This works but causes always additional efforts on each release/version number change.

[laeubi]

If you once resolve a dependency via Maven (our own bundles) then their dependencies will not be resolved by the target platforms P2 repositories anymore.

This is only partly true, please look here:
https://tycho.eclipseprojects.io/doc/latest/TargetPlatform.html#locally-built-artifacts

This problem came in with Tycho version 2.7.0.

Please also consider this release note hint:
https://github.com/eclipse-tycho/tycho/blob/main/RELEASE_NOTES.md#caution-when-switching-between-tycho-versions

[jkoch70]

Our issue is not having data in our local Maven repository as our Jenkins build job always starts with an empty local Maven repository.
The issue is that when a dependency comes from Artifactory their dependencies are not resolved via the configured P2 target platform, anymore.
Can we enable the Tycho version 2.6 behavior with a property again?

[laeubi]

@jkoch70 I'm not sure what Tycho 2.6 behavior specifically means, Tycho always resolves dependencies from P2, if you specify them in the pom, they will (additionally) be resolved from there if not found at least in latest Tycho... so the best would be to provide an integration-test to demonstrate the issue, its hard to tell from some pom.xml fragments to guess whats might be wrong here.

[jkoch70]

The bundle I am talking about does not have any dependencies in pom.xml but <packaging>eclipse-plugin</packaging> and a dependency to org.eclipse.ui in the Manifest.mf.
I agree, an integration test would be the best to communicate my problem but this will take some time that we don't have currently.