rules for transitive maven dependencies

[Paul Johnston]

I put together a set of workspace rules that I think makes it pretty easy to do transitive maven dependencies while still preserving the {fast, correct} nature of Bazel.  

https://github.com/pubref/rules_maven

It looks like:

maven_repository(

  name = "guice",

  deps = [

    'com.google.inject:guice:4.1.0',

  ],

)

which becomes...

maven_repository(

  name = 'guice',

  deps = [

    'com.google.inject:guice:4.1.0',

  ],

  transitive_deps = [

    '0235ba8b489512805ac13a8f9ea77a1ca5ebe3e8:aopalliance:aopalliance:1.0',

    '6ce200f6b23222af3d8abb6b6459e6c44f4bb0e9:com.google.guava:guava:19.0',

    'eeb69005da379a10071aa4948c48d89250febb07:com.google.inject:guice:4.1.0',

    '6975da39a7040257bd51d21a231b76c915872d38:javax.inject:javax.inject:1',

  ],

)

...and used as follows:

java_binary(

  name = "app",

  main_class = "example.App",

  deps = ["@guice//:compile"],

)

Hope you find it useful.  As always, contributions/feedback/suggestions welcome.

-Paul

[Adam Michael]

Wow, awesome! We've had an open issue about supporting this in the rules that are bundled with Bazel for a while: https://github.com/bazelbuild/bazel/issues/1410

[Justine Tunney]

Yeah this is good work Paul. You've always made good contributions. I think people might find this project as a useful stopgap until we can work out what we're planning in #1410.

Basically, we've built a web gui that generates configs that look like this for java_import_external. We're seeking approval to launch it. That might take a month or two.

The main issue I'm noticing with the design of rules_maven is that it appears as though dependencies would take up quadratic space. Is that the case? For example, what happens if one has a maven_repository() for guice, and another for soy. Both soy and guice depend on guava. Will guava be downloaded separately twice?

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discuss+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/3f87310c-ee03-4f1d-b22d-fad9e07724f4%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Zalán Meggyesi]

I built a Maven plugin that allows you to export your Maven deps as a set of WORKSPACE/BUILD declarations, and separately, the server declarations if needed.

Perhaps the two can be brought together somehow?

[Paul Johnston]

On Wednesday, December 14, 2016 at 4:15:25 PM UTC-7, Justine Tunney wrote:

Yeah this is good work Paul. You've always made good contributions. I think people might find this project as a useful stopgap until we can work out what we're planning in #1410.

Basically, we've built a web gui that generates configs that look like this for java_import_external. We're seeking approval to launch it. That might take a month or two.

The main issue I'm noticing with the design of rules_maven is that it appears as though dependencies would take up quadratic space. Is that the case? For example, what happens if one has a maven_repository() for guice, and another for soy. Both soy and guice depend on guava. Will guava be downloaded separately twice?

Not quadratic.  The @guice namespace does not impose a new namespace for jar artifacts, it's just a place to store the generated rules.bzl file that, it turn, invokes native.maven_jar rules.  These sit behind a require() function that basically is just a native.existing_rule guard to make sure it has not been loaded already.

The generated java_import looks like:

java_library(

  name = 'compile',

  exports = [

    '@aopalliance_aopalliance//jar',

    '@com_google_guava_guava//jar',

    '@com_google_inject_guice//jar',

    '@javax_inject_javax_inject//jar',

  ],

  visibility = ['//visibility:public'],

)

Therefore, all rules call the same guava.  

However, if a soy rule requires a different version of guava having a different sha1, the require function will notice that and complain.  In that event, you'll have to manually resolve the issue by omitting the conflicting dependency.  To do that, you can say `transitive_deps = ["omit:com.google.guava:guava:18.0", ...]` rather than `sha1:com.googleguava:guava:18.0`.

 

To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.