os890 Maven repository

A plain Maven repository served as static files. It holds the released artifacts of cdi-flow and jawelte, so they can be used without building those projects first.

Using it

Declare the repository once — no credentials, nothing in settings.xml:

<repositories>
    <repository>
        <id>os890</id>
        <url>https://os890.github.io/os890-maven-repo/</url>
    </repository>
</repositories>

<dependencies>
    <dependency>
        <groupId>org.os890.cdi.uml</groupId>
        <artifactId>dynamic-cdi-flow-renderer</artifactId>
        <version>0.9.0</version>
    </dependency>
</dependencies>

A <repositories> entry is not inherited through a dependency's POM, so a project needs the entry above in its own POM — including when it only reaches these artifacts transitively.

cdi-flow

github.com/os890/dynamic-cdi-flow-renderer — groupId org.os890.cdi.uml, released at 0.9.0.

Artifact	For
`dynamic-cdi-flow-renderer`	the addon — a portable CDI extension, for Weld, OpenWebBeans or a Jakarta EE server
`cdi-flow-quarkus`	the Quarkus extension: one dependency, and an application records its use-cases
`cdi-flow-jaxrs`	the request-filter reading the use-case a caller names in a header
`cdi-flow-lite`	the build compatible extension, for a CDI-Lite container

Sources- and javadoc-jars sit alongside each one. On Quarkus it is cdi-flow-quarkus instead, and that one dependency is the whole integration. Browse the tree in the repository it is served from — these pages are static files, so there are no directory listings here.

jawelte

github.com/os890/jawelte — groupId org.os890.jawelte, released at 0.1.0.

A Jakarta-based integration-test framework. A test class boots a real CDI SE container, and each integration is opt-in: putting a module on the test class-path is what activates it.

Most modules come as an -api and an -impl artifact — the api carries the annotations and the ports, the impl the adapters. Depending on the -impl is enough; it brings its -api along. The baseline is the core plus the CDI adapter, next to a CDI SE runtime of your choice — OpenWebBeans or Weld:

<dependency>
    <groupId>org.os890.jawelte</groupId>
    <artifactId>jawelte-core-impl</artifactId>
    <version>0.1.0</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.os890.jawelte</groupId>
    <artifactId>jawelte-cdi-module-impl</artifactId>
    <version>0.1.0</version>
    <scope>test</scope>
</dependency>

On top of that, whichever modules the test needs:

Module	For
`jawelte-cdi-module`	the CDI SE adapter — boots the per-test-class container, `@TestBean` mocks, the class-filter ports
`jawelte-scope-module`	the test-lifecycle scopes `@TestMethodScoped` / `@TestClassScoped`
`jawelte-jpa-module`	managed persistence context, `@PersistenceConfig`, `@ReadOnly`, the transaction- and cleanup-strategy SPIs
`jawelte-jta-module`	JTA-backed transactions, with Geronimo or Narayana behind the `TransactionManagerProvider` port
`jawelte-ejb-module`	maps `@jakarta.ejb.Singleton` / `@jakarta.ejb.Stateless` onto CDI scopes plus an implicit `@Transactional`
`jawelte-jaxrs-module`	an embedded Jakarta REST 4.0 `SeBootstrap` container for testing endpoints
`jawelte-batch-module`	Jakarta Batch job execution, driven by CDI events with a pluggable timeout policy
`jawelte-spring-data-module`	discovers Spring Data repository interfaces on the test class-path and registers real repositories as CDI beans (a single jar — no api/impl split)
`jawelte-wiremock-module`	WireMock server lifecycle, `@EnableWireMock` and the `@WireMockEndpoint` qualifier
`jawelte-db-testdata-module`	fluent DB fixtures — `DbSeed` to load, `DbDiff` to verify
`jawelte-content-diff-module`	semantic diff for JSON and XML payloads: `ContentDiff.forJson(...)` / `forXml(...)`
`jawelte-testcontrol-module`	`@TestControl`, binding per-method scope filtering and database fixtures to one annotation
`jawelte-flow-assert-module`	records the CDI call-flow of a test method and asserts it against an expected sequence-diagram

jawelte-flow-assert-module-impl depends on dynamic-cdi-flow-renderer above, so the recorder arrives with the module — both come from here. Its module README describes what is compared and how the expected diagrams are written.

Verifying a download

Maven checks the .sha1 beside each artifact as it resolves. That travels with the file it describes, so it catches a truncated download and nothing more; the SHA-256 digests published in cdi-flow's project README are the out-of-band check for its artifacts.