auto generate META-INF content for DataTypeTransformer

[Croway]

Hi, I have some doubts regarding this PR, in particular,

• I had to hack camel-package-maven-plugin in order to support the DataTypeTransformer folder structure META-INF/services/org/apache/camel/datatype instead of META-INF/services/org/apache/camel/ I was wondering if it is worth to use the "default" folder structure META-INF/services/org/apache/camel/transformer.
• I've implemented a sanitizer so that file names are equal to the original ones, but it can be removed if yo are fine with files with : or +.

[github-actions]

🌟 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.

• You can label PRs using build-all, build-dependents, 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.

[davsclaus]

Yeah okay yeah so @christophd created this by hand at first, and yeah we should migrate to make it standard and generated like everything else in camel-core project.

And since they are transformer then they should ideally use META-INF/services/org/apache/camel/transformer as the folder name. This is what the JdkService would do if you specify transformer as the name.

And then you need to change the DefaultTransformerResolver to use the correct location.

For Camel 4.2 we can then add in the release notes about this change (though no camel end users is using this)

[Croway]

Thanks @davsclaus, this was my gut feeling, I'll update the PR accordingly.

[christophd]

Thanks folks! This makes much more sense. Sorry for the folder structure confusion that I created manually

[oscerd]

After this and the release 4.1.0 of camel-kamelets, we can maybe move the transformers from camel-kamelets repo to camel repo and autogenerating

[davsclaus]

After this and the release 4.1.0 of camel-kamelets, we can maybe move the transformers from camel-kamelets repo to camel repo and autogenerating

Ah good idea, can we create a JIRA or github issue for this so we wont forget

[christophd]

There are some data type transformer implementations still living in the camel-kamelets-utils library.

Can we use the same SpiGeneratorMojo to auto generate there?

[oscerd]

There are some data type transformer implementations still living in the camel-kamelets-utils library.

Can we use the same SpiGeneratorMojo to auto generate there?

Wouldn't make more sense to move them in camel repo?

[christophd]

@davsclaus @oscerd I did not see your comments before writing my last comment. Yes, it makes sense to move the transformers into camel repo and use auto generation there

@Croway +1 on the sanitizer BTW

[oscerd]

I mean, we should try to avoid overloading the camel-kamelets library, for example we have also some specific bean there, we should maybe move those in the main repo? WDYT?

[christophd]

Yes +1 on moving to camel as much as possible

The only downside I see is that the transformers may add optional/provided dependencies to the Camel components pom.xml. This is because the transformer implementations refer to like JsonNode, CloudEvents etc. and these bits may not be part of the compile time in a Camel component yet.

[Croway]

the action is failing due to missing files, in particular I have the following locally

Is it safe to push these files? @oscerd @davsclaus

[davsclaus]

Yes its fine to merge

[oscerd]

Go ahead +1 for me