-
Notifications
You must be signed in to change notification settings - Fork 129
Expand file tree
/
Copy pathpom.xml
More file actions
1316 lines (1310 loc) · 70.1 KB
/
Copy pathpom.xml
File metadata and controls
1316 lines (1310 loc) · 70.1 KB
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
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"
xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<groupId>ai.labs</groupId>
<artifactId>eddi</artifactId>
<version>6.6.0</version>
<properties>
<compiler-plugin.version>3.16.0</compiler-plugin.version>
<maven.compiler.source>25</maven.compiler.source>
<maven.compiler.target>25</maven.compiler.target>
<maven.compiler.release>25</maven.compiler.release>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<quarkus.platform.artifact-id>quarkus-bom</quarkus.platform.artifact-id>
<quarkus.platform.group-id>io.quarkus.platform</quarkus.platform.group-id>
<quarkus.platform.version>3.40.1</quarkus.platform.version>
<!-- langchain4j ships two release lines from the same reactor. Every
dev.langchain4j artifact below is pinned to ONE of these two, and
they must be bumped together: a split leaves modules resolving
different langchain4j-core versions, which surfaces as a runtime
NoSuchMethodError rather than a build failure. There used to be four
properties for these two values (langchain4j-libs.version and
langchain4j-community.version were byte-identical duplicates of
langchain4j.version and langchain4j-beta.version), which made a
half-finished bump the likely outcome of any upgrade. -->
<langchain4j.version>1.20.2</langchain4j.version>
<langchain4j-beta.version>1.20.2-beta30</langchain4j-beta.version>
<!-- langchain4j-community-oci-genai is published on its own schedule: its newest release is
1.20.0-beta30, with no 1.20.2-beta30. Pinned separately so the rest of the beta line can
move; a patch-level core difference is binary compatible. Rejoin the beta property when
the module catches up. -->
<langchain4j-community-oci.version>1.20.0-beta30</langchain4j-community-oci.version>
<jandex-maven-plugin.version>3.6.0</jandex-maven-plugin.version>
<maven.compiler.parameters>true</maven.compiler.parameters>
<surefire-plugin.version>3.6.0</surefire-plugin.version>
<failsafe-plugin.version>3.6.0</failsafe-plugin.version>
<failsafe.useModulePath>false</failsafe.useModulePath>
<quarkus-mcp-server.version>2.0.1</quarkus-mcp-server.version>
<skipITs>true</skipITs>
<!-- skipUTs skips surefire alone, so CI's Integration Tests job can reuse the
unit-test coverage data Build & Test already produced (target/jacoco.exec)
instead of running ~20k unit tests a second time before the merged
coverage gate. It follows skipTests, so -DskipTests still skips both. -->
<skipTests>false</skipTests>
<skipUTs>${skipTests}</skipUTs>
<!-- The Manager and Chat UIs (ui/manager, ui/chat) are built by Maven in
prepare-package and copied into target/classes just before the jar is
assembled. compile, test and quarkus:dev therefore never run npm, while
package, verify and install always build both UIs unless -DskipUi=true.
CI's Build Image job is the build that ships them. -->
<skipUi>false</skipUi>
<!-- 2.x needs Java 17 and Maven 3.6 (both far below this build) and changes no
goal or parameter we use; 2.0.0 also fixed archive extraction on Windows
under Java 25. Since 2.0.2 everything npm and Vite write to stderr is logged
as [ERROR] - their warnings included - so read BUILD SUCCESS/FAILURE, not
the [ERROR] count. -->
<frontend-maven-plugin.version>2.0.2</frontend-maven-plugin.version>
<!-- Node 24 (LTS "Krypton") matches CI (ci.yml NODE_VERSION) and mise.toml;
change all three together, and ci.yml's NODE_SHA256_LINUX_X64 with them. Node 24 is LTS until 2028-04-30,
Node 22 only until 2027-04-30. The UIs' own floor is lower - 22.18: Vitest 5
needs 22.12, and Stryker 10's Babel 8 declares `^22.18.0 || >=24.11.0` -
so a contributor still on Node 22 can run `npm run dev`.
frontend-maven-plugin checks no checksum on the archive it downloads. CI's
Build Image job (the build that ships) places and verifies it first against
NODE_SHA256_LINUX_X64 in ci.yml, whose NODE_VERSION must equal this value
(BuildQualityGatesTest). A local build, and src/main/docker/Dockerfile.demo, still
download it unverified and trust nodejs.org over TLS alone. -->
<node.version>v24.21.0</node.version>
<!-- Pinned: Maven only warns when a declared plugin carries no version, then
takes whatever its default lifecycle binding says, which moves with the
Maven wrapper. -->
<maven-resources-plugin.version>3.5.0</maven-resources-plugin.version>
<maven-clean-plugin.version>3.5.0</maven-clean-plugin.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>${quarkus.platform.group-id}</groupId>
<artifactId>${quarkus.platform.artifact-id}</artifactId>
<version>${quarkus.platform.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>io.github.classgraph</groupId>
<artifactId>classgraph</artifactId>
<version>4.8.196</version>
</dependency>
<!-- Override jinjava to fix CVE-2026-25526 (pulled by jlama-core via jlama) -->
<dependency>
<groupId>com.hubspot.jinjava</groupId>
<artifactId>jinjava</artifactId>
<version>2.8.4</version>
</dependency>
<!-- Override jackson-core to fix GHSA-r7wm-3cxj-wff9 (async parser DoS, <2.22.1).
Managed transitively by the Quarkus BOM at 2.22.0. Trivy blocks the image
push on this, so it must be overridden here rather than waiting for the BOM. -->
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-core</artifactId>
<version>2.22.3</version>
</dependency>
<!-- Override jackson-databind to fix GHSA-5gvw-p9qm-jgwh (@JsonView bypassed for
@JsonUnwrapped containers) and GHSA-5jmj-h7xm-6q6v (case-insensitive
deserialization bypasses per-property @JsonIgnoreProperties), both <2.22.1.
Managed by the Quarkus BOM at 2.22.0, same as jackson-core above. Neither is
reachable from our code — @JsonView is unused and every @JsonIgnoreProperties
is class-level ignoreUnknown — but OpenSSF Scorecard counts advisories
regardless of reachability. 2.22.3 also fixes CVE-2026-91776 and CVE-2026-91777
(TypeDeserializerBase._findDeserializer, @JsonIdentityInfo forward references),
which Trivy blocks on. -->
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.22.3</version>
</dependency>
<!-- Keep the two jackson-dataformat modules we declare on the same patch
as jackson-core/databind above. The Quarkus BOM manages the whole
Jackson family at 2.22.0; overriding only core and databind for the
advisories leaves csv and xml a patch behind their own core. -->
<dependency>
<groupId>com.fasterxml.jackson.dataformat</groupId>
<artifactId>jackson-dataformat-csv</artifactId>
<version>2.22.3</version>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.dataformat</groupId>
<artifactId>jackson-dataformat-xml</artifactId>
<version>2.22.3</version>
</dependency>
<!-- Override reactor-netty-http to fix CVE-2025-22227 (pulled by langchain4j-azure-open-ai).
Stay on the 1.2 line while Quarkus manages Netty 4.1 (4.1.138.Final in 3.39.5):
1.3.x is built against Netty 4.2 (Import-Package io.netty [4.2,5)) and its default
event loop needs io.netty.channel.MultiThreadIoEventLoopGroup, so the Azure client's
first request fails with NoClassDefFoundError. ReactorNettyNettyCompatibilityTest
creates that event loop. Move to 1.3 only together with a Quarkus on Netty 4.2. -->
<dependency>
<groupId>io.projectreactor.netty</groupId>
<artifactId>reactor-netty-http</artifactId>
<version>1.2.18</version>
</dependency>
<!-- Override postgresql to fix CVE-2026-42198 (SCRAM iteration count DoS, ≤42.7.10)
and CVE-2026-54291 (auth downgrade, ≤42.7.11).
Pulled by langchain4j-pgvector (42.7.7) and Quarkus BOM. -->
<dependency>
<groupId>org.postgresql</groupId>
<artifactId>postgresql</artifactId>
<version>42.7.13</version>
</dependency>
<!-- Override bcprov-lts8on to fix GHSA-mx76-r943-rf8g (native GCM chunking can throw
a bad-tag exception on decryption, 2.73.0–2.73.10). Pulled by io.nats:jnats at
2.73.10; jnats 2.26.1 still declares 2.73.10, so a bump of the parent does not
clear it and the version has to be pinned here. -->
<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bcprov-lts8on</artifactId>
<version>2.73.13</version>
</dependency>
<!-- swagger-annotations is a VERSION PIN, not a usage. No source imports
io.swagger.v3.oas.annotations, so the direct <dependency> was removed
from <dependencies> below — but the jar still ships, because
swagger-parser (which McpApiToolBuilder does use, via
io.swagger.v3.oas.models) drags it in transitively at 2.2.52. Dropping
the declaration outright would therefore not have removed the artifact
from target/quarkus-app/lib, the container image, the CycloneDX SBOM or
the Trivy scan; it would only have DOWNGRADED it two patch versions,
silently reversing the deliberate bump in aa6c48bf ("every safe
patch/minor before release"). Managing it here keeps the shipped version
exactly where that bump put it while removing the compile-scope
dependency nothing compiles against.
Pinned by BuildQualityGatesTest#swaggerAnnotationsKeepsItsShippedVersion. -->
<dependency>
<groupId>io.swagger.core.v3</groupId>
<artifactId>swagger-annotations</artifactId>
<version>2.2.55</version>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-container-image-docker</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-rest</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-rest-jackson</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-rest-client</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-rest-client-jackson</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-jackson</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-smallrye-openapi</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-smallrye-context-propagation</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-swagger-ui</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-arc</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-scheduler</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-smallrye-health</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-micrometer-registry-prometheus</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-opentelemetry</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-oidc</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-cache</artifactId>
</dependency>
<!-- Caffeine is used DIRECTLY (Caffeine.newBuilder()) by ten classes — the
cache factory, the prompt-snippet and global-variable caches, the model
registries, and the tool-assembly warning cache. It arrives transitively
via quarkus-cache -> quarkus-caffeine, so the build works today by
accident: a Quarkus upgrade that reshapes that extension's own
dependencies would break compilation in classes that never mention
Quarkus. Declared explicitly, version left to the Quarkus BOM so it
cannot drift from the one the extension expects. -->
<dependency>
<groupId>com.github.ben-manes.caffeine</groupId>
<artifactId>caffeine</artifactId>
</dependency>
<!-- Bean Validation (Jakarta Validation / Hibernate Validator). Enables
declarative constraints on JAX-RS request bodies so an invalid body is
rejected at the boundary with a field-level 400 instead of being carried
into the engine. Version is managed by the Quarkus BOM — do not pin. -->
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-hibernate-validator</artifactId>
</dependency>
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j</artifactId>
<version>${langchain4j.version}</version>
</dependency>
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-open-ai</artifactId>
<version>${langchain4j.version}</version>
</dependency>
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-anthropic</artifactId>
<version>${langchain4j.version}</version>
</dependency>
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-ollama</artifactId>
<version>${langchain4j.version}</version>
</dependency>
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-vertex-ai-gemini</artifactId>
<version>${langchain4j-beta.version}</version>
</dependency>
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-hugging-face</artifactId>
<version>${langchain4j-beta.version}</version>
</dependency>
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-google-ai-gemini</artifactId>
<version>${langchain4j.version}</version>
</dependency>
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-http-client-jdk</artifactId>
<version>${langchain4j.version}</version>
</dependency>
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-jlama</artifactId>
<version>${langchain4j-beta.version}</version>
</dependency>
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-mcp</artifactId>
<version>${langchain4j-beta.version}</version>
</dependency>
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-agentic-a2a</artifactId>
<version>${langchain4j-beta.version}</version>
</dependency>
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-pgvector</artifactId>
<version>${langchain4j-beta.version}</version>
</dependency>
<!-- LLM Provider Expansion: Mistral AI, Azure OpenAI, Amazon Bedrock, Oracle GenAI -->
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-mistral-ai</artifactId>
<version>${langchain4j.version}</version>
</dependency>
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-azure-open-ai</artifactId>
<version>${langchain4j.version}</version>
</dependency>
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-bedrock</artifactId>
<version>${langchain4j.version}</version>
</dependency>
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-community-oci-genai</artifactId>
<version>${langchain4j-community-oci.version}</version>
</dependency>
<!-- RAG Provider Expansion: additional embedding stores + models -->
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-mongodb-atlas</artifactId>
<version>${langchain4j-beta.version}</version>
</dependency>
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-elasticsearch</artifactId>
<version>${langchain4j-beta.version}</version>
<exclusions>
<!-- Exclude Jackson 3.x (tools.jackson namespace) to fix WS-2026-0003 / CVE-2026-29062.
Elasticsearch-java 9.x pulls jackson-core 3.0.0 which has a High-severity vuln.
The rest of EDDI uses com.fasterxml.jackson (2.x) managed by Quarkus BOM. -->
<exclusion>
<groupId>tools.jackson.core</groupId>
<artifactId>jackson-core</artifactId>
</exclusion>
<exclusion>
<groupId>tools.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</exclusion>
<exclusion>
<groupId>tools.jackson.core</groupId>
<artifactId>jackson-annotations</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-qdrant</artifactId>
<version>${langchain4j-beta.version}</version>
</dependency>
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-chroma</artifactId>
<version>${langchain4j-beta.version}</version>
</dependency>
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-cohere</artifactId>
<version>${langchain4j-beta.version}</version>
</dependency>
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-vertex-ai</artifactId>
<version>${langchain4j-beta.version}</version>
</dependency>
<dependency>
<groupId>org.apache.pdfbox</groupId>
<artifactId>pdfbox</artifactId>
<version>3.0.8</version>
</dependency>
<dependency>
<groupId>org.jsoup</groupId>
<artifactId>jsoup</artifactId>
<version>1.23.2</version>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.dataformat</groupId>
<artifactId>jackson-dataformat-csv</artifactId>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.dataformat</groupId>
<artifactId>jackson-dataformat-xml</artifactId>
</dependency>
<!-- YAML: ComposeStackTest and InfrastructureIT parse docker-compose*.yml
with YAMLMapper. quarkus-jackson does NOT ship the YAML module, so
without this the classpath entry arrives only through
json-schema-validator's transitive tree and an unrelated bump there
breaks the test compile. Version comes from the Quarkus BOM, like the
two modules above. -->
<dependency>
<groupId>com.fasterxml.jackson.dataformat</groupId>
<artifactId>jackson-dataformat-yaml</artifactId>
</dependency>
<dependency>
<groupId>de.undercouch</groupId>
<artifactId>bson4jackson</artifactId>
<version>2.18.0</version>
<exclusions>
<exclusion>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-core</artifactId>
</exclusion>
<exclusion>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-annotations</artifactId>
</exclusion>
<exclusion>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.github.victools</groupId>
<artifactId>jsonschema-generator</artifactId>
<version>4.38.0</version>
</dependency>
<dependency>
<groupId>com.github.victools</groupId>
<artifactId>jsonschema-module-jackson</artifactId>
<version>4.38.0</version>
</dependency>
<!-- JSON Schema VALIDATION (victools above only GENERATES schemas) — used
by the declarative shared-artifact validators (I17). -->
<dependency>
<groupId>com.networknt</groupId>
<artifactId>json-schema-validator</artifactId>
<version>1.5.9</version>
</dependency>
<dependency>
<groupId>jakarta.annotation</groupId>
<artifactId>jakarta.annotation-api</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-mongodb-client</artifactId>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>3.21.0</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>com.jayway.jsonpath</groupId>
<artifactId>json-path</artifactId>
<version>3.0.0</version>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-qute</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-vertx</artifactId>
</dependency>
<dependency>
<groupId>io.vertx</groupId>
<artifactId>vertx-web-client</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-junit</artifactId>
<scope>test</scope>
</dependency>
<!-- quarkus-jacoco: Quarkus-native JaCoCo instrumentation for @QuarkusTest ITs.
Writes coverage data from within the Quarkus classloader, avoiding the
Windows agent path quoting issue that breaks the standard JaCoCo agent approach. -->
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-jacoco</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>io.rest-assured</groupId>
<artifactId>rest-assured</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<scope>test</scope>
</dependency>
<!-- WireMock: embedded HTTP mock server for LlmTask and ApiCallsTask integration tests -->
<dependency>
<groupId>org.wiremock</groupId>
<artifactId>wiremock-standalone</artifactId>
<version>3.13.2</version>
<scope>test</scope>
</dependency>
<!-- Jazzer: coverage-guided fuzz testing for security-critical parsers -->
<dependency>
<groupId>com.code-intelligence</groupId>
<artifactId>jazzer-junit</artifactId>
<version>0.30.0</version>
<scope>test</scope>
</dependency>
<!-- Testcontainers: container-based integration testing for E2E agent tests.
Testcontainers 2 prefixes every module artifact with "testcontainers-".
Versions come from the Quarkus BOM, which manages the whole 2.x family,
so they cannot drift from the Testcontainers Quarkus Dev Services use. -->
<dependency>
<groupId>org.testcontainers</groupId>
<artifactId>testcontainers</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.testcontainers</groupId>
<artifactId>testcontainers-junit-jupiter</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.testcontainers</groupId>
<artifactId>testcontainers-mongodb</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.testcontainers</groupId>
<artifactId>testcontainers-postgresql</artifactId>
<scope>test</scope>
</dependency>
<!-- NATS JetStream client for async conversation processing (Phase 5) -->
<dependency>
<groupId>io.nats</groupId>
<artifactId>jnats</artifactId>
<version>2.26.3</version>
</dependency>
<!-- PostgreSQL JDBC driver + Agroal connection pool (Phase 6.31) -->
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-jdbc-postgresql</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-agroal</artifactId>
</dependency>
<!-- Phase 8a: Quarkus MCP Server — expose EDDI as MCP tool provider -->
<dependency>
<groupId>io.quarkiverse.mcp</groupId>
<artifactId>quarkus-mcp-server-http</artifactId>
<version>${quarkus-mcp-server.version}</version>
</dependency>
<!-- Phase 8a+: OpenAPI spec parser for create_api_agent MCP tool -->
<dependency>
<groupId>io.swagger.parser.v3</groupId>
<artifactId>swagger-parser</artifactId>
<version>2.1.48</version>
</dependency>
</dependencies>
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<excludes>
<!-- Generated by the UI build and copied from ui/*/dist by
copy-ui-bundles. A stale local copy of the old
deploy-to-local-eddi-repo script re-creates them here,
gitignored and so invisible in git status; without these
excludes the default resource copy would stage that STALE
bundle into target/classes. Keep this list identical to the
.gitignore block and the maven-clean-plugin fileset below. -->
<exclude>META-INF/resources/assets/**</exclude>
<exclude>META-INF/resources/manage.html</exclude>
<exclude>META-INF/resources/welcome.html</exclude>
<exclude>META-INF/resources/workforce.html</exclude>
<exclude>META-INF/resources/chat.html</exclude>
<exclude>META-INF/resources/scripts/js/chat-ui*.js</exclude>
<exclude>META-INF/resources/scripts/css/chat-ui*.css</exclude>
<exclude>META-INF/resources/mockServiceWorker.js</exclude>
<exclude>META-INF/resources/eddi-icon.ico</exclude>
<exclude>META-INF/resources/eddi-icon.svg</exclude>
<exclude>META-INF/resources/logo_eddi.png</exclude>
<exclude>META-INF/resources/fonts/**</exclude>
<exclude>META-INF/resources/img/**</exclude>
</excludes>
</resource>
<!-- The Platform Operator's provisioning revision, owned by the Manager
(ui/manager/src/lib/operator/operator-revision.json). Copied onto the
backend classpath on EVERY build, -DskipUi included, so
OperatorRevisionCheck can warn at startup when the deployed operator
predates the Manager this jar ships. One file, read by both halves. -->
<resource>
<directory>ui/manager/src/lib/operator</directory>
<targetPath>eddi-manager</targetPath>
<includes>
<include>operator-revision.json</include>
</includes>
</resource>
</resources>
<plugins>
<plugin>
<groupId>io.smallrye</groupId>
<artifactId>jandex-maven-plugin</artifactId>
<version>${jandex-maven-plugin.version}</version>
<executions>
<execution>
<id>make-index</id>
<goals>
<goal>jandex</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>${quarkus.platform.group-id}</groupId>
<artifactId>quarkus-maven-plugin</artifactId>
<version>${quarkus.platform.version}</version>
<extensions>true</extensions>
<executions>
<execution>
<goals>
<goal>build</goal>
<goal>generate-code</goal>
<goal>generate-code-tests</goal>
<goal>native-image-agent</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>${compiler-plugin.version}</version>
<configuration>
<compilerArgs>
<arg>-parameters</arg>
</compilerArgs>
</configuration>
</plugin>
<!-- Enforcer: ban Jackson 3.x (tools.jackson.*) from the dependency tree.
Prevents silent re-introduction via transitive dependencies (e.g. Elasticsearch). -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>3.6.3</version>
<executions>
<execution>
<id>ban-jackson3</id>
<goals><goal>enforce</goal></goals>
<configuration>
<rules>
<bannedDependencies>
<excludes>
<exclude>tools.jackson.core:*</exclude>
</excludes>
<message>Jackson 3.x (tools.jackson.*) is banned — use com.fasterxml.jackson (2.x) managed by Quarkus BOM.</message>
</bannedDependencies>
</rules>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>${surefire-plugin.version}</version>
<configuration>
<skipTests>${skipUTs}</skipTests>
<!-- @{argLine} preserves JaCoCo's injected agent arg.
The jdk.incubator.vector add-modules flag mirrors the container
image (src/main/docker/Dockerfile) and mise.toml, so the test JVM
is the same shape as production. JlamaRuntimeSupportTest asserts
the Vector API is actually reachable here, so dropping the flag
fails the build rather than silently un-testing Jlama's SIMD
path. -->
<argLine>@{argLine} -ea -XX:+EnableDynamicAgentLoading -Xshare:off --enable-native-access=ALL-UNNAMED --add-modules=jdk.incubator.vector</argLine>
<excludes>
<exclude>**/*IT.java</exclude>
</excludes>
<systemPropertyVariables>
<java.util.logging.manager>org.jboss.logmanager.LogManager</java.util.logging.manager>
<java.util.logging.config.file>${project.basedir}/src/test/resources/logging.properties</java.util.logging.config.file>
<!--suppress UnresolvedMavenProperty -->
<maven.home>${maven.home}</maven.home>
</systemPropertyVariables>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>${failsafe-plugin.version}</version>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
<configuration>
<includes>
<include>**/*IT.java</include>
</includes>
<!-- NOTE: @{argLine} for JaCoCo IT instrumentation is intentionally NOT added here.
On Windows, the JaCoCo agent path with backslashes breaks the Quarkus
FacadeClassLoader. CI (Linux) uses the quarkus-jacoco extension instead.
See ContainerBaseIT.java line 24 for details.
Note what that does NOT mean. Failsafe's argLine PARAMETER defaults to
the ${argLine} property, which both jacoco:prepare-agent-integration
and the Quarkus Maven extension populate. Omitting the element is
therefore not the same as running without the agent: the agent IS
there, and jacoco-it.exec IS produced for the merged coverage gate.
Declaring an explicit argLine element here replaces all of it at once,
dropping the JaCoCo IT agent, the add-opens/add-exports that Quarkus
injects, and the serialized app-model path (Quarkus prints a warning
saying so). So there is deliberately no argLine element here. The
Jlama Vector API flag lives on surefire only: ITs exercise the image
over HTTP, the image carries the flag in its own ENV, and no IT builds
a Jlama model in the test JVM, so adding it here would buy nothing and
cost the IT coverage data. -->
<!-- Kill the forked test process if it hasn't completed in 15 minutes.
Prevents CI from hanging indefinitely when Docker image builds
or container startup fails to propagate errors. -->
<forkedProcessTimeoutInSeconds>900</forkedProcessTimeoutInSeconds>
<!-- Retry container-startup failures once. Testcontainers ITs
can flake on CI runners due to Docker networking timing.
This gives one automatic retry before failing the build. -->
<rerunFailingTestsCount>1</rerunFailingTestsCount>
<systemPropertyVariables>
<native.image.path>${project.build.directory}/${project.build.finalName}-runner
</native.image.path>
<java.util.logging.manager>org.jboss.logmanager.LogManager</java.util.logging.manager>
<!--suppress UnresolvedMavenProperty -->
<maven.home>${maven.home}</maven.home>
</systemPropertyVariables>
</configuration>
</plugin>
<!-- Checkstyle: code style enforcement.
failOnViolation was false, which made the whole ruleset decorative:
`mvn validate` reported violations and exited 0, so the import rules
AGENTS.md calls mandatory could never block anything, and dead imports
reached main. It fails now, but only on the rules the project actually
wants enforced: violationSeverity=error means only the checkstyle.xml
modules marked severity="error" (UnusedImports, RedundantImport) break
the build, while the aspirational ones (FileLength, LineLength) stay at
the Checker's default "warning" and remain advisory. -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>3.6.0</version>
<configuration>
<configLocation>checkstyle.xml</configLocation>
<consoleOutput>true</consoleOutput>
<!-- failOnViolation + violationSeverity IS the gate. `failsOnError`
is deliberately absent (its default is false): the plugin's own
descriptor for this goal reads "If this is true, and Checkstyle
reported any violations or errors, the build fails immediately
after running Checkstyle, before checking the log for
logViolationsToConsole. If you want to use logViolationsToConsole,
use failOnViolation instead of this." It is a second gate over the
SAME error-severity set, not a processing-error guard — it just
reaches the failure earlier and reports it worse ("Failed during
checkstyle execution: There are N checkstyle errors" instead of
"You have N Checkstyle violations"), and this build does want the
console log. Real processing errors are already fatal: Checkstyle's
Checker.haltOnException defaults to true, so an unparseable source
aborts the run whatever this flag says.
Pinned by BuildQualityGatesTest#checkstyleBlocksThroughFailOnViolation. -->
<failOnViolation>true</failOnViolation>
<violationSeverity>error</violationSeverity>
<!-- Scope, stated rather than defaulted: the blocking import rules
grade src/main/java ONLY. Turning this on today would fail the
build on 163 pre-existing unused imports in src/test/java, which
is a cleanup of its own and not something to smuggle into a
gate-wiring change; formatter:validate already covers both source
roots, so test sources are not unguarded, only un-Checkstyled.
AGENTS.md §4.7 says so in as many words, and
BuildQualityGatesTest#checkstyleImportGateScopeMatchesTheDocs
fails if this flag and that sentence ever disagree. -->
<includeTestSourceDirectory>false</includeTestSourceDirectory>
<linkXRef>false</linkXRef>
</configuration>
<executions>
<execution>
<?m2e ignore?>
<id>validate</id>
<phase>validate</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- Code Formatter.
Bound to `validate`, NOT `format`. The format goal defaults to the
process-sources phase, so it used to rewrite tracked source files on
every `mvn compile`/`test`/`package` — including files the developer
never touched, which then appear in `git status` next to the real work
(AGENTS.md rule 5 forbids `git add .` for exactly this reason). It also
meant formatting was "enforced" by mutating the working tree: CI
reformatted its own checkout and reported nothing, so unformatted code
could merge. `validate` checks and fails instead, and
`./mvnw formatter:format` — the command AGENTS.md documents — is still
how you fix a violation. -->
<plugin>
<groupId>net.revelc.code.formatter</groupId>
<artifactId>formatter-maven-plugin</artifactId>
<version>2.29.0</version>
<configuration>
<configFile>${project.basedir}/eclipse-formatter.xml</configFile>
<lineEnding>KEEP</lineEnding>
</configuration>
<executions>
<execution>
<id>validate</id>
<goals>
<goal>validate</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- JaCoCo: code coverage reporting -->
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.15</version>
<!-- Plugin-level excludes: applied to report AND check goals.
Excludes CDI bootstrap wiring, external integration adapters,
REST client libraries, and import/export services that require
a running Quarkus container (@QuarkusTest ITs cover these). -->
<configuration>
<excludes>
<!-- CDI bootstrap producers: @Produces methods that wire beans,
zero business logic, verified by container startup in @QuarkusTest ITs -->
<exclude>**/bootstrap/**</exclude>
<!-- Generated REST client wrappers (no logic, just JAX-RS proxy interfaces) -->
<exclude>**/runtime/client/**</exclude>
<!-- LLM provider SDK factory builders: each wraps a single external SDK
constructor call (e.g., OpenAI, Anthropic, Bedrock). No business logic,
cannot be tested without live API keys. -->
<exclude>**/llm/impl/builder/**</exclude>
<!-- Slack integration adapter: requires live Slack webhook API,
not testable without external service -->
<exclude>**/integrations/slack/**</exclude>
</excludes>
</configuration>
<executions>
<execution>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>report</id>
<phase>test</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
<!-- Instrument integration tests (Failsafe) -->
<execution>
<id>prepare-agent-integration</id>
<goals>
<goal>prepare-agent-integration</goal>
</goals>
</execution>
<!-- Merge IT-only data: failsafe agent + quarkus-jacoco extension.
@QuarkusTest ITs write to jacoco-quarkus.exec (not jacoco-it.exec),
so we merge both to get a complete IT-only picture. -->
<execution>
<id>merge-it</id>
<phase>post-integration-test</phase>
<goals>
<goal>merge</goal>
</goals>
<configuration>
<skip>${skipITs}</skip>
<fileSets>
<fileSet>
<directory>${project.build.directory}</directory>
<includes>
<include>jacoco-it.exec</include>
<include>jacoco-quarkus.exec</include>
</includes>
</fileSet>
</fileSets>
<destFile>${project.build.directory}/jacoco-it-all.exec</destFile>
</configuration>
</execution>
<execution>
<id>report-integration</id>
<phase>post-integration-test</phase>
<goals>
<goal>report</goal>
</goals>
<configuration>
<skip>${skipITs}</skip>
<dataFile>${project.build.directory}/jacoco-it-all.exec</dataFile>
<outputDirectory>${project.reporting.outputDirectory}/jacoco-it</outputDirectory>
</configuration>
</execution>
<!-- Merge UT + IT data files for combined coverage -->
<execution>
<id>merge</id>
<phase>post-integration-test</phase>
<goals>
<goal>merge</goal>
</goals>
<configuration>
<skip>${skipITs}</skip>
<fileSets>
<fileSet>
<directory>${project.build.directory}</directory>
<includes>
<include>jacoco.exec</include>
<include>jacoco-it.exec</include>
<include>jacoco-quarkus.exec</include>
</includes>
</fileSet>
</fileSets>
<destFile>${project.build.directory}/jacoco-merged.exec</destFile>
</configuration>
</execution>
<execution>
<id>merged-report</id>
<phase>post-integration-test</phase>
<goals>
<goal>report</goal>
</goals>
<configuration>
<skip>${skipITs}</skip>
<dataFile>${project.build.directory}/jacoco-merged.exec</dataFile>
<outputDirectory>${project.reporting.outputDirectory}/jacoco-merged</outputDirectory>
</configuration>
</execution>
<!-- Coverage gate (merged UT+IT): the single authoritative threshold.
Target: 90/80 for OpenSSF Gold.
Skipped together with the ITs, because jacoco-merged.exec is only
a merged file when the ITs ran. `mvn verify` defaults to
skipITs=true (see the property at the top of this file), which
left jacoco.exec as the sole input and graded unit-test-only
coverage against a threshold that assumes both suites — so a
clean tree with every test green failed the build at 89%. The
gate now runs exactly where the data it grades is produced: the
CI integration job, which passes -DskipITs=false. -->
<execution>
<id>merged-check</id>
<phase>verify</phase>
<goals>
<goal>check</goal>
</goals>
<configuration>
<skip>${skipITs}</skip>
<dataFile>${project.build.directory}/jacoco-merged.exec</dataFile>
<rules>
<rule>
<element>BUNDLE</element>
<limits>
<limit>
<counter>INSTRUCTION</counter>
<value>COVEREDRATIO</value>
<minimum>0.90</minimum>
</limit>
<limit>
<counter>BRANCH</counter>
<value>COVEREDRATIO</value>
<minimum>0.80</minimum>
</limit>
</limits>
</rule>
</rules>
</configuration>
</execution>
</executions>
</plugin>
<plugin>