smongiar commented on PR #27206:
URL: https://github.com/apache/camel/pull/27206#issuecomment-5951054084
Answering davsclaus's two open questions:
**1. Is the narrow scope (jackson-annotations mapping only) intentional?**
Yes. The root-cause fix is gnodet's commit — resolving known imports
*before* kamelet loading so the Java route builder can compile with
`@JsonProperty` present. The `jackson-annotations` properties entry is a
complementary, defence-in-depth addition: it ensures that if the resolution
ordering changes again, or if a user runs `camel export` in an environment
where `jackson-annotations` isn't pulled in transitively (e.g., different
runtime configurations, stripped BOM, etc.), the known-import downloader still
covers it.
The JIRA title ("camel export: kamelet spec.dependencies missing from
pom.xml when Java route builder fails to compile during silent run") is broader
than just the mapping — it captures the whole scenario. I'd suggest keeping it
as-is and letting gnodet's fix carry the description, with our mapping as a
supplementary entry. A follow-up JIRA for the general circular-bootstrap case
is a reasonable idea if needed.
**2. Does the test actually fail on `main` without the new properties line?**
Checking `camel-kamelet-main/pom.xml`:
```xml
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-jackson</artifactId> <!-- compile scope, no <scope>
element -->
</dependency>
```
`camel-jackson` transitively brings `jackson-databind` →
`jackson-annotations`, so **jackson-annotations IS already on the test
classpath**. The in-process export run therefore has access to `@JsonProperty`
regardless of our properties entry, meaning the test **probably does pass on
`main` without our line**.
The test validates gnodet's fix (the import resolution timing/ordering
change), not our `jackson-annotations` mapping specifically. I don't see a
straightforward way to unit-test the mapping without running `camel export` in
a fully isolated subprocess with a clean Maven repo. Happy to drop our
properties entry if the consensus is it isn't needed — but it seems harmless
and useful as a forward-compatibility measure. Let me know how you'd like to
proceed.
--
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]