Handling jar dependency resolution with jruby projects
- Dominant language
- Java
- Stars
- 14.9k
- Forks
- 3.5k
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 88
Description
since there are more and more java-jar based ruby plugins being introduced, jar conflicts are inevitable. To remedy this, one strategy we can try and practice is to package the java extension using jar-dependencies. This way we do not have farjar/shadowed-jars, and we can rely on jar-dependencies' `require_jar` to attempt to error out on version conflicts.
here is an example project using this build strategy: https://github.com/talevy/log4j2-json-logging
it is a joint effort between the `Rakefile`, `build.gradle`, and the gemspec.
This affects how Logstash can support multiple version of the same dependencies that get pulled into its classpath. Currently, `jar_dependencies` requires these jars and checks if any other jars of the same type were loaded previously. Here is its logic: https://github.com/mkristian/jar-dependencies/blob/master/lib/jar_dependencies.rb#L302-L320.
Moving forward, we need to decide how to organize these projects. the proposal above is just one way.
Contributor guide
Research direction
Start by comparing the example project's Rakefile, build.gradle, and gemspec, then read the referenced jar-dependencies logic around lib/jar_dependencies.rb lines 302-320. Determine how Logstash's JRuby projects should organize jar dependencies and handle conflicting versions. Done means the project-wide packaging strategy is agreed and its effect on multiple dependencies in the classpath is documented or implemented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, ruby
- Domain
- backend, build-system
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100