issue #697 reproducer

[ghost]

The test case attempts to build two plugins with dependencies from an external (Nexus) repository.

The first plugin depends on a Maven artifact which is rebundled and builds successfully.
The second plugin depends on an OSGi bundle which can't be resolved during the build.

The issue has been introduced with Tycho 2.7.0.

[github-actions]

Unit Test Results

153 files  153 suites   1h 20m 7s ⏱️
258 tests 254 ✔️ 3 💤 0 ❌ 1 🔥

For more details on these errors, see this check.

Results for commit 047ee2c.

[laeubi]

@pzi-dsa well done in reproduce the issue, I think the problem is the following log-output:

[DEBUG] Resolving artifact de.monticore:dsltool-api:jar:0.0.1 from [central (https://repo.maven.apache.org/maven2, default, releases)]
[DEBUG] Skipped remote request for de.monticore:dsltool-api:jar:0.0.1, already updated during this session

This is most probably because we add maven dependencies to the pom model and then maven resolves it already there. Then when the target retries it might has already failed the attempt and did not try again with the different repositories (probably a bug in maven).

[ghost]

Then when the target retries it might has already failed the attempt and did not try again with the different repositories (probably a bug in maven).

I agree, it seems like the problem only appears, whenever dependencies are resolved via Maven. I assume the problem only appeared with 2.7.0 because of the addition of Maven metadata to be bundled artifacts. Since then Maven is used directly, in favor of Tycho.

[DEBUG] Resolving artifact de.monticore:dsltool-api:jar:0.0.1 from [central (https://repo.maven.apache.org/maven2, default, releases)]

I noticed that the nexus repository is not included in the brackets. Instead it looks like Maven only uses central, default and releases to find the artifact. Is Maven aware of the repositories specified in the target platform definition?

During separate tests, I replaced the URL in either the central, default or releases repository with the one from the nexus repository. In all cases, Tycho/Maven was then able to find all required dependencies. My guess is that either the resolver instance used by Maven is created before Tycho adds the repositories from the target platform to it and is then not properly updated, or the repositories aren't added to begin with.

Edit: I think I misread the debug message. default and release are not separate repositories. Nevertheless, even with unrelated ids, the build still succeeds.

[laeubi]

I noticed that the nexus repository is not included in the brackets. Instead it looks like Maven only uses central, default and releases to find the artifact. Is Maven aware of the repositories specified in the target platform definition?

No because target platform resolution has nothing to do with maven resolution, even though both use the same resolver!
I have to check if thats a problem how tycho calls the resolver or if that is a bug in maven.

[laeubi]

Okay what happens here is the following:

The target is resolved and there everything works fine, but maven records the repository that was used to resolve the artifact:

dsltool-api-0.0.1.jar>rwth=
dsltool-api-0.0.1.pom>rwth=

Then we add this to the maven model as a regular dependency and maven tries resolve this as well. Because the repository is not configured, maven think something has changed and do an update with maven central, where it is not found.

So what would work is to configure all repositories as well for maven as for the target, but that's kind of undesirable...

There are some ways to handle this, but I'm not sure each has some drawbacks:

1. we could mark the dependency as optional, while this works its a bit a hack because it will simply ignore the failure
2. we could add all repositories from the target to the maven model, but for sure this might also be undesirable because now we enhance the maven resolution with things from the target and possibly mix different target location items
3. We could assemble a local artifact repository and only add resolved items from the target, but this might create additional build-time and require more disk-space.

[laeubi]

@pzi-dsa thanks for the reproducer, I have merged this and fixed it with #855