CAMEL-26697: camel-jbang - The exported pom.xml names each artifact once by etzel-mes · Pull Request #29353 · apache/camel

etzel-mes · 2026-11-06T18:50:40Z

Description

camel export wrote a pom.xml that names the same artifact twice. Maven 3.9 warns about that, and Maven 3.10.0 (2026-09-27) fails the build; the exported project carries the 3.9.12 wrapper, so the failure appears when the project is built with a Maven of its own, as a build pipeline does.

Two mechanisms produce such a pom, one commit each, and two more commits from the review.

The notation. Exporter.resolveDependencies collects the dependencies and removes the duplicates per groupId:artifactId as its last step. The three runtime exporters override it, call super first and then add their own dependencies, so what they add is not deduplicated — and an artifact in the camel: notation is a different string from the mvn:org.apache.camel:camel-...:<version> that the recorded run holds. CAMEL-24247 changed the notation of the camel-main metrics and health dependencies for this reason; that holds only where the base exporter adds the identical string before the duplicates are removed.

The mapping. The duplicates are removed by the coordinates as written, while each runtime maps the dependencies to its own artifacts afterwards (camel-x → camel-quarkus-x, camel-x → camel-x-starter, and the quarkus-dependencies.properties replacements). Two dependencies with different written coordinates become the same artifact there.

Export	Named twice before
`--runtime=camel-main`, `camel.metrics.enabled=true`	camel-micrometer-prometheus
`--runtime=camel-main --console`, console options in application.properties	camel-console, camel-management, camel-health, camel-platform-http-main, camel-platform-http-jolokia
`--runtime=quarkus --console`, the same	camel-quarkus-console, camel-quarkus-management
`--runtime=spring-boot --console`, the same	camel-console-starter, camel-management-starter
`--runtime=quarkus --console --dep=org.apache.camel.quarkus:camel-quarkus-console`	camel-quarkus-console
`--runtime=spring-boot --console --dep=org.apache.camel.springboot:camel-console-starter`	camel-console-starter

The change:

resolveDependencies is the step that removes the duplicates of the dependency strings and is final: it calls the overridable doResolveDependencies and deduplicates what comes back. The dependencies a runtime exporter adds are deduplicated as well, whatever notation they use.
A runtime exporter therefore sees the dependencies before the duplicates are removed. CamelMainExporter decided with s.contains("mvn:org.apache.camel:camel-platform-http-main") whether the main HTTP server is included, and removed camel-platform-http and -vertx by the same kind of string check, so a dependency given as camel:platform-http would have survived the removal. Those three checks compare artifacts (hasCamelArtifact / removeCamelArtifact).
The four places that build the pom's dependencies (Exporter.buildDependencyList, QuarkusExporter.buildQuarkusDependencyList after its replacements, SpringBootExporter's list and its legacy catalog template) remove the duplicates of the mapped artifacts, with one rule in ExportHelper.removeDuplicateArtifacts: a single dependency per groupId:artifactId, the first, but one with a version wins over one without — the rule the string step already applies to an explicit --dep version. The pom entries keep their order, as the sort still runs last.
SpringBootExporter decided the same way whether the export has an HTTP server, for the run controller of the exported application.properties and for the openapi dependency. Both places compare artifacts now (third commit, on review). camel-platform-http-vertx counts as a server as well, as the prefix of the string check did. camel-platform-http-main and -jolokia no longer count, as they are the server of camel-main and not of Spring Boot; no export changes its outcome by that, as a run with --console records camel-platform-http and -vertx next to them.
The version preference of removeDuplicateArtifacts reads in parentheses (fourth commit, on review). The condition is unchanged.
The camel: notation of CAMEL-24247 is kept; the fix does not revert it.

Tests: ExportTest.shouldNotDuplicateMetricsDependency (the test of CAMEL-24247) now runs over the three metrics options; shouldNotDuplicateConsoleDependencies exports with --console and a profile that has the console options, for the three runtimes; shouldNotDuplicateConsoleDependencyGivenAsRuntimeArtifact adds a --dep with the runtime's own coordinates for Quarkus and Spring Boot. Each asserts that the exported pom.xml names every artifact once. Six of those cases fail without the first two changes, and ExportHelperTest has the rule of the second one on its own. shouldReplacePlatformHttpInAnyNotation and shouldKeepTheRunControllerOutWhenPlatformHttpIsGivenInAnyNotation pin what camel-main and Spring Boot do with a camel:platform-http dependency; both pass before their change as well, because the silent run records the mvn: notation of a --dep too, so the string checks found the artifact — they guard the behaviour rather than prove the fix. camel-jbang-run (257 tests) and the whole ExportTest (158) pass.

