Is it possible to target a pom.xml in the project?

[dhalperi]

I.e., if I have a folder //third_party/foo that has pom.xml, foo.jar, foo-sources.jar, etc, can I use it and still get the transitive dependency resolution?

Or can I only depend on artifacts from Maven central?

[pcj]

It would be a new feature, but basically anything you can do with gradle, you can theoretically do with rules_maven (and you definitely can use other maven servers than central).

(However, if your pom.xml file is using other local filesystem resources (like ~/.m2), then it could present problems (or require running bazel in non-sandboxed mode)).

If you have an example test repo that would help.

[dhalperi]

Here's what we're doing:

• we use the JsonPath library, which is released on Maven Central.

• There's a bug that is patched in master, but not yet released.

The question is, what's the easiest way to get the HEAD version?

What we did using Maven was just build the jar ourselves with a custom version and ship the jar, sources, and pom.xml in our source tree. Then we mvn install:install-file the jar during the build process. The pom.xml still has the normal JsonPath transitive deps, which we did not need to modify.

So what's the right thing to do with bazel? Ideally, we'd reuse that project's maven machinery as much as possible until they release a new version.

[pcj]

So JsonPath uses gradle for it's build, so that is convenient here. I could imagine we could have a gradle_java_import rule that (1) takes a build.gradle file as input, (2) runs a gradle build, (3) takes the jar output and imports it into bazel. Then you could do something like:

new_git_repository(
    name = "jsonpath",
    url = "github.com/janeway/jsonpath",
    build_file_content = """
load("@org_pubref_rules_maven", "gradle_jar_import")
"""
gradle_java_import(
    name = "jar",
    build = "build.gradle",
    srcs = glob(["src/main/java/**"]),
)

and then use it as

java_library(
   ...
   deps = ["@jsonpath//:jar"],
)

WDYT?

[dhalperi]

I can't quite tell from that proposal -- would it integrate into the maven ecosystem, such that

• the gradle build process invoked would use the maven jars in WORKSPACE
• the jar itself, if depended-upon by other maven jars in WORKSPACE, would be used?

[pcj]

The way I proposed it:

1. Gradle itself, alone, would be used to build a jsonpath.jar. No other jars from the WORKSPACE would be used at this step.
2. The output jar (built by gradle) would become available to the WORKSPACE via a java_import rule. Other java_library targets would refer to that jar

[dhalperi]

Sorry for the delay, was on a ski trip :)

My questions for your proposal:

• What's the best way to ensure that gradle uses the same version of transitive dependency jars (which it pulls from Maven, after all) as the one version we use in our Bazel?
• How can we ensure that libraries that depend on the output jar built by gradle get the right transitive maven dependencies?

Aka, if jsonpath depends on jsonpath-core and a maven module foo depends on jsonpath-core, I want to make sure they're the same version, that depending on both jsonpath and foo gets only single copy of jsonpath core, and that depending on jsonpath does invoke a transitive dependency on @jsonpath_core//:compile for example.