-
Notifications
You must be signed in to change notification settings - Fork 10
/
3rdparty_jvm.html
888 lines (858 loc) · 56.8 KB
/
3rdparty_jvm.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
<!DOCTYPE html>
<html lang="en">
<!--
Copyright 2014 Pants project contributors (see CONTRIBUTORS.md).
Licensed under the Apache License, Version 2.0 (see LICENSE).
-->
<head>
<meta charset="utf-8"/>
<title>JVM Dependency Management</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<link rel="shortcut icon" href="pants-logo.ico">
<!-- In case this is a "test publish", tell search engines where real version lives: -->
<link rel="canonical" href="http://pantsbuild.org/3rdparty_jvm.html">
<link rel="stylesheet" href="bootstrap-custom.min.css">
<link rel="stylesheet" href="bootstrap-custom-theme.min.css">
<link rel="stylesheet" href="docsite.css">
</head>
<body>
<div class="header">
<nav class="navbar navbar-default navbar-static-top">
<div class="container">
<div class="navbar-header">
<button type="button" class="navbar-toggle collapsed" data-toggle="collapse" data-target="#navbar" aria-expanded="false" aria-controls="navbar">
<span class="sr-only">Toggle navigation</span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
<a class="navbar-brand navbar-brand-img" href="index.html">
<img src="pants-logo.ico" alt="[pantsbuild logo]">
</a>
<a class="navbar-brand" href="index.html">
Pants v1
</a>
</div>
<div id="navbar" class="navbar-collapse collapse">
<ul class="nav navbar-nav navbar-right">
<li><a href="/">Docs</a></li>
<li><a href="community.html">Community</a></li>
<li><a href="https://www.github.com/pantsbuild/pants">GitHub</a></li>
<li>
<form class="navbar-form navbar-left search" role="search" action="https://www.google.com/search">
<div class="form-group">
<input type="text" name="as_q" class="form-control query" placeholder="Search">
<input name="as_sitesearch" value="pantsbuild.org" type="hidden">
</div>
</form>
</li>
</ul>
</div><!--/.nav-collapse -->
</div>
<div class="deprecated">Pants v1 is no longer maintained. See <a href="https://www.pantsbuild.org/">here</a> for the Pants v2 documentation.</div>
</nav>
</div>
<div class="page">
<div class="container-fluid">
<div class="row">
<div class="col-md-1">
</div>
<div class="col-md-2">
<div class="site-toc">
<ul>
<li class="toc-h1 toc-heading">
Getting Started
</li>
<li class="toc-h1 toc-link ">
<a href="install.html">Installing Pants</a>
</li>
<li class="toc-h1 toc-link ">
<a href="setup_repo.html">Setting Up Pants</a>
</li>
<li class="toc-h1 toc-link ">
<a href="first_tutorial.html">Tutorial</a>
</li>
<li class="toc-h1 toc-link ">
<a href="common_tasks.html">Common Tasks</a>
</li>
<li class="toc-h1 toc-link ">
<a href="orgs.html">Pants for Organizations</a>
</li>
<li class="toc-h1 toc-heading">
Pants Basics
</li>
<li class="toc-h1 toc-link ">
<a href="why_use_pants.html">Why Use Pants?</a>
</li>
<li class="toc-h1 toc-link ">
<a href="first_concepts.html">Pants Concepts</a>
</li>
<li class="toc-h1 toc-link ">
<a href="build_files.html">BUILD files</a>
</li>
<li class="toc-h1 toc-link ">
<a href="target_addresses.html">Target Addresses</a>
</li>
<li class="toc-h1 toc-link ">
<a href="3rdparty.html">Third-Party Dependencies</a>
</li>
<li class="toc-h1 toc-link ">
<a href="options.html">Pants Options</a>
</li>
<li class="toc-h1 toc-link ">
<a href="invoking.html">Invoking Pants</a>
</li>
<li class="toc-h1 toc-link ">
<a href="reporting_server.html">Reporting Server</a>
</li>
<li class="toc-h1 toc-link ">
<a href="ide_support.html">IDE Support</a>
</li>
<li class="toc-h1">
<a class="sidebar-nav-heading" class="toc-drop" data-toggle="collapse" href="#JVM-Support" aria-expanded="false" aria-controls="JVM-Support">JVM Support<span class="caret"></span></a>
<ul class="" id="JVM-Support">
<li class="toc-h1 toc-link ">
<a href="jvm_projects.html">JVM Projects with Pants</a>
</li>
<li class="toc-h1 toc-link toc-here">
JVM Dependency Management
</li>
<li class="toc-h1 toc-link ">
<a href="scala.html">Scala Support</a>
</li>
<li class="toc-h1 toc-link ">
<a href="publish.html">Publishing Artifacts</a>
</li>
<li class="toc-h1 toc-link ">
<a href="from_maven.html">Pants for Maven Experts</a>
</li>
</ul>
</li>
<li class="toc-h1">
<a class="sidebar-nav-heading" class="toc-drop" data-toggle="collapse" href="#Python-Support" aria-expanded="false" aria-controls="Python-Support">Python Support<span class="caret"></span></a>
<ul class="collapse sidebar-nav sidebar-submenu" id="Python-Support">
<li class="toc-h1 toc-link ">
<a href="python_readme.html">Python Projects with Pants</a>
</li>
<li class="toc-h1 toc-link ">
<a href="3rdparty_py.html">Python 3rdparty Pattern</a>
</li>
</ul>
</li>
<li class="toc-h1 toc-link ">
<a href="go_readme.html">Go support for Pants</a>
</li>
<li class="toc-h1 toc-link ">
<a href="node_readme.html">Node.js Support</a>
</li>
<li class="toc-h1 toc-heading">
Code & Doc Generation
</li>
<li class="toc-h1 toc-link ">
<a href="thrift_deps.html">Thrift</a>
</li>
<li class="toc-h1 toc-link ">
<a href="grpcio_gen.html">Python gRPC + protobufs</a>
</li>
<li class="toc-h1 toc-link ">
<a href="page.html">Markdown</a>
</li>
<li class="toc-h1 toc-heading">
Getting Help
</li>
<li class="toc-h1 toc-link ">
<a href="tshoot.html">Troubleshooting</a>
</li>
<li class="toc-h1 toc-link ">
<a href="community.html">Community</a>
</li>
<li class="toc-h1 toc-heading">
Reference
</li>
<li class="toc-h1 toc-link ">
<a href="build_dictionary.html">Pants BUILD Dictionary</a>
</li>
<li class="toc-h1 toc-link ">
<a href="options_reference.html">Pants Reference</a>
</li>
<li class="toc-h1">
<a class="sidebar-nav-heading" class="toc-drop" data-toggle="collapse" href="#Release-Notes" aria-expanded="false" aria-controls="Release-Notes">Release Notes<span class="caret"></span></a>
<ul class="collapse sidebar-nav sidebar-submenu" id="Release-Notes">
<li class="toc-h1 toc-link ">
<a href="notes-1.30.x.html">1.30.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.29.x.html">1.29.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.28.x.html">1.28.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.27.x.html">1.27.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.26.x.html">1.26.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.25.x.html">1.25.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.24.x.html">1.24.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.23.x.html">1.23.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.22.x.html">1.22.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.21.x.html">1.21.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.20.x.html">1.20.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.19.x.html">1.19.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.18.x.html">1.18.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.17.x.html">1.17.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.16.x.html">1.16.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.15.x.html">1.15.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.14.x.html">1.14.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.13.x.html">1.13.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.12.x.html">1.12.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.11.x.html">1.11.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.10.x.html">1.10.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.9.x.html">1.9.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.8.x.html">1.8.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.7.x.html">1.7.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.6.x.html">1.6.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.5.x.html">1.5.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.4.x.html">1.4.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.3.x.html">1.3.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.2.x.html">1.2.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.1.x.html">1.1.x Stable Releases</a>
</li>
<li class="toc-h1 toc-link ">
<a href="notes-1.0.x.html">1.0.x Stable Releases</a>
</li>
</ul>
</li>
<li class="toc-h1 toc-heading">
Developer
</li>
<li class="toc-h1 toc-link ">
<a href="dev.html">Pants Developer Center</a>
</li>
<li class="toc-h1 toc-link ">
<a href="export.html">Export Format</a>
</li>
<li class="toc-h1 toc-link ">
<a href="architecture.html">Architecture</a>
</li>
<li class="toc-h1 toc-heading">
Blogs
</li>
<li class="toc-h1 toc-link ">
<a href="coursier_migration.html">Twitter's Coursier Migration</a>
</li>
</ul>
</div> <!-- site-toc -->
</div>
<div class="col-md-8">
<div class="content">
<div class="mainflow">
<nav class="pagetoc">
<ul>
<li class="toc-h1"><a href="#3rdpartyjvm">3rdparty/jvm</a></li>
<li class="toc-h1"><a href="#your-codes-build-file">Your Code's BUILD File</a></li>
<li class="toc-h1"><a href="#round-trip-dependencies">"Round Trip" Dependencies</a></li>
<li class="toc-h1"><a href="#controlling-jar-dependency-versions">Controlling JAR Dependency Versions</a></li>
<li class="toc-h1"><a href="#managing-transitive-dependencies">Managing Transitive Dependencies</a></li>
<li class="toc-h2"><a href="#the-problem">The Problem</a></li>
<li class="toc-h2"><a href="#possible-solutions">Possible Solutions</a></li>
<li class="toc-h2"><a href="#managed-jar-dependencies">Managed Jar Dependencies</a></li>
<li class="toc-h1"><a href="#using-a-snapshot-jvm-dependency">Using a SNAPSHOT JVM Dependency</a></li>
<li class="toc-h1"><a href="#strict-dependencies">Strict Dependencies</a></li>
<li class="toc-h2"><a href="#what-is-strict_deps">What is strict_deps?</a></li>
<li class="toc-h2"><a href="#why-strict_deps">Why strict_deps?</a></li>
<li class="toc-h2"><a href="#example">Example</a></li>
<li class="toc-h2"><a href="#strict_deps-for-library-developers">Strict_deps for Library Developers</a></li>
<li class="toc-h3"><a href="#invalidation">Invalidation</a></li>
<li class="toc-h2"><a href="#errors-exports-and-missing-deps-suggest">Errors, Exports, and Missing-deps-suggest</a></li>
<li class="toc-h3"><a href="#missing-deps-suggest">Missing-deps-suggest</a></li>
<li class="toc-h3"><a href="#exports">Exports</a></li>
<li class="toc-h3"><a href="#how-to-solve-an-error-with-exports">How to Solve An Error With Exports</a></li>
</ul>
</nav>
<!-- main content start -->
<!-- generated by pants! -->
<style>
.codehilite .hll { background-color: #ffffcc }
.codehilite { background: #f0f0f0; }
.codehilite .c { color: #60a0b0; font-style: italic } /* Comment */
.codehilite .err { border: 1px solid #FF0000 } /* Error */
.codehilite .k { color: #007020; font-weight: bold } /* Keyword */
.codehilite .o { color: #666666 } /* Operator */
.codehilite .ch { color: #60a0b0; font-style: italic } /* Comment.Hashbang */
.codehilite .cm { color: #60a0b0; font-style: italic } /* Comment.Multiline */
.codehilite .cp { color: #007020 } /* Comment.Preproc */
.codehilite .cpf { color: #60a0b0; font-style: italic } /* Comment.PreprocFile */
.codehilite .c1 { color: #60a0b0; font-style: italic } /* Comment.Single */
.codehilite .cs { color: #60a0b0; background-color: #fff0f0 } /* Comment.Special */
.codehilite .gd { color: #A00000 } /* Generic.Deleted */
.codehilite .ge { font-style: italic } /* Generic.Emph */
.codehilite .gr { color: #FF0000 } /* Generic.Error */
.codehilite .gh { color: #000080; font-weight: bold } /* Generic.Heading */
.codehilite .gi { color: #00A000 } /* Generic.Inserted */
.codehilite .go { color: #888888 } /* Generic.Output */
.codehilite .gp { color: #c65d09; font-weight: bold } /* Generic.Prompt */
.codehilite .gs { font-weight: bold } /* Generic.Strong */
.codehilite .gu { color: #800080; font-weight: bold } /* Generic.Subheading */
.codehilite .gt { color: #0044DD } /* Generic.Traceback */
.codehilite .kc { color: #007020; font-weight: bold } /* Keyword.Constant */
.codehilite .kd { color: #007020; font-weight: bold } /* Keyword.Declaration */
.codehilite .kn { color: #007020; font-weight: bold } /* Keyword.Namespace */
.codehilite .kp { color: #007020 } /* Keyword.Pseudo */
.codehilite .kr { color: #007020; font-weight: bold } /* Keyword.Reserved */
.codehilite .kt { color: #902000 } /* Keyword.Type */
.codehilite .m { color: #40a070 } /* Literal.Number */
.codehilite .s { color: #4070a0 } /* Literal.String */
.codehilite .na { color: #4070a0 } /* Name.Attribute */
.codehilite .nb { color: #007020 } /* Name.Builtin */
.codehilite .nc { color: #0e84b5; font-weight: bold } /* Name.Class */
.codehilite .no { color: #60add5 } /* Name.Constant */
.codehilite .nd { color: #555555; font-weight: bold } /* Name.Decorator */
.codehilite .ni { color: #d55537; font-weight: bold } /* Name.Entity */
.codehilite .ne { color: #007020 } /* Name.Exception */
.codehilite .nf { color: #06287e } /* Name.Function */
.codehilite .nl { color: #002070; font-weight: bold } /* Name.Label */
.codehilite .nn { color: #0e84b5; font-weight: bold } /* Name.Namespace */
.codehilite .nt { color: #062873; font-weight: bold } /* Name.Tag */
.codehilite .nv { color: #bb60d5 } /* Name.Variable */
.codehilite .ow { color: #007020; font-weight: bold } /* Operator.Word */
.codehilite .w { color: #bbbbbb } /* Text.Whitespace */
.codehilite .mb { color: #40a070 } /* Literal.Number.Bin */
.codehilite .mf { color: #40a070 } /* Literal.Number.Float */
.codehilite .mh { color: #40a070 } /* Literal.Number.Hex */
.codehilite .mi { color: #40a070 } /* Literal.Number.Integer */
.codehilite .mo { color: #40a070 } /* Literal.Number.Oct */
.codehilite .sa { color: #4070a0 } /* Literal.String.Affix */
.codehilite .sb { color: #4070a0 } /* Literal.String.Backtick */
.codehilite .sc { color: #4070a0 } /* Literal.String.Char */
.codehilite .dl { color: #4070a0 } /* Literal.String.Delimiter */
.codehilite .sd { color: #4070a0; font-style: italic } /* Literal.String.Doc */
.codehilite .s2 { color: #4070a0 } /* Literal.String.Double */
.codehilite .se { color: #4070a0; font-weight: bold } /* Literal.String.Escape */
.codehilite .sh { color: #4070a0 } /* Literal.String.Heredoc */
.codehilite .si { color: #70a0d0; font-style: italic } /* Literal.String.Interpol */
.codehilite .sx { color: #c65d09 } /* Literal.String.Other */
.codehilite .sr { color: #235388 } /* Literal.String.Regex */
.codehilite .s1 { color: #4070a0 } /* Literal.String.Single */
.codehilite .ss { color: #517918 } /* Literal.String.Symbol */
.codehilite .bp { color: #007020 } /* Name.Builtin.Pseudo */
.codehilite .fm { color: #06287e } /* Name.Function.Magic */
.codehilite .vc { color: #bb60d5 } /* Name.Variable.Class */
.codehilite .vg { color: #bb60d5 } /* Name.Variable.Global */
.codehilite .vi { color: #bb60d5 } /* Name.Variable.Instance */
.codehilite .vm { color: #bb60d5 } /* Name.Variable.Magic */
.codehilite .il { color: #40a070 } /* Literal.Number.Integer.Long */
</style>
<h1 id="jvm-dependency-management">JVM Dependency Management</h1>
<p>In general, we recommend the <a href="3rdparty.html">3rdparty idiom</a>
for organizing dependencies on code from outside the source tree. This document
describes how to make this work for JVM (Java or Scala) code.</p>
<p>Your JVM code can depend on external, third-party libraries. Pants uses
<a href="http://ant.apache.org/ivy/">Ivy</a> to resolve and retrieve these JAR files.
You should know the (<a href="http://maven.apache.org/guides/mini/guide-central-repository-upload.html">Maven/Ivy groupId, artifactId, and
version</a>)
you want to use.</p>
<h2 id="3rdpartyjvm">3rdparty/jvm</h2>
<p>If you have a small to medium number of third-party dependencies, you can define
them all in a single <code>3rdparty/jvm/BUILD</code> file. If you have a large number, it
may make sense to organize them in multiple subdirectories, say by category or by publisher.</p>
<p>In the appropriate <code>BUILD</code> file, you create a <a href="build_dictionary.html#bdict_jar_library" pantsref="bdict_jar_library"><code>jar_library</code></a>
referencing the <a href="build_dictionary.html#bdict_jar" pantsref="bdict_jar"><code>jar</code></a>s you want:</p>
<p>
<div class="md-included-snippet"><div class="codehilite"><pre><span></span><span class="n">jar_library</span><span class="p">(</span>
<span class="n">jars</span><span class="o">=</span><span class="p">[</span>
<span class="n">jar</span><span class="p">(</span><span class="n">org</span><span class="o">=</span><span class="s1">'com.google.auto.value'</span><span class="p">,</span> <span class="n">name</span><span class="o">=</span><span class="s1">'auto-value'</span><span class="p">,</span> <span class="n">rev</span><span class="o">=</span><span class="s1">'1.1'</span><span class="p">),</span>
<span class="p">],</span>
<span class="c1"># Is used as an annotation processor.</span>
<span class="n">scope</span><span class="o">=</span><span class="s1">'compile'</span><span class="p">,</span>
<span class="p">)</span>
</pre></div>
</div>
</p>
<p>Here, the <a href="build_dictionary.html#bdict_jar_library" pantsref="bdict_jar_library"><code>jar_library</code></a>'s name
defines a target address that other build targets can refer to. The
<a href="build_dictionary.html#bdict_jar" pantsref="bdict_jar"><code>jar</code></a>s refer to jars that Ivy can resolve and fetch.</p>
<p>When <a href="scala.html">using Scala with pants</a>, the <a href="build_dictionary.html#bdict_scala_jar" pantsref="bdict_scala_jar"><code>scala_jar</code></a> symbol will add the appropriate Scala version suffix (e.g. <code>_2.12</code>) to the <code>name</code> field automatically.</p>
<h2 id="your-codes-build-file">Your Code's BUILD File</h2>
<p>To set up your code to import the external jar, you add a dependency to
the appropriate Java target[s] in your <code>BUILD</code> file and add <code>import</code>
statements in your Java code.</p>
<p>For example, your <code>BUILD</code> file might have</p>
<p>
<div class="md-included-snippet"><div class="codehilite"><pre><span></span><span class="n">java_library</span><span class="p">(</span><span class="n">name</span><span class="o">=</span><span class="s1">'autovalue-lib'</span><span class="p">,</span>
<span class="n">dependencies</span> <span class="o">=</span> <span class="p">[</span>
<span class="s1">'3rdparty/jvm/com/google/auto/value'</span><span class="p">,</span>
<span class="p">],</span>
<span class="p">)</span>
</pre></div>
</div>
</p>
<p>And your Java code might have:</p>
<div class="codehilite"><pre><span></span><span class="kn">import</span> <span class="nn">com.google.auto.value.AutoValue</span><span class="p">;</span>
</pre></div>
<h2 id="round-trip-dependencies">"Round Trip" Dependencies</h2>
<p>It is possible for your code to exist as source in the repo but
also be published as a binary to an external repository. If you happen to pull in any
third party artifacts, they may express a dependency on the published
version of the artifact. This means that the classpath will contain
both the version in the repo compiled from source and an older version
that was previously published. In this case, you want to be sure that
when pants always prefers the version built from source.</p>
<p>Fortunately, the remedy for this is simple. If you add a <code>provides=</code> parameter
that matches the one used to publish the artifact, pants will always prefer the
local target definition to the published jar if it is in the context:</p>
<div class="codehilite"><pre><span></span><span class="n">java_library</span><span class="p">(</span>
<span class="n">name</span><span class="o">=</span><span class="s1">'api'</span><span class="p">,</span>
<span class="n">sources</span><span class="o">=</span><span class="p">[</span><span class="s1">'*.java'</span><span class="p">],</span>
<span class="n">provides</span><span class="o">=</span><span class="n">artifact</span><span class="p">(</span><span class="n">org</span><span class="o">=</span><span class="s1">'org.archie'</span><span class="p">,</span> <span class="n">name</span><span class="o">=</span><span class="s1">'api'</span><span class="p">,</span> <span class="n">repo</span><span class="o">=</span><span class="n">myrepo</span><span class="p">),</span>
<span class="p">)</span>
<span class="n">jar_library</span><span class="p">(</span>
<span class="n">name</span><span class="o">=</span><span class="s1">'bin-dep'</span><span class="p">,</span>
<span class="n">jars</span><span class="o">=</span><span class="p">[</span>
<span class="n">jar</span><span class="p">(</span><span class="n">org</span><span class="o">=</span><span class="s1">'org.archie'</span><span class="p">,</span> <span class="n">name</span><span class="o">=</span><span class="s1">'consumer'</span><span class="p">,</span> <span class="n">rev</span><span class="o">=</span><span class="s1">'1.2.3'</span><span class="p">),</span>
<span class="p">],</span>
<span class="n">dependencies</span><span class="o">=</span><span class="p">[</span>
<span class="c1"># Include the local, source copy of the API to cause it to be used rather than</span>
<span class="c1"># any versioned binary copy that the `consumer` lib might depend on transitively.</span>
<span class="s1">':api'</span><span class="p">,</span>
<span class="p">])</span>
</pre></div>
<h2 id="controlling-jar-dependency-versions">Controlling JAR Dependency Versions</h2>
<p><strong>If you notice that one "foreign" dependency pulls in mostly wrong
things,</strong> tell Pants not to pull in its dependencies. In your
<code>3rdparty/.../BUILD</code> file, use <code>jar</code>'s <code>intransitive</code> argument; then
carefully add hand-picked versions:</p>
<div class="codehilite"><pre><span></span><span class="n">jar_library</span><span class="p">(</span><span class="n">name</span><span class="o">=</span><span class="s2">"retro-naming-factory"</span><span class="p">,</span>
<span class="n">jars</span><span class="o">=</span><span class="p">[</span>
<span class="n">jar</span><span class="p">(</span><span class="n">org</span><span class="o">=</span><span class="s1">'retro'</span><span class="p">,</span> <span class="n">name</span><span class="o">=</span><span class="s1">'retro-factory'</span><span class="p">,</span> <span class="n">rev</span><span class="o">=</span><span class="s1">'5.0.18'</span><span class="p">,</span> <span class="n">intransitive</span><span class="o">=</span><span class="kc">True</span><span class="p">),</span>
<span class="p">],</span>
<span class="n">dependencies</span><span class="o">=</span><span class="p">[</span>
<span class="c1"># Don't use retro's expected (old, incompatible) common-logging</span>
<span class="c1"># version, yipe; use the same version we use everywhere else:</span>
<span class="s1">'3rdparty/jvm/common-logging'</span><span class="p">,</span>
<span class="p">]</span>
<span class="p">)</span>
</pre></div>
<p><strong>If you notice a small number of transitive dependencies to exclude</strong>
Rather than mark the <code>jar</code> intransitive, you can <code>exclude</code> some
transitive dependencies from JVM targets:</p>
<div class="codehilite"><pre><span></span><span class="n">java_library</span><span class="p">(</span>
<span class="n">name</span> <span class="o">=</span> <span class="s1">'loadtest'</span><span class="p">,</span>
<span class="n">dependencies</span> <span class="o">=</span> <span class="p">[</span>
<span class="s1">'3rdparty/storm:storm'</span><span class="p">,</span>
<span class="p">],</span>
<span class="n">sources</span> <span class="o">=</span> <span class="p">[</span><span class="s1">'*.java'</span><span class="p">],</span>
<span class="n">excludes</span> <span class="o">=</span> <span class="p">[</span>
<span class="n">exclude</span><span class="p">(</span><span class="s1">'org.sonatype.sisu.inject'</span><span class="p">,</span> <span class="s1">'cglib'</span><span class="p">)</span>
<span class="p">]</span>
<span class="p">)</span>
</pre></div>
<h2 id="managing-transitive-dependencies">Managing Transitive Dependencies</h2>
<h3 id="the-problem">The Problem</h3>
<p>If you have jars that pull in many transitive dependencies, you probably
want to constrain which versions of those transitive dependencies you
pull in. This is valuable for:</p>
<ul>
<li>Security concerns (you may want to avoid artifacts with known
vulnerabilities, or you may only want to use particular jars which you
trust).</li>
<li>Predictable and consistent behavior across all projects in your
repository (described below).</li>
<li>Caching concerns/build times (described below).</li>
</ul>
<p>Otherwise, you may have some targets that end up being built with
version <code>1.2.3</code> of a transitive dependency, and others that get built with
<code>4.5.6</code> of that dependency. Worse, the <em>same target</em> might be built with
different versions of a transitive dependency depending on what other
targets happen to be part of the same pants invocation. To illustrate
this, consider the diagram below:</p>
<div>
<img alt="image" src="images/transitive-dependencies.png" style="display: block; max-height: 25ex; margin-left: auto; margin-right: auto;"/>
</div>
<p>Assume <code>foo</code> and <code>bar</code> are binary targets. If you build a binary of <code>foo</code>
with <code>./pants binary foo</code>, <code>foo</code> will be packaged with the <code>example</code> jar
in addition to its transitive dependencies, which will be resolved as the
<code>common</code> jar, version <code>1.2.3</code>.</p>
<p>Likewise, if you run <code>./pants binary bar</code>, it will be packaged with <code>demo</code>,
and the transitive dependencies of <code>demo</code>, which here is simply the <code>common</code>
jar version <code>4.5.6</code>.</p>
<p>However, if you run <code>./pants binary foo bar</code>, ivy will only resolve one
version of <code>common-1.2.3</code>, which most likely means that both <code>foo</code> and <code>bar</code>
will get <code>common</code> version <code>4.5.6</code> (because it is the more recent version).
This is a problem, because it may be that <code>common-4.5.6</code> is not compatible
with <code>3rdparty:example</code>, which will <em>break the <code>foo</code> binary at runtime</em>.</p>
<p>More subtly, if you have many intermediate <code>java_library</code> targets between
your <code>jvm_binaries</code> and your <code>jar_library</code> targets (which is normally the
case), simply changing which combination of <code>java_library</code> targets are in
the same <code>./pants</code> invocation may invalidate the cache and force Pants to
recompile them, even if their sources are unchanged. This is because they
may resolve different versions of their transitive jar dependencies than
the previous time they were compiled, which means their classpaths will be
different. Getting a different classpath causes a cache-miss, forcing a
recompile. In general recompiling when the classpath changes is the
correct thing to do, however this means that unstable transitive
dependencies will cause a lot of cache-thrashing. If you have a large
repository with a large amount of code, recompiles get expensive.</p>
<h3 id="possible-solutions">Possible Solutions</h3>
<p>There are a few ways to avoid or work around these problems. A simple method
is to use the <a href="http://ant.apache.org/ivy/history/2.4.0/settings/conflict-managers.html">strict ivy conflict manager</a>,
which will cause the jar resolution to fail with an error if it detects two
artifacts with conflicting versions. This has the advantage of forcing a dev
to be aware of (and make a decision about) conflicting versions.</p>
<p>You could also disable transitive jar resolution altogether, and explicitly
declare every dependency you need. This ensures that you have total control
over your external dependencies, but can be difficult to maintain.</p>
<p>The third option is using <code>managed_jar_dependencies</code>, to pin the versions of
the subset of your transitive dependencies that you care about.</p>
<h3 id="managed-jar-dependencies">Managed Jar Dependencies</h3>
<p>Maven handles this problem with the <code><dependencyManagement></code>
<a href="https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management">stanza</a>,
and Pants has similar functionality via the <code>managed_jar_dependencies</code> target.</p>
<p>You can set up your <code>3rdparty/BUILD</code> file like so:</p>
<div class="codehilite"><pre><span></span><span class="n">managed_jar_dependencies</span><span class="p">(</span><span class="n">name</span><span class="o">=</span><span class="s1">'management'</span><span class="p">,</span>
<span class="n">artifacts</span><span class="o">=</span><span class="p">[</span>
<span class="s1">':commons-io'</span><span class="p">,</span>
<span class="s1">':jersey-core'</span><span class="p">,</span>
<span class="p">],</span>
<span class="p">)</span>
<span class="n">jar_library</span><span class="p">(</span><span class="n">name</span><span class="o">=</span><span class="s1">'commons-io'</span><span class="p">,</span>
<span class="n">jars</span><span class="o">=</span><span class="p">[</span>
<span class="n">jar</span><span class="p">(</span><span class="s1">'commons-io'</span><span class="p">,</span> <span class="s1">'commons-io'</span><span class="p">,</span> <span class="s1">'2.5'</span><span class="p">),</span>
<span class="p">],</span>
<span class="p">)</span>
<span class="n">jar_library</span><span class="p">(</span><span class="n">name</span><span class="o">=</span><span class="s1">'jersey-core'</span><span class="p">,</span>
<span class="n">jars</span><span class="o">=</span><span class="p">[</span>
<span class="n">jar</span><span class="p">(</span><span class="s1">'com.sun.jersey'</span><span class="p">,</span> <span class="s1">'jersey-core'</span><span class="p">,</span> <span class="s1">'1.19.1'</span><span class="p">),</span>
<span class="p">],</span>
<span class="p">)</span>
</pre></div>
<p>And in <code>pants.toml</code>, add:</p>
<div class="codehilite"><pre><span></span><span class="k">[jar-dependency-management]</span>
<span class="na">default_target</span> <span class="o">=</span> <span class="s">"3rdparty:management"</span>
</pre></div>
<p>This will force all <code>jar_library</code> targets in your repository to use the
versions of <code>commons-io</code> and <code>jersey-core</code> referenced by the <code>management</code>
target. When resolving transitive dependencies, Pants will always choose
the versions "pinned" by the managed dependencies target.</p>
<p>If a <code>jar_library</code> omits the version for one of its <code>jar()</code>s, it will use
the version defined in <code>managed_jar_dependencies</code>. If a <code>jar()</code> defines a
version that <em>conflicts</em> with the version set in <code>managed_jar_dependencies</code>,
an error will be raised and the build will fail (though this behavior can
be modified via the <code>conflict_strategy</code> option).</p>
<p>This is a bit verbose, and entails a bit of duplicate code (you have to
mention <code>jersey-core</code> 3 times in the above example). You can use the
<code>managed_jar_libraries</code> target factory instead to make your <code>3rdparty/BUILD</code>
definitions more concise.</p>
<p>This example is equivalent to the one earlier, but using <code>managed_jar_libraries</code>
instead:</p>
<div class="codehilite"><pre><span></span><span class="n">managed_jar_libraries</span><span class="p">(</span><span class="n">name</span><span class="o">=</span><span class="s1">'management'</span><span class="p">,</span>
<span class="n">artifacts</span><span class="o">=</span><span class="p">[</span>
<span class="n">jar</span><span class="p">(</span><span class="s1">'commons-io'</span><span class="p">,</span> <span class="s1">'commons-io'</span><span class="p">,</span> <span class="s1">'2.5'</span><span class="p">),</span>
<span class="n">jar</span><span class="p">(</span><span class="s1">'com.sun.jersey'</span><span class="p">,</span> <span class="s1">'jersey-core'</span><span class="p">,</span> <span class="s1">'1.19.1'</span><span class="p">),</span>
<span class="p">],</span>
<span class="p">)</span>
</pre></div>
<p>This automatically generates <code>jar_library</code> targets for you, and makes a
<code>managed_jar_dependencies</code> target to reference them. (Note that you still
need to make the same change to pants.ini).</p>
<p>The generated library targets follow the naming convention
<code>org.name.classifier.ext</code>, where <code>classifier</code> and <code>ext</code> are omitted if they
are the default values.</p>
<p>So in the above example will generate two <code>jar_library</code> targets, called
<code>3rdparty:commons-io.commons-io</code> and <code>3rdparty:com.sun.jersey.jersey-core</code>.</p>
<p>The artifacts list of <code>managed_jar_libraries</code> can also accept target
addresses to already-existing <code>jar_libraries</code>, just like a normal
<code>managed_jar_dependences</code> target. In this case, <code>managed_jar_libraries</code>
will just use the referenced target, rather than generating a new one.</p>
<p>With Pants you can create <em>multiple</em> <code>managed_jar_dependencies</code>.
If you have more than one, for any particular <code>jar_library</code>, you can define
which <code>managed_jar_dependencies</code> it uses explicitly (rather than using the
default defined in <code>pants.ini</code>):</p>
<div class="codehilite"><pre><span></span><span class="n">jar_library</span><span class="p">(</span><span class="n">name</span><span class="o">=</span><span class="s1">'org.apache.hadoop-alternate'</span><span class="p">,</span>
<span class="n">jars</span><span class="o">=</span><span class="p">[</span>
<span class="n">jar</span><span class="p">(</span><span class="s1">'org.apache.hadoop'</span><span class="p">,</span> <span class="s1">'hadoop-common'</span><span class="p">,</span> <span class="s1">'2.7.0'</span><span class="p">),</span>
<span class="p">],</span>
<span class="n">managed_dependencies</span><span class="o">=</span><span class="s1">'3rdparty:management-alternate'</span><span class="p">,</span>
<span class="p">)</span>
</pre></div>
<p><a id="test_3rdparty_jvm_snapshot" pantsmark="test_3rdparty_jvm_snapshot"> </a></p>
<h2 id="using-a-snapshot-jvm-dependency">Using a SNAPSHOT JVM Dependency</h2>
<p>Sometimes your code depends on a buggy external JVM dependency. You
think you've fixed the external code, but want to test locally before
uploading it to make sure. To do this, in the <code>jar</code> dependency for the
artifact, specify the <code>url</code> attribute to point to the local file and
change the <code>rev</code>. If you are actively making changes to the dependency,
you can also use the <code>mutable</code> jar attribute to re-import the file each
time pants is run (otherwise, pants will cache it):</p>
<div class="codehilite"><pre><span></span><span class="n">jar_library</span><span class="p">(</span><span class="n">name</span><span class="o">=</span><span class="s1">'checkstyle'</span><span class="p">,</span>
<span class="n">jars</span> <span class="o">=</span> <span class="p">[</span>
<span class="n">jar</span><span class="p">(</span><span class="n">org</span><span class="o">=</span><span class="s1">'com.puppycrawl.tools'</span><span class="p">,</span> <span class="n">name</span><span class="o">=</span><span class="s1">'checkstyle'</span><span class="p">,</span> <span class="n">rev</span><span class="o">=</span><span class="s1">'5.5-SNAPSHOT'</span><span class="p">,</span>
<span class="n">url</span><span class="o">=</span><span class="s1">'file:///Users/pantsdev/Src/checkstyle/checkstyle.jar'</span><span class="p">,</span>
<span class="n">mutable</span><span class="o">=</span><span class="kc">True</span><span class="p">),</span>
<span class="p">],</span>
<span class="p">)</span>
</pre></div>
<h2 id="strict-dependencies">Strict Dependencies</h2>
<h3 id="what-is-strict_deps">What is strict_deps?</h3>
<p>Strict_deps is a feature of JVM targets which controls the dependencies
available on the compile classpath when that target is being compiled.</p>
<p>When compiling a JVM target with strict_deps disabled, all transitive
dependencies of that target are included on the compile classpath.</p>
<p>When compiling a JVM target with strict deps enabled, the compile classpath
is more restricted. Instead of containing all transitive dependencies, only
the direct dependencies and the targets exported by those dependencies are
included in the compile classpath.</p>
<p>Enabling strict_deps speeds up builds because it 1) reduces the work the
compiler has to do when searching for symbols, and 2) improves cache hit
rates by reducing the number of dependencies that contribute to a target's
cache keys. This works because most targets don't need their full transitive
dependencies available to compile. However, it does require you to be more
exact in writing down your dependencies.</p>
<h3 id="why-strict_deps">Why strict_deps?</h3>
<p>Depending on the shape of your build graph, use of strict_deps improves cache
hit rates and per-target compilation time (on the order of 10-20%).</p>
<h3 id="example">Example</h3>
<p>With strict_deps enabled, we can identified some gaps between what the
compiler expects on a classpath and what is actually available on the
classpath as specified in BUILD files.</p>
<p>Let's look at a simple example involving 3 targets A, B and C. B depends on A,
and C depends on B. Thus their dependency graph can be represented like this:
C->B->A. Their declarations in BUILD file are shown as below:</p>
<div class="codehilite"><pre><span></span><span class="n">scala_library</span><span class="p">(</span>
<span class="n">name</span><span class="o">=</span><span class="s1">'A'</span><span class="p">,</span>
<span class="n">source</span><span class="o">=</span><span class="p">[</span><span class="s1">'A.scala'</span><span class="p">],</span>
<span class="p">)</span>
<span class="n">scala_library</span><span class="p">(</span>
<span class="n">name</span><span class="o">=</span><span class="s1">'B'</span><span class="p">,</span>
<span class="n">source</span><span class="o">=</span><span class="p">[</span><span class="s1">'B.scala'</span><span class="p">],</span>
<span class="n">dependencies</span><span class="o">=</span><span class="p">[</span><span class="s1">':A'</span><span class="p">],</span>
<span class="p">)</span>
<span class="n">scala_library</span><span class="p">(</span>
<span class="n">name</span><span class="o">=</span><span class="s1">'C'</span><span class="p">,</span>
<span class="n">source</span><span class="o">=</span><span class="p">[</span><span class="s1">'C.scala'</span><span class="p">],</span>
<span class="n">dependencies</span><span class="o">=</span><span class="p">[</span><span class="s1">':B'</span><span class="p">],</span>
<span class="p">)</span>
</pre></div>
<p>If we compile C with strict_deps turned off, everything works fine, as all
transitive dependencies of C will be added to compile time classpaths.
However, the compilation may require additional dependencies if strict_deps
is turned on. With strict_deps=True, only B is in C's compile time classpath.
There are 2 cases for the failure.</p>
<ol>
<li>
<p>C directly uses APIs from A. This is obviously a mistake by author of C,
and the fix is simple, just add A to C's dependency list.</p>
</li>
<li>
<p>C does not use APIs from A, but compiler still wants A to be in C's
classpaths. This is tricky, as author of C may not even be aware of A. It's
hard for C's author to get the right dependency list in this case.</p>
</li>
</ol>
<p>People may wonder why the compiler asks for A to compile C in the first place.
There are a number of reasons for this, an example of which is that the java
compiler needs all transitively implemented interfaces to be on the classpath
so that it can resolve default method implementations.</p>
<h3 id="strict_deps-for-library-developers">Strict_deps for Library Developers</h3>
<p>The compile overhead of a library change for downstream targets when
strict_deps is enabled should be minimized to just the targets that
depend directly on the library target or depend on a target that exports
that target.</p>
<h4 id="invalidation">Invalidation</h4>
<p>This is a change from the current behavior where all downstream targets will
have their compile invalidated.</p>
<p>With strict_deps, a change to a library target will only invalidate the
compile artifacts of dependent targets if they have</p>
<ol>
<li>A direct dependency on the changed library target, or</li>
<li>A dependency on it via the export graph.</li>
</ol>
<p>Before, if a target depending on a library had an implicit dependency on a
transitive dependency of the library target it would just work. The transitive
dependency would end up on the dependent target’s compile classpath and that
target would compile happily. Strict deps removes that implicit transitivity,
which exposes undeclared dependencies.</p>
<p>This introduces two new sources of errors.</p>
<ol>
<li>When adding a new library dependency to a target, if the library dependency
requires some of its dependencies to be on the compile classpath, the compile
can fail if those dependencies don’t make it on the classpath. These errors
are a bit weird and will be confusing at first.</li>
<li>When a library target adds a new publicly visible dependency, targets that
depend on the library target will fail to compile with the same kind of error
message as 1.</li>
</ol>
<h3 id="errors-exports-and-missing-deps-suggest">Errors, Exports, and Missing-deps-suggest</h3>
<p>The errors sometimes have different messages, but usually in Scala they look
something like this:</p>
<div class="codehilite"><pre><span></span><span class="o">[</span>error<span class="o">]</span> <path-to-current-sources>/<Some-file>.scala:71:32: Symbol <span class="s1">'type</span>
<span class="s1"> <Some-type>'</span> is missing from the classpath.
<span class="o">[</span>error<span class="o">]</span> This symbol is required by <span class="s1">'<Some-other-type>.timeout'</span>.
<span class="o">[</span>error<span class="o">]</span> Make sure that <span class="nb">type</span> <Some-type>is in your classpath and check <span class="k">for</span>
conflicting dependencies with <span class="sb">`</span>-Ylog-classpath<span class="sb">`</span>.
<span class="o">[</span>error<span class="o">]</span> A full rebuild may <span class="nb">help</span> <span class="k">if</span> <Some-other-type>.class was compiled
against an incompatible version of <none>.<Some-type>.
<span class="o">[</span>error<span class="o">]</span> Some-file.code
<span class="o">[</span>error<span class="o">]</span>
</pre></div>
<p><strong>NOTE: It's likely the source snippet may not be related to the error</strong></p>
<p>There are two possible solutions for this error. One is to identify the
dependency that is missing and add it to your target directly.</p>
<h4 id="missing-deps-suggest">Missing-deps-suggest</h4>
<p>Missing-deps-suggest is a feature that will try to identify the target that
failed to compile and suggest a dependency that may be missing.</p>
<p>If this doesn't provide a solution, then the second solution to this error
is exporting the missing type's target in the dependency you depend on.</p>
<h4 id="exports">Exports</h4>
<p>A target should export any dependencies which provide types or symbols that
are exposed in its public API. For instance, if target A has a method returning
something of type X, it should export the target which defines the type X.</p>
<p>Exports are transitive. This means that if a target exports one of its
dependencies and that exported dependency has exports, those exports will
also be end up on the classpath. This allows the export graph to model
requirements created by type hierarchies.</p>
<h4 id="how-to-solve-an-error-with-exports">How to Solve An Error With Exports</h4>
<p>Let's look at an example failure:</p>
<div class="codehilite"><pre><span></span><span class="o">[</span><span class="m">1</span>/1<span class="o">]</span> Compiling <span class="m">1</span> zinc <span class="nb">source</span> in <span class="m">1</span> target <span class="o">(</span>examples/src/scala/org/pantsbuild/example/strictdeps:h<span class="o">)</span>.
<span class="m">17</span>:12:58 <span class="m">00</span>:03 <span class="o">[</span>compile<span class="o">]</span>
<span class="m">17</span>:12:58 <span class="m">00</span>:03 <span class="o">[</span>zinc<span class="o">]</span>
<span class="o">[</span>error<span class="o">]</span> Symbol <span class="s1">'type z.Z'</span> is missing from the classpath.
<span class="o">[</span>error<span class="o">]</span> This symbol is required by <span class="s1">'method z.X.yyy'</span>.
<span class="o">[</span>error<span class="o">]</span> Make sure that <span class="nb">type</span> Z is in your classpath and
check <span class="k">for</span> conflicting dependencies with <span class="sb">`</span>-Ylog-classpath<span class="sb">`</span>.
<span class="o">[</span>error<span class="o">]</span> A full rebuild may <span class="nb">help</span> <span class="k">if</span> <span class="s1">'X.class'</span> was compiled
against an incompatible version of z.
<span class="o">[</span>error<span class="o">]</span> one error found
<span class="o">[</span>error<span class="o">]</span> Compile failed at Sep <span class="m">19</span>, <span class="m">2017</span> <span class="m">5</span>:12:59 PM <span class="o">[</span><span class="m">0</span>.916s<span class="o">]</span>
<span class="m">17</span>:12:59 <span class="m">00</span>:04 <span class="o">[</span>missing-deps-suggest<span class="o">]</span>
compile<span class="o">(</span>examples/src/scala/org/pantsbuild/example/strictdeps:h<span class="o">)</span> failed: Zinc compile failed.
FAILURE: Compilation failure: Failed jobs: compile<span class="o">(</span>examples/src/scala/org/pantsbuild/example/strictdeps:h<span class="o">)</span>
</pre></div>
<p>There are three targets that need to be identified to fix an error like this:</p>
<ol>
<li>the target that failed to compile.</li>
<li>the dependency of 1 that owns the type that needed the missing type</li>
<li>the dependency of target 2 that owns the missing type.</li>
</ol>
<p>Target 1 should be the most straight-forward to find. It's the target named in
the failure message as a failed job. It's mentioned both at the end of the
failing compile, in the line starting with <code>FAILURE: Compilation failure</code>,
and in a line near the error message. In this example, the failure is
<code>compile(examples/src/scala/org/pantsbuild/example/strictdeps:h)</code>. So, target
1 is <code>examples/src/scala/org/pantsbuild/example/strictdeps:h</code>.</p>
<p>Finding target 2 involves looking at target 1's dependencies and figuring out
which one contains the type from the error message. First, let's find the
type. In a message like this, target 2's type is the one that required the
missing type. In this message specifically, it's the following line:</p>
<div class="codehilite"><pre><span></span><span class="o">[</span>error<span class="o">]</span> This symbol is required by <span class="s1">'method z.X.yyy'</span>.
</pre></div>
<p>The type from target 2 is the method <code>yyy</code> on <code>z.X</code>. How to we find
the target for that type? One way would be to eyeball it. Let's look at the
BUILD file.</p>
<div class="codehilite"><pre><span></span><span class="n">scala_library</span><span class="p">(</span>
<span class="n">name</span><span class="o">=</span><span class="s1">'h'</span><span class="p">,</span>
<span class="n">sources</span><span class="o">=</span><span class="p">[</span><span class="s1">'H.scala'</span><span class="p">],</span>
<span class="n">dependencies</span><span class="o">=</span><span class="p">[</span><span class="s1">':x'</span><span class="p">],</span>
<span class="n">strict_deps</span><span class="o">=</span><span class="kc">True</span>
<span class="p">)</span>
</pre></div>
<p>In this example, target 1 only has one dependency, <code>x</code>. That makes finding
target 2 easy. It's <code>:x</code>.</p>
<p>Now that we know target 1 and target 2, let's find 3. Since we're doing this
manually, we'll look at the build files again.</p>
<p>Here's target 2's BUILD file declaration:</p>
<div class="codehilite"><pre><span></span><span class="n">scala_library</span><span class="p">(</span>
<span class="n">name</span><span class="o">=</span><span class="s1">'x'</span><span class="p">,</span>
<span class="n">sources</span><span class="o">=</span><span class="p">[</span><span class="s1">'X.scala'</span><span class="p">],</span>
<span class="n">dependencies</span><span class="o">=</span><span class="p">[</span><span class="s1">':z'</span><span class="p">]</span>
<span class="p">)</span>
</pre></div>
<p>It too has only one dependency, so we know what Target 3 is. It's <code>:z</code>.</p>
<p>Now that we know what the missing dependency is, we can fix the error.
Z has to be on the classpath in order to use X, so any target depending
on <code>:x</code> will also need <code>:z</code>. We could just add a dependency on :z to :h, but
doing so would result in new users of <code>:x</code> running into this same error. To
prevent that, let's add an export to <code>:x</code> of <code>:z</code>.</p>
<div class="codehilite"><pre><span></span><span class="n">scala_library</span><span class="p">(</span>
<span class="n">name</span><span class="o">=</span><span class="s1">'x'</span><span class="p">,</span>
<span class="n">sources</span><span class="o">=</span><span class="p">[</span><span class="s1">'X.scala'</span><span class="p">],</span>
<span class="n">dependencies</span><span class="o">=</span><span class="p">[</span><span class="s1">':z'</span><span class="p">],</span>
<span class="n">exports</span><span class="o">=</span><span class="p">[</span><span class="s1">':z'</span><span class="p">]</span>
<span class="p">)</span>
</pre></div>
<p>Now our target compiles successfully.</p>
<!-- main content end -->
<div class="generated">
Generated by <a href="docs.html">publish_docs</a>
from dist/markdown/html/examples/src/java/org/pantsbuild/example/3rdparty_jvm.html 2022-12-03T01:08:59.336911
</div>
</div> <!-- mainflow -->
</div> <!-- content -->
</div>
<div class="col-md-1">
</div>
</div> <!-- row -->
</div> <!-- container-fluid -->
</div> <!-- page -->
<script src="https://code.jquery.com/jquery-2.2.3.min.js" integrity="sha384-I6F5OKECLVtK/BL+8iSLDEHowSAfUo76ZL9+kGAgTRdiByINKJaqTPH/QVNS1VDb" crossorigin="anonymous"></script>
<script src="bootstrap-custom.min.js"></script>
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-78111411-1', 'auto');
ga('send', 'pageview');
</script>
</body>
</html>