Adding managed_jar_dependencies docs to

Review Request #3776 — Created April 28, 2016 and submitted

benjyw, jsirois, stuhood, zundel
This adds a large section explaining the motivation behind and the
use of `managed_jar_dependencies` and `managed_jar_libraries`.

Generated doc site looks the way it is supposed to:

  • 0
  • 0
  • 2
  • 0
  • 2
Description From Last Updated
  1. Hey Garrett,

    To make it easier to review a doc change, you can publish a preview that everyone can see with

    ./build-support/bin/ -p -d gmalmquist

    It will upload to the website under a directory staging/gmalmquist

    1. Thanks for the tip, up at

    2. Thanks! Can you re-generate the graphic so it isn't so ... tall?

  2. It may be worth noting why a simple 'strict' conflict-manager ( is not enough.  This is my 1st question when reading this at any rate.
    Afaict there are 2 reasons:
    1. this allows you to re-define a single strict version number instead of fail when version numbers are different.
    2. this allows you to be selectively strict for only certain deps and not the whole repo.
    1. Yeah; you could do it with strict and lots and lots of carefully tailored excludes, but it's a bit unweildy unless you had a good way to generate the excludes (like what foursquare does).

    2. I'm not sure that it's currently unclear why you'd want managed_jar_libraries instead of using ivy's strict conflict manager.

      I think the build system doing what you want it to do and successfully building with the correct transitive artifacts is clearly more desirable than it just failing.

    3. I don't think its clearly better but I'm happy to have this addition left out.
      I say its not clearly better, because a managed dep added today, silently alters expected versions of 3rdparty libs a year later.  The compile success will stop egregious issues, but there is no sure runtime success.  A fail fast may feel inconvenient, but it at least forces a dev to come to grips with doing the analysis or saying, lets just go for it and see if it flies.
  2. s/intermediary/intermediate/ (When I think of an intermediary I think of a person)

  3. Worth mentioning that recompiling the same target with different jar resolutions is a feature of pants that can be useful, but may not be what you want.

  4. I wouldn't say this. I think you can do this in maven too effectively by having multiple parent poms.

  2. Let's list a few reasons why you might want the same ones:

    • Predictable behavior across all apps
    • Security concerns may make you want to ensure you are at a certain version of a jar to avoid known vulnerabilities.
    • Caching concerns (which you mention below)
  3. I think Right here you could add a section called 'possible solutions'. Using strict deps in ivy might be one. Explicitly listing every jar you want on each target is another. using managed dependencies is a third option.

    You could then explain in the next paragraph how it works and why it is better than the previous 2 solutions.

  1. I'd still like to see the diagram made shorter. The arrows are taking up a lot of vertical space.

  2. s/cache-trash/cache thrashing/

  3. s/multiple different/multiple/

    or choose different, but using both words sounds redundant to me.

  4. s/what/which/

  1. Ship It!
  1. Ship It!
    1. I was chatting with Benjy and he reqested that we not merge this until after he lands is mega refactor.

    2. Oh okay.

  1. Ship It!
Review request changed

Status: Closed (submitted)

Change Summary:

In 807d746a4c049b97dd462dea9247d6b162aa42ac, thanks John and Eric!