bazel-contrib / bazel-contrib/rules_jvm_external
Pinning a platform specific dependency doesn't work correctly
- Dominant language
- Java
- Stars
- 373
- Forks
- 301
- Avg merge
- 7d 17h
- Merged PRs (30d)
- 3
Description
Take a JavaFX project with two lockfiles (one for windows and one for linux):
```starlark
maven.install(
name = "windows",
artifacts = [
"org.openjfx:javafx-graphics:win:17",
"org.openjfx:javafx-controls:win:17",
"org.openjfx:javafx-fxml:win:17",
"org.openjfx:javafx-base:win:17",
],
lock_file = "//:windows_install.json",
fetch_sources = True,
)
maven.install(
name = "linux",
artifacts = [
"org.openjfx:javafx-graphics:linux:17",
"org.openjfx:javafx-controls:linux:17",
"org.openjfx:javafx-fxml:linux:17",
"org.openjfx:javafx-base:linux:17",
],
lock_file = "//:linux_install.json",
fetch_sources = True,
)
```
I would expect that running `bazel run @unpinned_linux//:pin` on a windows machine will download the linux jars given the platform qualifier, but instead it downloads the windows jars. The reverse (pinning windows deps on a linux machine) will also have the same unintended effect.
Am I using rules_jvm_external wrong? If so, how should I go about this instead (or how would I go about creating fat jars)?
Contributor guide
Research direction
Start with the two maven.install declarations and their windows_install.json and linux_install.json lockfiles, then reproduce the behavior using bazel run @unpinned_linux//:pin on the opposite operating system. Done means pinning resolves the artifacts matching the platform qualifier rather than the host platform, or the supported alternative is documented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- build-system
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100