Plugin Manager re-resolves dependencies unnecessarily
- Dominant language
- Java
- Stars
- 14.9k
- Forks
- 3.5k
- Avg merge
- 19h 14m
- Merged PRs (30d)
- 63
Description
**Logstash information**:
Please include the following information:
1. Logstash version (e.g. `bin/logstash --version`): `v7.15.0`...`main`
2. Logstash installation source (e.g. built from source, with a package manager: DEB/RPM, expanded from tar or zip archive, docker): _any_
3. How is Logstash being run (e.g. as a service/service manager: systemd, upstart, etc. Via command line, docker/kubernetes): _any_
**Plugins installed**: (`bin/logstash-plugin list --verbose`)
_n/a_
**JVM** (e.g. `java -version`): _any_
If the affected version of Logstash is 7.9 (or earlier), or if it is NOT using the bundled JDK or using the 'no-jdk' version in 7.10 (or higher), please provide the following information:
1. JVM version (`java -version`)
2. JVM installation source (e.g. from the Operating System's package manager, from source, etc).
3. Value of the `LS_JAVA_HOME` environment variable if set.
**OS version** (`uname -a` if on a Unix-like system): _any_
**Description of the problem including expected versus actual behavior**:
In https://github.com/elastic/logstash/pull/13015 we _froze_ the lockfile and "genericized" the lockfile to only include the generic "java" platform, un-freezing the lockfile when performing mutative operations (`install`, `remove`, `update`).
But because bundler uses the _current_ specific platform (e.g., `universal-java-21` when run on Java 21) as part of dependency resolution, the absence of the current specific platform from the list of platforms in the lockfile causes it to perform an additional dependency-graph resolution when performing these actions (while the lockfile is unfrozen).
Contributor guide
Assessment
This issue has not been assessed yet.