Please check the whole change

The duplicates are removed per groupId:artifactId, as the step before this change already did, so two entries of one artifact that differ only in classifier or packaging collapse as well. No export in the tests has such a pair, and this is the behaviour the export already had, so it is kept.
The Spring Boot HTTP-server check of the third commit no longer counts camel-platform-http-main and -jolokia, which the prefix of the old string check did. I looked for an export that changes its outcome by that and found none: a run with --console records camel-platform-http and -vertx next to those two, so the component is in the set whenever they are. The check is narrower in principle, with no set the recorded run produces to show it.
Neither platform-http test distinguishes the notations: with --dep the silent run records the mvn: notation as well, and no option skips the silent run, so the short notation never reaches the exporter alone in an export test. Both lines are provable by reading; the tests pin the behaviour and fail when the detection breaks.
Two string checks of this kind are left out on purpose: CamelMainExporter's "if platform-http is included then switch to camel-platform-http-main" (its substring also matches -vertx and -jolokia, which for camel-main should switch to the main server, so an exact comparison would change behaviour) and Exporter.hasOpenapi. Both miss the camel: notation, and both would carry the test limitation above. Say the word and they go in here or into an issue of their own.
No upgrade-guide entry: no option, default or API changes; an exported pom.xml loses a line it should not have had.
CAMEL-24247 was backported to camel-4.18.x. Whether this one is backported is your call.
mvn clean install -DskipTests from the root folder was not run on this machine; camel-jbang-run and camel-jbang-core were built and their tests run, and the change feeds no generator.

Target

I checked that the commit is targeting the correct branch (Camel 4 uses the main branch)

Tracking

CAMEL-26697

Apache Camel coding standards and style

I checked that each commit in the pull request has a meaningful subject line and body.
I have run mvn clean install -DskipTests locally from root folder and I have committed all auto-generated changes. (Only the two changed modules were built; see above.)

AI-assisted contributions

If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., Co-authored-by trailers) and the PR description identifies the AI tool used.

Written with Claude Code (Claude Opus 5 and Claude Fable 5.1), each commit reviewed by a separate Claude Fable 5.1 run.

Claude Code on behalf of etzel-mes

🤖 Generated with Claude Code

…ce in two notations A runtime exporter adds its dependencies after the duplicates of the collected ones were removed, so an artifact it adds is named a second time when the recorded run holds the same artifact in another notation: camel:micrometer-prometheus and mvn:org.apache.camel:camel-micrometer-prometheus:4.23.0 are two strings for one artifact. With camel.metrics.enabled the exported pom.xml named camel-micrometer-prometheus twice, and Maven 3.10 fails such a build. CAMEL-24247 changed the notation of the camel-main metrics and health dependencies so that the Set collapses them. That covers the options the base exporter handles as well, and not the console dependencies, which all three runtimes name twice for the same reason. resolveDependencies is now the step that removes the duplicates, after the dependencies a runtime exporter adds: the collection moved to the overridable doResolveDependencies. A runtime exporter therefore sees the dependencies before the duplicates are removed. The camel-main exporter decided with a string check whether the main HTTP server is included, and removed camel-platform-http and -vertx by the same kind of check, so a dependency given as camel:platform-http would now survive the removal. Those three checks compare artifacts instead of dependency strings. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…e mapping of a runtime The duplicates of the dependencies are removed by the groupId:artifactId of each dependency as written, before a runtime exporter maps them to its own artifacts. Two dependencies with other coordinates become the same artifact through that mapping, and the exported pom.xml names it twice: with --runtime=quarkus --console, the camel-console that --console adds becomes org.apache.camel.quarkus:camel-quarkus-console, which a --dep=org.apache.camel.quarkus:camel-quarkus-console names as well. The Spring Boot export does the same through its -starter mapping, and Maven 3.10 fails such a build. The four places that turn the dependency strings into the MavenGavs of the pom (the camel-main list, the Quarkus list after its replacements, the Spring Boot list and the legacy catalog template of Spring Boot) now remove the duplicates after their mapping, with one rule in ExportHelper next to the comparator they share: a single dependency per groupId:artifactId, the first one in its position, except that one with a version wins over one without, as the mapping leaves the version of a runtime's own artifacts to the BOM. The pom entries keep their sort order. The camel-main list maps nothing of its own, where only two local JARs of one artifact converge; the rule is called there as well, so it holds for every pom the export writes. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

