## Issue
Closes https://github.com/langchain4j/langchain4j/issues/3804
Closes https://github.com/langchain4j/langchain4j/issues/3320
## Change
- Integrate https://revapi.org/ (`revapi-maven-plugin`) into the build
to automatically detect breaking API changes
- Revapi runs during the `verify` phase on every build, comparing the
current code against the latest released version on Maven Central
(`RELEASE`)
- Suppress `java.method.varargOverloadsOnlyDifferInVarargParameter`
globally — this is a design warning about varargs overloads, not an
actual breaking change
- Add per-module `revapi.json` justifications for pre-existing
`java.class.nonPublicPartOfAPI` warnings in `langchain4j-ollama`,
`langchain4j-bedrock`, `langchain4j-onnx-scoring`, and
`langchain4j-google-ai-gemini` — these are package-private classes
exposed through protected members on package-private base classes, so
they cannot actually leak to external
users
- Do not check depndencies - we do not expose them explicitly and are
not responsible for any changes there
- skip `integration-tests` modules - we do not release them
### How it works
- Revapi downloads the latest released JAR from Maven Central and
compares it against the locally built JAR at the bytecode level
- Any removal, signature change, or visibility reduction of public API
elements will fail the build
- Adding new public API is always fine
- To justify an intentional breaking change, add a `revapi.json` in the
module root — justifications auto-expire on the next release since the
baseline moves forward
## General checklist
- [X] There are no breaking changes (API, behaviour)
- [X] I have added unit and/or integration tests for my change
- [X] The tests cover both positive and negative cases
- [X] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
- [X] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green
- [ ] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features)
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable)
Guardrails support.
I also introduced a new `langchain4j-test` module which can be a future
place to put in some testing utilities. For now I have several
assertj-based assertion classes that can be used for asserting
guardrails. (see
https://docs.quarkiverse.io/quarkus-langchain4j/dev/guardrails.html#_unit_testing
for current details).
Additionally, I've introduced a new `integration-tests` where we can
build various sets of test suites (think things that use/need
`ServiceLoader`s). This way we can test various implementations of
things for frameworks that may extend LangChain4j (Quarkus, Spring,
etc).
I've tried to include as much "genericism" as I can into this so that
downstream frameworks can re-use this without having to re-implement.
I'll have @geoand / @cescoffier review this too before merging.
## To-do list
- [x] Initial scaffolding for being able to define guardrails
- [x] Guardrail testing utilities
- [x] Wire guardrails into `AiService`s via annotations
- [x] Wire guardrails into `AiService`s using the builder
- [x] Handle output guardrails on streaming responses
- [x] Lots of tests
- [x] Documentation
Fixes#2549
---------
Co-authored-by: Lize Raes <49833622+LizeRaes@users.noreply.github.com>
Co-authored-by: Dmytro Liubarskyi <ljubarskij@gmail.com>
github-actions[bot]