[
https://issues.apache.org/jira/browse/CAMEL-25668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luigi De Masi updated CAMEL-25668:
----------------------------------
Description:
h2. Purpose
Give the existing Semantic experts consistent, explicit artifact names while
keeping the TypeSafe AI component independently usable without a dependency on
camel-semantic.
This task covers two different packaging changes:
* Extract the TypeSafe AI semantic adapter from camel-typesafe-ai into a new
camel-semantic-typesafe-ai module.
* Rename the existing camel-wolf-defender module/artifact to
camel-semantic-wolf-defender. Wolf Defender is already a Semantic expert
module, with its local inference implementation and supporting exception; it
has no separate Camel routing endpoint. This is a module rename, not an
adapter/backend split.
h2. TypeSafe AI: extract the adapter
* Add components/camel-ai/camel-semantic-typesafe-ai, depending on
camel-semantic and camel-typesafe-ai.
* Move TypeSafeAiSemanticAdapter and the applicable Semantic-specific tests to
the new module.
* Keep the component, endpoints, producer, client configuration and managed
transport in camel-typesafe-ai. Reuse that transport from the extracted adapter.
* Remove camel-typesafe-ai's dependency on camel-semantic. Do not introduce a
reverse dependency from the component to the new adapter module.
* Preserve existing operations, accepted inputs, parameters, batching, typed
results, provider uncertainty, exceptions and lifecycle behavior.
h2. Wolf Defender: rename the module
* Rename components/camel-ai/camel-wolf-defender and its Maven artifact to
camel-semantic-wolf-defender.
* Keep the adapter, inference implementation, supporting exception and tests
together. Preserve their Java packages and class names; no inference API
extraction or new routing component is required.
* Keep the existing model provisioning, native dependencies, resource limits,
concurrency, lifecycle, failure behavior and expert semantics unchanged.
h2. Explicit input validation
* Validate the input shapes and modalities accepted by each expert before
provider requests or local inference, including direct adapter calls and
batches.
* TypeSafe AI accepts text and its supported structured application state
(String, Map and List). Wolf Defender accepts text only, subject to its
existing nonblank, character and token limits.
* Reject unsupported images, audio, video, binary objects and explicit media
parts with clear validation exceptions. Do not stringify unsupported inputs,
silently remove parts or invoke preprocessing/fallback services. A structured
wrapper must not bypass the checks for explicit media content.
* Apply the applicable validation at the TypeSafe provider/component boundary
as well as its Semantic adapter boundary, without introducing a dependency from
camel-typesafe-ai to camel-semantic. Do not require shared Semantic media
classes in the provider component.
* Preserve legitimate structured state and ordinary textual content; do not
infer a media modality merely from arbitrary user text or field names.
* Add positive tests for each supported input shape and negative tests showing
rejection before HTTP/model invocation, including a batch with an invalid
input. Document any newly enforced rejection of previously accepted unsupported
values in the upgrade guide.
h2. Build, metadata and migration
* Update reactor modules, dependency management/BOM entries, relevant
dependency declarations, generated catalog metadata and documentation mirrors.
* Update expert artifact identity to the module that contains each adapter,
preserving provider identity and operation meaning.
* Update documentation, examples and applicable Camel JBang dependency
resolution/usage references to use the new artifacts. Preserve explicit named
expert selection and the existing runtime metadata/tooling contract.
* Document the migration in the appropriate upgrade guide: TypeSafe Semantic
users add camel-semantic-typesafe-ai; direct TypeSafe component users continue
using camel-typesafe-ai; Wolf Defender users replace camel-wolf-defender with
camel-semantic-wolf-defender.
* Preserve existing Java adapter class names where practical. Document any
necessary TypeSafe bean-class or import changes explicitly rather than silently
changing route behavior.
h2. Acceptance criteria
# camel-typesafe-ai can build and execute its component functionality without
camel-semantic or camel-semantic-typesafe-ai on the application's classpath.
# camel-semantic-typesafe-ai supplies the existing TypeSafe expert using the
component's configured transport, including custom endpoint/client settings and
batching.
# camel-semantic-wolf-defender supplies the same Wolf Defender expert and local
inference implementation under the renamed artifact, without introducing a
separate backend module or changing the Java API.
# Dependency graphs are acyclic, and the provider component does not depend on
its Semantic adapter module.
# Existing Semantic behavior remains covered by the moved/adapted tests:
explicit registry references, capability inspection, supported inputs and
operations, result types and probabilities, validation, exceptions and service
lifecycle. Metadata inspection must not load the Wolf model or perform
inference.
# Relevant Java/XML/YAML examples and Camel JBang usage resolve the new
artifacts. Existing audit/result rendering continues to use the common Semantic
contracts.
# Build metadata, generated artifacts, documentation and upgrade guidance
consistently reflect the new artifact names.
# Invalid or unsupported inputs fail before provider/model invocation for both
experts, with regression tests for supported text/structured inputs and
rejected media.
h2. Scope boundary
The OpenAI Decisions integration and camel-semantic-openai belong in a separate
issue. This refactoring does not add OpenAI support, multimodal inputs, image
audit rendering, a Semantic API/runtime split, or new inference behavior.
h2. References
* [TypeSafe AI module at the merged Semantic
baseline|https://github.com/apache/camel/tree/12e8bdcdf1affa19b3d62786d4a4001db936b164/components/camel-ai/camel-typesafe-ai]
* [Wolf Defender module at the same
baseline|https://github.com/apache/camel/tree/12e8bdcdf1affa19b3d62786d4a4001db936b164/components/camel-ai/camel-wolf-defender]
* [Merged explicit-expert and audit changes, PR
27791|https://github.com/apache/camel/pull/27791]
_AI-generated by Codex on behalf of luigidemasi (Luigi De Masi)._
was:
h2. Purpose
Give the existing Semantic experts consistent, explicit artifact names while
keeping the TypeSafe AI component independently usable without a dependency on
camel-semantic.
This task covers two different packaging changes:
* Extract the TypeSafe AI semantic adapter from camel-typesafe-ai into a new
camel-semantic-typesafe-ai module.
* Rename the existing camel-wolf-defender module/artifact to
camel-semantic-wolf-defender. Wolf Defender is already a Semantic expert
module, with its local inference implementation and supporting exception; it
has no separate Camel routing endpoint. This is a module rename, not an
adapter/backend split.
h2. TypeSafe AI: extract the adapter
* Add components/camel-ai/camel-semantic-typesafe-ai, depending on
camel-semantic and camel-typesafe-ai.
* Move TypeSafeAiSemanticAdapter and the applicable Semantic-specific tests to
the new module.
* Keep the component, endpoints, producer, client configuration and managed
transport in camel-typesafe-ai. Reuse that transport from the extracted adapter.
* Remove camel-typesafe-ai's dependency on camel-semantic. Do not introduce a
reverse dependency from the component to the new adapter module.
* Preserve existing operations, accepted inputs, parameters, batching, typed
results, provider uncertainty, exceptions and lifecycle behavior.
h2. Wolf Defender: rename the module
* Rename components/camel-ai/camel-wolf-defender and its Maven artifact to
camel-semantic-wolf-defender.
* Keep the adapter, inference implementation, supporting exception and tests
together. Preserve their Java packages and class names; no inference API
extraction or new routing component is required.
* Keep the existing model provisioning, native dependencies, resource limits,
concurrency, lifecycle, failure behavior and expert semantics unchanged.
h2. Build, metadata and migration
* Update reactor modules, dependency management/BOM entries, relevant
dependency declarations, generated catalog metadata and documentation mirrors.
* Update expert artifact identity to the module that contains each adapter,
preserving provider identity and operation meaning.
* Update documentation, examples and applicable Camel JBang dependency
resolution/usage references to use the new artifacts. Preserve explicit named
expert selection and the existing runtime metadata/tooling contract.
* Document the migration in the appropriate upgrade guide: TypeSafe Semantic
users add camel-semantic-typesafe-ai; direct TypeSafe component users continue
using camel-typesafe-ai; Wolf Defender users replace camel-wolf-defender with
camel-semantic-wolf-defender.
* Preserve existing Java adapter class names where practical. Document any
necessary TypeSafe bean-class or import changes explicitly rather than silently
changing route behavior.
h2. Acceptance criteria
# camel-typesafe-ai can build and execute its component functionality without
camel-semantic or camel-semantic-typesafe-ai on the application's classpath.
# camel-semantic-typesafe-ai supplies the existing TypeSafe expert using the
component's configured transport, including custom endpoint/client settings and
batching.
# camel-semantic-wolf-defender supplies the same Wolf Defender expert and local
inference implementation under the renamed artifact, without introducing a
separate backend module or changing the Java API.
# Dependency graphs are acyclic, and the provider component does not depend on
its Semantic adapter module.
# Existing Semantic behavior remains covered by the moved/adapted tests:
explicit registry references, capability inspection, supported inputs and
operations, result types and probabilities, validation, exceptions and service
lifecycle. Metadata inspection must not load the Wolf model or perform
inference.
# Relevant Java/XML/YAML examples and Camel JBang usage resolve the new
artifacts. Existing audit/result rendering continues to use the common Semantic
contracts.
# Build metadata, generated artifacts, documentation and upgrade guidance
consistently reflect the new artifact names.
h2. Scope boundary
The OpenAI Decisions integration and camel-semantic-openai belong in a separate
issue. This refactoring does not add OpenAI support, multimodal inputs, image
audit rendering, a Semantic API/runtime split, or new inference behavior.
h2. References
* [TypeSafe AI module at the merged Semantic
baseline|https://github.com/apache/camel/tree/12e8bdcdf1affa19b3d62786d4a4001db936b164/components/camel-ai/camel-typesafe-ai]
* [Wolf Defender module at the same
baseline|https://github.com/apache/camel/tree/12e8bdcdf1affa19b3d62786d4a4001db936b164/components/camel-ai/camel-wolf-defender]
* [Merged explicit-expert and audit changes, PR
27791|https://github.com/apache/camel/pull/27791]
_AI-generated by Codex on behalf of luigidemasi (Luigi De Masi)._
> camel-semantic: Extract TypeSafe adapter and rename Wolf Defender module
> ------------------------------------------------------------------------
>
> Key: CAMEL-25668
> URL: https://issues.apache.org/jira/browse/CAMEL-25668
> Project: Camel
> Issue Type: Task
> Components: camel-ai
> Reporter: Luigi De Masi
> Assignee: Luigi De Masi
> Priority: Major
>
> h2. Purpose
> Give the existing Semantic experts consistent, explicit artifact names while
> keeping the TypeSafe AI component independently usable without a dependency
> on camel-semantic.
> This task covers two different packaging changes:
> * Extract the TypeSafe AI semantic adapter from camel-typesafe-ai into a new
> camel-semantic-typesafe-ai module.
> * Rename the existing camel-wolf-defender module/artifact to
> camel-semantic-wolf-defender. Wolf Defender is already a Semantic expert
> module, with its local inference implementation and supporting exception; it
> has no separate Camel routing endpoint. This is a module rename, not an
> adapter/backend split.
> h2. TypeSafe AI: extract the adapter
> * Add components/camel-ai/camel-semantic-typesafe-ai, depending on
> camel-semantic and camel-typesafe-ai.
> * Move TypeSafeAiSemanticAdapter and the applicable Semantic-specific tests
> to the new module.
> * Keep the component, endpoints, producer, client configuration and managed
> transport in camel-typesafe-ai. Reuse that transport from the extracted
> adapter.
> * Remove camel-typesafe-ai's dependency on camel-semantic. Do not introduce a
> reverse dependency from the component to the new adapter module.
> * Preserve existing operations, accepted inputs, parameters, batching, typed
> results, provider uncertainty, exceptions and lifecycle behavior.
> h2. Wolf Defender: rename the module
> * Rename components/camel-ai/camel-wolf-defender and its Maven artifact to
> camel-semantic-wolf-defender.
> * Keep the adapter, inference implementation, supporting exception and tests
> together. Preserve their Java packages and class names; no inference API
> extraction or new routing component is required.
> * Keep the existing model provisioning, native dependencies, resource limits,
> concurrency, lifecycle, failure behavior and expert semantics unchanged.
> h2. Explicit input validation
> * Validate the input shapes and modalities accepted by each expert before
> provider requests or local inference, including direct adapter calls and
> batches.
> * TypeSafe AI accepts text and its supported structured application state
> (String, Map and List). Wolf Defender accepts text only, subject to its
> existing nonblank, character and token limits.
> * Reject unsupported images, audio, video, binary objects and explicit media
> parts with clear validation exceptions. Do not stringify unsupported inputs,
> silently remove parts or invoke preprocessing/fallback services. A structured
> wrapper must not bypass the checks for explicit media content.
> * Apply the applicable validation at the TypeSafe provider/component boundary
> as well as its Semantic adapter boundary, without introducing a dependency
> from camel-typesafe-ai to camel-semantic. Do not require shared Semantic
> media classes in the provider component.
> * Preserve legitimate structured state and ordinary textual content; do not
> infer a media modality merely from arbitrary user text or field names.
> * Add positive tests for each supported input shape and negative tests
> showing rejection before HTTP/model invocation, including a batch with an
> invalid input. Document any newly enforced rejection of previously accepted
> unsupported values in the upgrade guide.
> h2. Build, metadata and migration
> * Update reactor modules, dependency management/BOM entries, relevant
> dependency declarations, generated catalog metadata and documentation mirrors.
> * Update expert artifact identity to the module that contains each adapter,
> preserving provider identity and operation meaning.
> * Update documentation, examples and applicable Camel JBang dependency
> resolution/usage references to use the new artifacts. Preserve explicit named
> expert selection and the existing runtime metadata/tooling contract.
> * Document the migration in the appropriate upgrade guide: TypeSafe Semantic
> users add camel-semantic-typesafe-ai; direct TypeSafe component users
> continue using camel-typesafe-ai; Wolf Defender users replace
> camel-wolf-defender with camel-semantic-wolf-defender.
> * Preserve existing Java adapter class names where practical. Document any
> necessary TypeSafe bean-class or import changes explicitly rather than
> silently changing route behavior.
> h2. Acceptance criteria
> # camel-typesafe-ai can build and execute its component functionality without
> camel-semantic or camel-semantic-typesafe-ai on the application's classpath.
> # camel-semantic-typesafe-ai supplies the existing TypeSafe expert using the
> component's configured transport, including custom endpoint/client settings
> and batching.
> # camel-semantic-wolf-defender supplies the same Wolf Defender expert and
> local inference implementation under the renamed artifact, without
> introducing a separate backend module or changing the Java API.
> # Dependency graphs are acyclic, and the provider component does not depend
> on its Semantic adapter module.
> # Existing Semantic behavior remains covered by the moved/adapted tests:
> explicit registry references, capability inspection, supported inputs and
> operations, result types and probabilities, validation, exceptions and
> service lifecycle. Metadata inspection must not load the Wolf model or
> perform inference.
> # Relevant Java/XML/YAML examples and Camel JBang usage resolve the new
> artifacts. Existing audit/result rendering continues to use the common
> Semantic contracts.
> # Build metadata, generated artifacts, documentation and upgrade guidance
> consistently reflect the new artifact names.
> # Invalid or unsupported inputs fail before provider/model invocation for
> both experts, with regression tests for supported text/structured inputs and
> rejected media.
> h2. Scope boundary
> The OpenAI Decisions integration and camel-semantic-openai belong in a
> separate issue. This refactoring does not add OpenAI support, multimodal
> inputs, image audit rendering, a Semantic API/runtime split, or new inference
> behavior.
> h2. References
> * [TypeSafe AI module at the merged Semantic
> baseline|https://github.com/apache/camel/tree/12e8bdcdf1affa19b3d62786d4a4001db936b164/components/camel-ai/camel-typesafe-ai]
> * [Wolf Defender module at the same
> baseline|https://github.com/apache/camel/tree/12e8bdcdf1affa19b3d62786d4a4001db936b164/components/camel-ai/camel-wolf-defender]
> * [Merged explicit-expert and audit changes, PR
> 27791|https://github.com/apache/camel/pull/27791]
> _AI-generated by Codex on behalf of luigidemasi (Luigi De Masi)._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