etzel-mes · 2026-11-06T18:51:41Z

@davsclaus @gnodet would you have a look? I cannot request reviewers as an external contributor.

This builds on your CAMEL-24247 fix rather than replacing it: the camel: notation it introduced stays, and the first commit moves the step that removes the duplicates to the end of the dependency resolution, where it also sees what a runtime exporter adds. The second commit covers the duplicates that only the coordinates of the pom reveal, after each runtime's mapping. The description lists the six exports that named an artifact twice on main and what I could not verify.

JIRA: CAMEL-26697, assigned to mardonius.

Claude Code on behalf of etzel-mes

davsclaus

TL;DR

Approve: the export now names each artifact once in the pom.xml, both when the same artifact comes in two notations and when the runtime mapping folds two coordinates into one artifact.

Blockers: None

Other findings: none, all review questions resolved.

Thanks @etzel-mes, this is a careful fix with a very clear write-up. What I checked:

Making resolveDependencies final. The only subclasses are the three package-private runtime exporters, and all of them now override doResolveDependencies and call super first. Nothing outside the package can be broken by final. Running the string dedup after the runtime additions is the actual fix for the notation case. It also covers SpringBootExporter adding mvn:org.apache.camel:camel-platform-http next to a user's camel:platform-http, which would have produced a duplicate before.
The artifact checks in CamelMainExporter. MavenGav.parseGav maps camel:x, camel-x, org.apache.camel:camel-x[:v] and mvn:org.apache.camel:camel-x:v to the same groupId/artifactId, and it never throws on other strings (file:, plain GAVs). The exact artifactId comparison also fixes a gap in the old contains("org.apache.camel:camel-platform-http:") check, which missed a versionless mvn: entry.
ExportHelper.removeDuplicateArtifacts after the mapping. First entry wins and keeps its position, and a versioned entry wins over an unversioned one. That matches the existing --dep precedence rule, and the sort still runs last. The CAMEL-24247 camel: notation is kept, so this doesn't revert that change.

Tests: assertEachArtifactOnce over the three runtimes and the three metrics options, plus the --dep given as a runtime artifact, cover the cases in the table. shouldReplacePlatformHttpInAnyNotation pins the camel-main replacement. The ExportHelperTest additions follow that class's existing JUnit style.

The remaining SpringBootExporter contains("mvn:org.apache.camel:camel-platform-http") check is fine to leave as you describe. It is a prefix match that also covers -vertx/-main, so an exact-artifact swap would change its meaning and belongs to its own issue.

CI on this head is still waiting for workflow approval. This review is static and does not replace CI, SonarCloud or other specialized review tools.

Claude Code on behalf of Claus Ibsen

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

davsclaus

TL;DR

Request changes: one small addition before merge. The SpringBootExporter HTTP-server check should use the new hasCamelArtifact helper as well.

Blockers

SpringBootExporter.java:141 and :448: the HTTP-server check still compares dependency strings

Other findings: none. Everything else from my earlier review stands.

Sorry for the back and forth @etzel-mes. In my approval I agreed this could be left out. On a second look it's a two-line change with the helper you already added, so it's better to do it in this PR than in a separate issue.

The issue. Both places in SpringBootExporter decide whether the export has an HTTP server with:

deps.stream().anyMatch(s -> s.contains("mvn:org.apache.camel:camel-platform-http"))

That misses the short notation (--dep=camel-platform-http, --dep=camel:platform-http, or camel.jbang.dependencies=camel:platform-http) when the recorded run doesn't also hold the mvn: form. At line 141 the exported application.properties then gets camel.main.run-controller=true although the project has a server. This is the same pattern the first commit replaced in CamelMainExporter.

Suggested change. hasCamelArtifact is protected static in Exporter, so SpringBootExporter can call it at both places. Keep camel-platform-http-vertx, because the current prefix match counts it as a server:

// line 141
boolean http = hasCamelArtifact(deps, "camel-platform-http")
        || hasCamelArtifact(deps, "camel-platform-http-vertx");

// line 448
boolean http = hasCamelArtifact(answer, "camel-platform-http")
        || hasCamelArtifact(answer, "camel-platform-http-vertx");

Test. A Spring Boot sibling of shouldReplacePlatformHttpInAnyNotation: export with --runtime=spring-boot --dep=camel-platform-http, then assert that the exported application.properties has no camel.main.run-controller and that assertEachArtifactOnce holds. Please keep the JDK 21 guard that the other Spring Boot tests use.

