bazel-contrib / bazel-contrib/rules_jvm_external
Support a deep, group-id-based workspace package layout
- Dominant language
- Java
- Stars
- 373
- Forks
- 301
- Avg merge
- 7d 17h
- Merged PRs (30d)
- 3
Description
The present layout of the maven workspace has some problems, both stylistically as well as semantically (though the latter is a rare issue).
I'd love to see an optional layout whereby instead of`@maven//:all_the_maven_things` could be `@maven//some/group/id:artifact_id`. This would be preferable for three reasons.
1. It's both more bazely and more maveny. Targets are the logical bazel equivalent of a maven artifact (the locus of configuration, and the compilation unit). Maven groupIds are a namespace akin to bazel packages space. Also, this format lays out the groupId very similarly to how the actual maven repositories are structured, so it's a familiar pattern to both bazel and maven users.
2. having `@maven//:some_group_id_artifact_id` allows for weird cases of collision. This is rare, and admittedly contrived, but `com.squareup.myprocessor:compiler` and `com.squareup:myprocessor-compiler` would resolve to the same target in the flat maven workspace. It's possible to fix that with a double-underscore as a separator, but it's currently a (small, abstract) risk.
3. It would make migrating from bazel_maven_repository easier, and therefore moving folks from two maven solutions to one easier. I personally would love to see a single blessed solution that has the features we need in it. I think the learning from two such solutions has mostly happened, and I think there isn't THAT much innovation left to happen separately that can't happen on the official project, so I'd love to see some convergence on features and approach and then wind down ours. Probably the biggest hurdle is the addressing scheme (as well as the build snippet override for edge-cases).
I think the implementation isn't that difficult - Rather than play out one big build file, you just group the targets by group_id and play them out in per-group-id package directories. I'm willing to work up a PR if it's likely to be accepted.
Contributor guide
Research direction
Start by tracing how the current flat Maven workspace layout is generated and how targets are addressed. Done means an optional layout groups targets by Maven group ID in per-group package directories while preserving artifact-based addressing and avoiding flat-name collisions.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- build-system
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100