Add transitive jar dependencies to depmap project info goal for intellij plugin.

Review Request #1047 - Created Sept. 18, 2014 and submitted

Tejal Desai
fkorotkov, jsirois, stuhood, zundel

Add transitive jar dependencies to depmap goal for Pants Intellij plugin

When creating projects using the plugin, the depmap showed direct dependencies for 3rdparty jar libraries.
This change add the trasitive dependency jars to the depmap output.
The transitive jars are required to correctly configure intellij modules.


Added integration tests but need to verify the contents.

PR created here:
{Coverage increased (+0.04%) when pulling 09790ec on add_transitive_jar_deps into ad7d09d on master.}

Locally tested
./pants tests/python/pants_test/tasks:depmap_integration


  • 0
  • 2
  • 1
  • 3
Description From Last Updated
Fedor Korotkov
Tejal Desai
Tejal Desai
Eric Ayers
Tejal Desai
Tejal Desai
Tejal Desai
Eric Ayers
Eric Ayers
Ity Kaul
Tejal Desai
Tejal Desai
Ity Kaul
Tejal Desai
Eric Ayers
Tejal Desai
Review request changed

Status: Closed (submitted)

John Sirois


This test and test_depmap_without_resolve should be red flags - if depmap requires a resolve it should do this in prepare such that ./pants depmap --depmap-project-info ... just works. If the idea is that the only user of the --depmap-project-info is in fact the idea plugin and that plugin knows to call resolve (ie: your goal is to not impose resolve overhead on human users of depmap), that's a good sign that all the code in the --depmap-project-info branches should be factored out to its own IDEA-specific Task.


  1. Plugin calls depmap twice. First time wihtout resolve to get a project mapping so we can open the project quickly. And in background it calls depmap the second time with resolve and configures jars afterwards. It allows us to open a project and start indexing it in parallel with jar resolving.

  2. That's fine in the very specific context of use of the depmap goal by IDEA, but its extremely confusing to have this mixed into the depmap goal a user uses (and that a user would not know to call resolve + use the flag). For that reason I think it makes alot of sense to split out the behavior needed by the IDEA plugin to a seperate Task. That task can be installed without a description and not show up in goals help, etc...

  3. ... at least it confused Patrick and I for an hour or so and we're presumably power-users!

  4. Originally it was a separate goal :-) check second review change after Ity's and Larry's comments.

    But I think it's better to have a separate goal for getting ide specific information about targets.

  5. It can be a separate task, however we still need to do ./pants goal resolve new_task <>,

    Lasttime i spoke with Patrik, the new scheduling based on product types will not support scheduling to depend on options.
    As Fedor mentioned, we first run a task to only get internal source dependencies (which is what depmap does).
    Then run resolve and consume resolve task products.

    Other option is replace this by two tasks, one which depends on resolve product types and one which does not.
    1. ./pants depmap_replacement
    2. ./pants resolve_depmap_replacement

  6. I think at the end of the day scheduling with product types will in fact have access to / need options to support recursive cases like building scrooge inline before using scrooge (in the case where you use scrooge and its hosted in the same repo - aka birdcage). In that case you need to have the option that specifies the tool spec.

    Even if not so, your idea of a pair of tasks makes sense.