Less strict maven package names for self-managed instances
Problem to solve
Currently, the maven package registry requires users name their packages as the full project path when using the instance level endpoint. This is due to the fact that multiple users/companies/orgs, might want to use the same package name, but when a consumer of the package wants to install it from the instance level, GitLab needs a way to identify which package is which, purely from the name. So companyA might have a package foo
, and so would companyB. Instead of allowing only one package named foo
, we have them use the package name: path/to/foo
, which might be something like companyA/subgroup/foo
and companyB/subgroup/foo
. Then when a consumer wants to install a package, they use that name and GitLab knows which one to send them.
For GitLab.com, this makes sense as there are many users sharing these endpoints. We have group level and project level endpoints to help alleviate this problem. However, when a customer is using a self-managed instance, they are in control of the entire instance, and it would often be beneficial to allow for less strict naming at the instance level.
Intended users
Users with self-managed GitLab instances utilizing the maven package registry.
Further details
Concerns
The self-managed users would have to be careful about naming to prevent naming collisions, we should add validation at the code level to prevent this and to prevent a colliding package from overwriting the original package of that name.
Proposal
Set up a way for self-managed instances to have the option to use less strict names.
What does success look like, and how can we measure that?
A self managed user can create maven packages with any name at the instance level.