Allow target-definition to be specified in `repositories` block

[mickaelistria]

Conceptually, a .target definition is more like a Maven repository: it's a definition of the content available for dependency resolution. Currently, it's only possible to configure a target definition in target-platform-configuration mojo-is; it would be a bit more consistent to allow blocks such as

  <repository>
    <id>lsp4e-target</id>
    <layout>eclipse-target-definition</layout>
    <!-- relative to basedir -->
    <url>../target-platforms/target-platform-latest/target-platform-latest.target</url>
    <!-- or absolute -->
    <url>file:/${env.WORKDIR}/target-platforms/target-platform-latest/target-platform-latest.target</url>
    <!-- or published -->
    <url>https://git.eclipse.org/c/lsp4e/lsp4e.git/plain/target-platforms/target-platform-latest/target-platform-latest.target</url>
    <!-- or maven coordinates, to resolve one way or the other (reactor, local repo, remote repo) -->
     <url>mvn:org.eclipse.lsp4e:target-platform-latest:0.13.1-SNAPSHOT</url>
  </repository>

[laeubi]

What is the advantage of this notation over configuring the target-platform-configuration mojo? Especially as we already have support for a <file> reference there it sounds more profitable to extend this with an <url> one as well.

[mickaelistria]

The advantage is IMO consistency and also more straightforward learning of Tycho. But indeed, it wouldn't bring any functional benefit nor cover new use case.

[laeubi]

I'm not sure if this does not bring in additional problems as we have another source of indirection the because a target is not really a singular repository (e.g. one could configure the target env in the target-platform-configuration mojo and so on what would be then missing here. If you are looking for a more consistent approach (e.g not defining thins in multiple places), my idea of allowing to encode target locations directly in the target-platform-configuration mojo might be more profitable as it would allow to be a replacement of the repository configuration.

[mickaelistria]

my idea of allowing to encode target locations directly in the target-platform-configuration mojo might be more profitable as it would allow to be a replacement of the repository configuration.

The issue with this approach is that instead of fitting into the well-known Maven model, Tycho becomes more or less a forked format with its custom patterns for concepts that are already existing in the Maven model; making it harder to learn and use for newcomers.

[laeubi]

@mickaelistria is this still something you want to see in tycho?

[mickaelistria]

I still believe it would make a lot of sense to use the Maven model element to represent available depedencies in order to configure available dependencies, more than a target-platform-configuration plugin. However, we can currently leave without it; and I don't plan to work on it soon.

[mickaelistria]

Thanks! While this is not a game changer per-se, I believe this will actually allow to make Tycho a bit more maven-y by replacing some Tycho-specific constructs (target-platform-configuration) by standard repository. We can expect that some integrations such as m2e can be made a bit easier.