This review is static and does not replace CI, SonarCloud or other specialized review tools.

Claude Code on behalf of Claus Ibsen

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

gnodet-bot

Clean, well-structured fix for the Maven 3.10 duplicate-GA rejection in exported pom.xml. The two-layer dedup strategy (string-level in resolveDependencies → MavenGav-level in buildDependencyList) is correct and non-interfering. The template method pattern (final resolveDependencies + overridable doResolveDependencies) is a solid design improvement. The notation-agnostic hasCamelArtifact/removeCamelArtifact helpers are strictly more correct than the old contains()-based string matching. Tests are thorough.

One minor readability note inline — otherwise this is good to go.

This review was generated by an AI agent, Hermès on behalf of @gnodet.

github-actions · 2026-11-06T19:10:18Z

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

First-time contributors require MANUAL approval for the GitHub Actions to run
You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

github-actions · 2026-11-06T19:27:29Z

🧪 CI tested the following changed modules:

dsl/camel-jbang/camel-jbang-core
dsl/camel-jbang/camel-jbang-run

🔁 1 test passed only after a retry on JDK 21 (1 retried attempt)

Recovered flaky tests on JDK 21 (1)

Module	Test	Failed attempts	First failure
`dsl/camel-jbang/camel-jbang-plugin-tui`	`LaunchManagerOutcomeTest.startedWhenTheStatusFileSaysSo`	1	expected: null but was: LaunchOutcome[ok=false, log=null]

ℹ️ These tests did not fail the build. Surefire retried them and they passed.
Retries are enabled project-wide by surefire.rerunFailingTestsCount in parent/pom.xml.

🔬 Scalpel shadow comparison — Scalpel: 3 of 717 tested, 3 compile-only — current: 6 all tested

Maveniverse Scalpel detected 3 affected modules (current approach: 6).

Skip-tests mode would test 3 modules (2 direct + 2 downstream), skip tests for 3 (generated code, meta-modules)

Modules only in current approach (3)

camel-jbang-mcp
camel-jbang-plugin-mcp
camel-launcher-container

Modules Scalpel would test (3)

camel-jbang-plugin-tui ← downstream of org.apache.camel:camel-jbang-core
camel-jbang-plugin-validate ← downstream of org.apache.camel:camel-jbang-core
camel-jbang-run ← dsl/camel-jbang/camel-jbang-run/src/main/java/org/apache/camel/dsl/jbang/run/common/ExportHelper.java, dsl/camel-jbang/camel-jbang-run/src/main/java/org/apache/camel/dsl/jbang/run/export/CamelMainExporter.java, dsl/camel-jbang/camel-jbang-run/src/main/java/org/apache/camel/dsl/jbang/run/export/Exporter.java, dsl/camel-jbang/camel-jbang-run/src/main/java/org/apache/camel/dsl/jbang/run/export/QuarkusExporter.java, dsl/camel-jbang/camel-jbang-run/src/main/java/org/apache/camel/dsl/jbang/run/export/SpringBootExporter.java, dsl/camel-jbang/camel-jbang-run/src/test/java/org/apache/camel/dsl/jbang/run/common/ExportHelperTest.java

Modules with tests skipped (3)

camel-jbang-plugin-generate
camel-jbang-plugin-kubernetes
coverage

ℹ️ Shadow mode — Scalpel observes but does not affect test execution. Learn more

⚠️ Some tests are disabled on GitHub Actions (@DisabledIfSystemProperty(named = "ci.env.name")) and require manual verification:

dsl/camel-jbang/camel-jbang-core: 2 test(s) disabled on GitHub Actions

💡 Manual integration tests recommended:

You modified dsl/camel-jbang/camel-jbang-core. The related integration tests in dsl/camel-jbang/camel-jbang-it are excluded from CI. Consider running them manually:
mvn verify -f dsl/camel-jbang/camel-jbang-it -Djbang-it-test

All tested modules (10 modules, 1m 44s total)

Total reactor time: 1m 44s

Module	Duration	Status
Camel :: JBang :: MCP	28.8s	SUCCESS
Camel :: JBang :: Plugin :: Validate	25.1s	SUCCESS
Camel :: JBang :: Run	19.3s	SUCCESS
Camel :: JBang :: Plugin :: Kubernetes	17.0s	SUCCESS
Camel :: Coverage	5.2s	SUCCESS
Camel :: JBang :: Plugin :: Generate	4.5s	SUCCESS
Camel :: JBang :: Plugin :: MCP	2.8s	SUCCESS
Camel :: Launcher :: Container	1.0s	SUCCESS
Camel :: JBang :: Core	n/a
Camel :: JBang :: Plugin :: TUI	n/a

