Force fetch location of dependency artifacts for feature projects

[alxflam-work]

Hi, I'm currently upgrading a codebase from tycho 1.7.0 to 4.0.13. I do have a minimal reproducible example for what i'm describing, but first here's the description of what occurred during this migration:

We have a feature project, let's call it docs-feature for this discussion, which includes some other features and bundles in its feature.xml. The included features / plugins of this docs-feature are not part of the same reactor build like the docs-feature, they are resolved using a p2 repository. What we do with the docs-feature then is the following:

The maven-dependency-plugin and its unpack-dependencies goal are used to fetch all the asciidoc files from the contents of the feature. Then we can generate some HTML / PDL documentation from these ADOC files. We're doing it like this because we have a bigger application feature, many bundles provide functionality for it and each of the bundle provides an ADOC file with its user documentation. Then every product has a docs-feature including the bundles relevant for the product and so we can build a single PDF / HTML documentation tailored to the product. So using the docs-feature, we can fetch relevant adoc files, process them into a single document, and then distribute it as a root file feature within the product.

This worked fine in Tycho 1.7.0 but it's failing with Tycho 4.0.13, as since #745 the fetch member of MavenDependencyInjector is only set to true for eclipse-plugin and eclipse-plugin-test packaging types - but we do have a feature project.
So then we get the exception Unknown archiver type: No such archiver: 'tmp' by the unpack-dependencies goal as tycho has not force fetched the dependencies, hence instead the new "file not yet available.tmp" file is assigned to the artifacts. And tmp is not a jar and cannot be handled, and obviously it would be empty, so there's nothing to handle anyways.

I can mitigate the issue when debugging the build by changing fetch to true.
But is there any solution i can apply to force the dependencies to be fetched, even though it is a feature project?
It's not directly possible, as the constructor of MavenDependencyInjector does not have any means to adapt the logic which decides whether fetch is true or false, i was thinking more into a workaround direction whether i could additionally configure some tycho goal to resolve dependencies forcefully?

The only workaround i can currently think of is creating and eclipse-plugin project which requires the bundles included in the docs-feature and generate the PDF / HTML with this project instead, as its project type will force fetch to be true.

The MRE is this repo: https://github.com/alxflam-work/tycho-fetch-location (Maven 3.9.9, Tycho 4.0.13, Java 17)
See branch main and its build error at https://github.com/alxflam-work/tycho-fetch-location/actions/runs/16073946777/job/45364642912 caused by the file not yet available.tmp file due to fetch being false .
On branch ftrFilterGroupId, the following was done: Enabled line 61 of the pom.xml, the build works again as then only the groupId of the local reactor build projects are regarded by the unzip, and as these are part of the local reactor build, their location is resolved.
In my real environment that's not possible, the features and plugins included in the docs-feature are not part of the same reactor build.

[laeubi]

Instead of using dependency:unpack-dependencies you might try to use tycho-p2-extras:mirror instead what should download all dependencies in a configurable way and is P2 aware.

Also you might want to take a look at target-platform-configuration:mirror-target-platform what should also work for feature projects.

[alxflam-work]

Hi @laeubi, thanks for the suggestions. Using mirror-target-platform for the feature sounds promising, but both suggestions would then also require some new logic to process the downloaded bundles and extract their adoc files, e.g. using ant. For this task, the maven-dependency-plugin with its unpack-dependencies goal is really handy. So i have tried the following now: Instead of using a feature-plugin i'm simply using an eclipse-plugin which requires all necessary dependencies as required bundles. Then the old approach with the maven-dependency-plugin still works and i can use a P2 touchpoint instruction in my product to copy the generated PDF and HTML to my products root. That seems to be working fine, without much adaptions to the existing implementation, even getting rid of a more or less useless feature which was only included in the product to provide root files.

[laeubi]

Great to hear you found a solution!