allthingssecurity opened a new pull request, #28787:
URL: https://github.com/apache/camel/pull/28787

   # Description
   
   [CAMEL-26438](https://issues.apache.org/jira/browse/CAMEL-26438)
   
   The five fake worlds of the deterministic simulation tests (camel-aws2-sqs 
`SqsWorld`, camel-azure-eventhubs `EventHubsWorld`, camel-kafka-share 
`KafkaShareWorld`, camel-pulsar `PulsarWorld`, camel-slack `SlackWorld`) were 
listed only in a hand-written table in `test-dst.adoc`. Tools (the MCP server, 
an AI agent asked to test a consumer) could not find out which components have 
a world, what it simulates, or which have none yet. As discussed on Zulip, this 
PR marks each world with an annotation and lists the worlds in the catalog, 
generated and checked like the rest of the catalog.
   
   This is the first step of the JIRA. The MCP tool that lists the worlds and a 
generated section on each component page are later PRs.
   
   One difference from the JIRA text: the annotation has `invariants` (an 
array, named as in `dst.check(...)`) instead of one `invariant`, because four 
of the five worlds check several invariants.
   
   ## Changes
   
   - **`@DstWorld`** (camel-test-dst, `org.apache.camel.test.dst`, `@since 
4.24`): `component` (the scheme), `fake`, `covers`, `faults`, `invariants`, 
`issues`. Retention `SOURCE`: the worlds are test classes, which are not 
compiled when the component JSON is generated (and not at all with 
`-Dmaven.test.skip`), so the plugin reads the source.
   - **The 5 worlds are annotated.** The faults and invariants are the ones 
each world injects and checks (the invariant names are those of its 
`dst.check(...)`); the issues are the issue that added the world, the bugs it 
is a regression test for and the bugs it found.
   - **camel-package-maven-plugin**
     - `generate-endpoint-schema` (`EndpointSchemaGeneratorMojo`) reads the 
`@DstWorld` classes of the module's test sources with Roaster 
(`DstWorldsHelper`) and writes a `dstWorlds` section into the JSON of the 
component the world names. It adds the DST tests of the world's package that 
use it (`tests`: the classes of the same package with a `@DstTest` method that 
name the world). The values must be string literals or `+` concatenations of 
them (a small literal parser, as Roaster does not join concatenations).
     - The build fails, rather than leave a world out of the catalog, for: a 
value that is not a string literal, an empty `component` or `fake`, a file that 
cannot be parsed, or `@DstWorld` on something else than the top-level class of 
its file (a record, interface, enum, nested or second class) (these name the 
file); two worlds with the same simple name in one module; and a `component` 
that is not a scheme of the module, also in a module whose main code has no 
component (these name the world class). A file that only mentions `@DstWorld` 
in a comment or a string is skipped: the parsed types decide.
     - The JSON of a module without `@DstWorld` does not change. The goal now 
reads the module's test sources (as bytes, so a test file in another encoding 
does not matter), and Roaster parses only the files that contain `@DstWorld` 
and refer to the package of camel-test-dst. The up-to-date check of the 
`generate` goal now includes the test sources, so editing only a world 
regenerates the JSON without a clean build (editing a test also runs the 
generation again).
     - New goal `update-dst-worlds-doc` (`UpdateDstWorldsDocMojo`), run by 
camel-catalog after `prepare-catalog`: generates the table of worlds in 
`test-dst.adoc` (between `// dst worlds: START/END`) and in its catalog copy 
from the `dstWorlds` sections of the catalog's component JSON. A page without 
the markers fails the build.
   - **camel-tooling-model:** `DstWorldModel`, `ComponentModel.getDstWorlds()`, 
and `JsonMapper` reads and writes the section (after the options, one line per 
world; nothing is written for a component without worlds).
   - **Generated:** the JSON of the 5 components and their catalog copies (only 
the new `dstWorlds` section), `test-dst.adoc` and its catalog copy.
   - **Docs:** `test-dst.adoc`: the generated table replaces the hand-written 
one (component, world and its tests, fake, what it covers, issues), a step 10 
"Describe the world with @DstWorld" in the guide, a checklist line and the 
class table; "Running the tests" now runs all 5 worlds and names the past fix 
and the system properties of each world; `camel-catalog.adoc`: a section on the 
`dstWorlds` section and `ComponentModel.getDstWorlds()`.
   - No upgrade guide entry: a new optional section of the catalog, and 
camel-test-dst is new in 4.24.
   
   ## Follow-ups (later PRs of CAMEL-26438)
   
   - an MCP tool in camel-jbang-mcp that lists the worlds and the consumers 
without one, and `CatalogDocs` returning `dstWorlds` as it does `bodyTypes`;
   - a short generated section on each component page that has a world (what it 
covers, how to run it with a seed);
   - maybe a `limits` member for what a world does not cover (for example the 
Pulsar world runs only with `messageListener=true`), if the tools need it.
   
   ## Tests
   
   - `JsonMapperTest.testShouldReadAndWriteDstWorlds`: no section without 
worlds; the section is written after the options and read back the same.
   - `DstWorldsHelperTest` (8): the literal parser (concatenations, arrays with 
a trailing comma, escapes; constants, text blocks and method calls refused); a 
world with its tests found in a test source tree, with a class that only 
mentions `DstWorld`, an annotation of another package and a test of another 
world left out; sorting; the build errors above (including a world on a record, 
an interface, an enum and a nested class, and a file Roaster cannot parse); a 
Latin-1 test file, a directory named like a source, the same root twice and 
four files that only mention `@DstWorld` (javadoc with a wildcard import, a 
comment with the full name, a javadoc in the package of camel-test-dst, a 
string) do not fail; the mojo adds the worlds of its scheme only, and fails for 
a world of a scheme the module does not have and for a world in a module 
without components.
   - `UpdateDstWorldsDocMojoTest` (2): the table rendered from catalog JSON 
(sorted, `|` escaped, line breaks joined into one line, worlds without tests or 
covers), the markers replaced, a page without markers refused.
   - `CamelCatalogDstWorldsTest` (camel-catalog, 7): each of the 5 components 
has its world with its tests in the catalog, the SQS world's details, and the 
generated table of `test-dst.adoc` lists exactly the worlds of the catalog.
   - Negative control: without the annotation on `SlackWorld`, the build 
regenerates `slack.json` without the section (as on main) and 
`CamelCatalogDstWorldsTest` fails for slack.
   - The DST tests of the 5 worlds still pass (6 classes: SQS visibility 1000 
and redelivery 500 seeds, Event Hubs 1002, Kafka share 1000, Pulsar 1001, Slack 
1000), as do the camel-test-dst self tests and 
`EndpointSchemaGeneratorMojoTest`.
   
   _Claude Code on behalf of allthingssecurity_
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to