twosigma / twosigma/beakerx

Importing a Maven bill of materials with %classpath

Open
#7,911 0 comments 1 reaction 0 assignees View on GitHub
Dominant language
Jupyter Notebook
Stars
2.9k
Forks
383
PR merge metrics
No merged PRs in 30d

Description

Maven supports the concept of a [Bill of Materials](https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies) (BOM), a "grocery list" of artifacts at compatible versions. For projects with a large number of components, this is extremely useful. You can specify a single version—the version of the BOM—and then list the dependencies you want with only `groupId`+`artifactId`, leaving off the respective `version` values knowing they will be selected correctly from the BOM. With Maven `pom.xml` files, this is accomplished using `import`. Consuming these BOMs is [possible in Gradle](https://github.com/tsachev/lein-bom), and [also in leiningen with a plugin](https://github.com/tsachev/lein-bom), but [maybe not with SBT](https://stackoverflow.com/questions/42032303/how-do-i-use-a-maven-bom-bill-of-materials-to-manage-my-dependencies-in-sbt), and apparently also not with Groovy Grape based on my research.

It would be valuable if BeakerX notebooks could specify BOMs using the `%classpath` magic. Without such a feature, there is no surefire way to ensure compatible versions of various components are used. Unfortunately, Maven suffers from an [inconsistency in how dependency versions are computed](https://stackoverflow.com/q/45041888/1207769); support for BOMs would avoid this bug (which seems highly unlikely to be fixed any time soon) on the BeakerX side.

I am willing to dig into writing a patch for this feature, but need to hear from the maintainers first that this is something they agree would be worthwhile. What do you think?

Also [briefly discussed earlier on Gitter](https://gitter.im/twosigma/beakerx?at=5c25116493cce97d3ba6fc83).

Contributor guide

No contributing guide indexed for this repository

Research direction

The issue identifies the %classpath magic and Maven BOM support but names no files or tests. First confirm that maintainers still want this feature, then trace how %classpath resolves Maven dependencies; done means a notebook can declare a BOM and obtain compatible versions for dependencies without individual version values.

Written by the indexing model from the issue text.

Assessment

Tech stack
java, jupyter-notebook
Domain
build-system, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.