Top 20 slowest modules:

Camel :: JBang :: MCP (28.8s)
Camel :: JBang :: Plugin :: Validate (25.1s)
Camel :: JBang :: Run (19.3s)
Camel :: JBang :: Plugin :: Kubernetes (17.0s)
Camel :: Coverage (5.2s)
Camel :: JBang :: Plugin :: Generate (4.5s)
Camel :: JBang :: Plugin :: MCP (2.8s)
Camel :: Launcher :: Container (1.0s)

⚙️ View full build and test results

…r in any notation The Spring Boot exporter decided with a string check whether the export has an HTTP server, so a dependency given as camel:platform-http was invisible to it. The exported application.properties would then get camel.main.run-controller=true although the project has a server, and an export with openapi would add camel-platform-http a second time. Both places compare artifacts now, as the camel-main exporter does since the first commit. camel-platform-http-vertx counts as a server as well, as the prefix of the string check did. camel-platform-http-main and -jolokia, which the recorded run can hold, no longer count: they are the server of camel-main, not of Spring Boot. No export changes its outcome by that, as a run with --console records camel-platform-http and -vertx next to them. The test pins that a Spring Boot export with platform-http gets no run controller. It does not distinguish the notations: with --dep the silent run records the mvn: notation as well, so the string check found the artifact too. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The version preference of the duplicate removal mixes || and && without parentheses. The condition is the intended one, as && binds tighter, but a reader has to apply the precedence rules and static analysis reports the mix. The parentheses group the pair; the rule is unchanged: the first dependency of an artifact is kept, unless it has no version and a later one does. Suggested in the review of this pull request. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

fixed

gnodet-bot

Following up on my earlier review — both issues are addressed.

Parentheses in ExportHelper — ✅ addressed. (!hasVersion(existing) && hasVersion(gav)) is explicit now.
SpringBootExporter HTTP check at both locations — ✅ addressed. Both export() (line ~141) and doResolveDependencies (line ~448) now use hasCamelArtifact(deps, "camel-platform-http") || hasCamelArtifact(deps, "camel-platform-http-vertx"), matching what davsclaus requested. The new shouldKeepTheRunControllerOutWhenPlatformHttpIsGivenInAnyNotation test covers it with the JDK 21 guard and asserts camel.main.run-controller is absent.

Previous findings are all addressed. LGTM.

This review was generated by an AI agent, Hermès on behalf of @gnodet.

davsclaus

Re-review of cbc5389 and c3ace16. Thanks @etzel-mes, both points are addressed:

SpringBootExporter: both places (the run-controller check in export() and the openapi check in doResolveDependencies) now use hasCamelArtifact for camel-platform-http and camel-platform-http-vertx. Your note on the narrower match (-main and -jolokia no longer count as a server) checks out: a --console run records the component next to them, so no export changes.
ExportHelper: the explicit parentheses keep the same rule.
The new shouldKeepTheRunControllerOutWhenPlatformHttpIsGivenInAnyNotation test pins the behaviour, and I agree it can't separate the notations while the silent run always records the mvn: form.

On the two checks you left on purpose (the contains("camel-platform-http") in CamelMainExporter and Exporter.hasOpenapi) and the ExportTest.createCommand problem (a later parse resets --dir and the test exports into camel-jbang-core itself): yes, please file those as a JIRA. The createCommand one in particular can overwrite the module's pom.xml in a local build, so it's worth fixing.

Reviewed with Claude Code on behalf of davsclaus. This review was generated by an AI agent and may contain inaccuracies; please verify all suggestions before applying.

davsclaus · 2026-11-06T20:48:37Z

@etzel-mes CI fails in RunExportGoldenTest case options (golden/expected/options.export.txt). This is your fix working, not a regression: the golden file on main lists camel-platform-http-jolokia and camel-platform-http-main twice each in the # pom.xml section, and the export now names them once. The test ran 3 times on CI, with the same diff each time:

<   dependency org.apache.camel:camel-platform-http-jolokia
<   dependency org.apache.camel:camel-platform-http-main

Could you regenerate it and push the updated golden file?

cd dsl/camel-jbang/camel-jbang-core
mvn test -Dtest=RunExportGoldenTest -Dcamel.golden.update=true

