oscerd commented on issue #1173:
URL:
https://github.com/apache/camel-kamelets/issues/1173#issuecomment-5505992963
The premise of this issue no longer exists, so I think it can be closed —
but the underlying tension it identified is still there, in a different form,
and is worth recording before it goes.
## `camel-kamelets-utils` is gone
The `@BeanInject` case was about autowiring beans from
`camel-kamelets-utils`, which this repository no longer ships. `77be42a85`
("Remove Camel-Kamelets-utils since it is now in core", 2024-10-11) moved it
into Camel core.
Verified against current `main`:
- no Java sources outside `tests/` and `library/`
- no reference to `camel-kamelets-utils` anywhere in the tree
- no occurrence of `BeanInject` at all
Kamelets are YAML templates only now, so there is no place left in this
repository for the `@BeanInject` usage this issue was about. Nothing to support.
## What the validator actually does today
The rule is in `verifyUsedParams` (`script/validator/validator.go`), and it
is symmetric — it errors both on a parameter used but not declared, and on one
declared but never used:
```go
errors = append(errors, fmt.Errorf("parameter %q is declared in kamelet %q
but never used", p, k.Kamelet.Name))
```
The problem you hit — a parameter that is legitimately consumed by something
other than direct interpolation into the template — is real and did not go away
with the utils module. It is currently handled by a **hardcoded list of 13
exempt files** at the top of that function:
```go
if k.FileName != "../../kamelets/azure-storage-blob-source.kamelet.yaml" &&
k.FileName != "../../kamelets/aws-s3-event-based-source.kamelet.yaml" &&
... eleven more ...
```
So the answer to "would we need to change the Kamelet validation tool"
turned out to be yes, and the change that happened was an exclusion list rather
than an understanding of indirect usage.
That works, but it is worth naming as a smell: adding a Kamelet whose
parameter is consumed indirectly means editing a Go file with a hardcoded path,
rather than declaring the intent in the Kamelet itself. An annotation on the
Kamelet — something the validator reads — would keep the exemption next to the
thing being exempted, and would stop the list growing silently.
I have not opened a PR for that: it is a different change from what this
issue asks, it touches the validator's contract for everyone, and it deserves
its own issue if you think it is worth doing. Happy to file one.
Closing this as obsolete since `@BeanInject` in this repository is no longer
possible. Please reopen if I have misread the intent.
---
_Claude Code on behalf of Andrea Cosentino_
--
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]
