A managed_jar_libraries factory to reduce 3rdparty duplication.

Review Request #3372 - Created Jan. 25, 2016 and submitted

Garrett Malmquist
benjyw, nhoward_tw, patricklaw, stuhood, zundel
In an effort to reduce duplication of 3rdparty configuration, I
introduced a `managed_jar_libraries` factory. It syntactically
appears very similarly to a managed_jar_dependencies target, but it
also generates jar_library targets for each jar() it contains. It
does not generate anything for artifacts which are specified
indirectly with a jar_library spec (rather than a directly embedded
jar() object), because that would be redundant (and could even
likely conflict with existing definitions in the BUILD file).

Added integration tests to test_jar_dependency_management_integration.py.

CI went green here: https://travis-ci.org/pantsbuild/pants/builds/104732867
CI went green here: https://travis-ci.org/pantsbuild/pants/builds/104770329
CI went green here: https://travis-ci.org/pantsbuild/pants/builds/104919830


  • 0
  • 5
  • 1
  • 6
Description From Last Updated
Eric Ayers
Nick Howard (Twitter)
Garrett Malmquist
Nick Howard (Twitter)
Eric Ayers
Garrett Malmquist
Eric Ayers
Garrett Malmquist
Garrett Malmquist
Review request changed

Status: Closed (submitted)

Change Summary:

In commit 6ea125a5a8e3c985e5b219e78de0e32d49a274b6, thanks Nick & Eric!

Benjy Weinberger


Out of curiosity, why would there be a cycle? What's an example of where that could happen?

More generally, it's not clear to me from this comment why this can't be implemented as traversable_dependency_specs (as it was before), which is not the same as being in dependencies=.

Oh, is this the 'cycle' you were referring to earlier?

I'm confused by this. Where are the versions specified? Why would we allow this?

testprojects/3rdparty/managed/BUILD (Diff revision 4)

This is a great example. Makes the whole thing much easier to understand.