Target Platform for 3rd parties: Orbit vs Maven

Target Platform for 3rd parties: Orbit vs Maven
what happens if orbit is discontinued

problems / knowledge gaps for maven dependencies in target

• oomph: to my knowledge oomph cannot do it and platform cheats around it using a "private orbit" / using previous built p2 repo
• tycho 2.7.5: we currently dont use a new enhough tycho cause tycho has problems with pom dependencies packages to target platforms but not available in repo https://github.com/eclipse/xtext-eclipse/issues/1931
• tycho 3.0 requires java 17 and thus toolchain setup. this might complicate stuff.
• we build parts with gradle then build features with tycho in xtext-umbrella and also repackage orbit stuff there https://github.com/eclipse/xtext-umbrella/blob/master/releng/org.eclipse.xtext.sdk.p2-repository/category.xml (or inlude them in features). this repo is then signed and deployed via https://github.com/eclipse/xtext-umbrella/blob/master/releng/jenkins/sign-and-deploy/Jenkinsfile which uses https://github.com/xtext/publishing/ to sign stuff in the p2 repo (and the maven artifacts, both curling the jarsigner serivce to my knowledge). unclear what to do with the maven dependencies there (the ones we repackage) and how to separate the two things.
  (maybe https://docs.google.com/document/d/1dl10ia092X5hN1qfKoHYvriCNM-iBqiOkfjnntxaBbk/edit ?!? - is there a better documentation or example somewhere?)
• is it possible to manage the version of the maven dependencies using a dependencyManagent config / bom ?
• in customer projects i have seen terrible build times using this feature
• ..... 1000 problems we dont see yet

Start by reading the referenced xtext-umbrella category.xml and Jenkinsfile, then review the linked Tycho issue and the notes about Oomph, Tycho, Gradle, and Maven dependencies. The issue is exploratory; done would require an agreed approach for target-platform dependencies, version management, signing, and deployment, with the relevant documentation or examples identified.