Only options.export.txt should change. Once CI is green, it can be merged.

Claude Code on behalf of davsclaus. This was generated by an AI agent and may contain inaccuracies; please verify before applying.

…h artifact once The options case of RunExportGoldenTest exports a camel-main run with --observe and --console. Its expected pom.xml listed camel-platform-http-main and camel-platform-http-jolokia twice: the duplicate in two notations that this change removes. Regenerated with -Dcamel.golden.update=true; only options.export.txt changes. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

gnodet-bot

Following up on my earlier reviews — previous findings remain fully addressed and no new issues found.

The commit since last review (0a2642d) fixes the CI failure davsclaus flagged: options.export.txt removes the two duplicate lines (camel-platform-http-jolokia and camel-platform-http-main) that the new dedup logic now prevents from appearing in the exported pom.xml. The production fix, deduplication helpers, and new tests are sound — full review in my earlier comment.

Previous findings all addressed. LGTM.

This review was generated by an AI agent, Hermès on behalf of @gnodet.

davsclaus

Re-review of 0a2642d: the golden file options.export.txt now lists camel-platform-http-jolokia and camel-platform-http-main once each, which is the dedup fix working as intended. CI is green, the earlier threads are resolved. LGTM, thanks @etzel-mes.

Claude Code on behalf of davsclaus. This review was generated by an AI agent and may contain inaccuracies; please verify all suggestions before applying.

etzel-mes and others added 2 commits November 6, 2026 20:56

davsclaus approved these changes Nov 6, 2026

View reviewed changes

davsclaus previously requested changes Nov 6, 2026

View reviewed changes

Comment thread .../camel-jbang-run/src/main/java/org/apache/camel/dsl/jbang/run/export/SpringBootExporter.java Resolved

github-actions Bot added the dsl label Nov 6, 2026

gnodet-bot reviewed Nov 6, 2026

View reviewed changes

Comment thread ...-jbang/camel-jbang-run/src/main/java/org/apache/camel/dsl/jbang/run/common/ExportHelper.java Resolved

etzel-mes and others added 2 commits November 6, 2026 23:12

gnodet-bot reviewed Nov 6, 2026

View reviewed changes

davsclaus approved these changes Nov 6, 2026

View reviewed changes

gnodet-bot reviewed Nov 6, 2026

View reviewed changes

davsclaus approved these changes Nov 6, 2026

View reviewed changes

Navigation Menu

Repository navigation

CAMEL-26697: camel-jbang - The exported pom.xml names each artifact once - #29353

CAMEL-26697: camel-jbang - The exported pom.xml names each artifact once#29353
etzel-mes wants to merge 5 commits into
apache:mainfrom
etzel-mes:fix/CAMEL-26697-export-duplicate-dependency

etzel-mes commented Nov 6, 2026 •

edited

Loading

Uh oh!

etzel-mes commented Nov 6, 2026

Uh oh!

davsclaus left a comment

Uh oh!

davsclaus left a comment

Uh oh!

Uh oh!

gnodet-bot left a comment

Uh oh!

Uh oh!

github-actions Bot commented Nov 6, 2026

Uh oh!

github-actions Bot commented Nov 6, 2026 •

edited

Loading

Uh oh!

gnodet-bot left a comment

Uh oh!

davsclaus left a comment

Uh oh!

davsclaus commented Nov 6, 2026

Uh oh!

gnodet-bot left a comment

Uh oh!

davsclaus left a comment

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

etzel-mes commented Nov 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Please check the whole change

Target

Tracking

Apache Camel coding standards and style

AI-assisted contributions

Uh oh!

etzel-mes commented Nov 6, 2026

Uh oh!

davsclaus left a comment

Choose a reason for hiding this comment

TL;DR

Uh oh!

davsclaus left a comment

Choose a reason for hiding this comment

TL;DR

Uh oh!

Uh oh!

gnodet-bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

github-actions Bot commented Nov 6, 2026

Uh oh!

github-actions Bot commented Nov 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gnodet-bot left a comment

Choose a reason for hiding this comment

Uh oh!

davsclaus left a comment

Choose a reason for hiding this comment

Uh oh!

davsclaus commented Nov 6, 2026

Uh oh!

gnodet-bot left a comment

Choose a reason for hiding this comment

Uh oh!

davsclaus left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

etzel-mes commented Nov 6, 2026 •

edited

Loading

github-actions Bot commented Nov 6, 2026 •

edited

Loading