Moving smooks-camel-catridge to Apache Camel ?

[davsclaus]

Hi

This is Claus from the Camel project.

I wonder if the smooks-camel-catridge is something that potentially can be moved to Apache Camel to be included out of the box from Camel.

The Camel components out of the box, have better integrated with tooling and Camel users tend to only use what is shipped by Camel itself.

For example UI tooling like Apache Camel Karavan would then be able to use smooks more easily.
https://karavan.space/

[davsclaus]

There is a JIRA ticket about this at Apache Camel
https://issues.apache.org/jira/browse/CAMEL-19985

[cjmamo]

Greetings Claus. This is something we definitely can consider and discuss in the Smooks dev forum. A concern I have, however, is the impact this would have on the release cadence of projects that have a dependency on this cartridge. For example, smooks-bom can't be released until the Camel cartridge is released because the BOM has a dependency on it. Could the cartridge be forked instead of moved? Of course, someone would then need to keep the code bases synced. Would someone from the Camel community be interested in doing some of the legwork? I have limited capacity but can assist.

[cjmamo]

Now that I think about it, perhaps we can remove the Camel cartridge from the Smooks BOM. Still, I'm unsure how this will play out in the long-term. Perhaps we could start with a fork and then eventually remove the original cartridge if things pan out well?

[davsclaus]

Now that I think about it, perhaps we can remove the Camel cartridge from the Smooks BOM. Still, I'm unsure how this will play out in the long-term. Perhaps we could start with a fork and then eventually remove the original cartridge if things pan out well?

Yeah we could try that, so the fork could then be adjusted to ASF Camel, and be part of upcoming release. And then we can see if that works out well, and the smooks catridge can be deprecated, and point users to use the camel released instead.

[davsclaus]

Just be in mind that all ASF projects can only be released as ASF License source code, so if the code is forked then we would need to adjust the license header to be standard ASF license header, such as this example:
https://github.com/apache/camel/blob/main/components/camel-activemq/src/main/java/org/apache/camel/component/activemq/ActiveMQComponent.java#L1-L16

[cjmamo]

Just be in mind that all ASF projects can only be released as ASF License source code

That shouldn't be a problem since the cartridge code is dual-licensed.

[davsclaus]

Just be in mind that all ASF projects can only be released as ASF License source code

That shouldn't be a problem since the cartridge code is dual-licensed.

Okay sounds good. Do you have a good plan how to move forward?
Would the smooks team need time to evaluate this proposal?

For the forked code, then I wonder if me, you or someone else from the smooks team can do that? For ASF to accept the code, then it can be a PR on github, or code attached as .zip to a camel JIRA ticket in the issue tracker.

After the initial code fork, then I can adjust the code on the Camel side to make it build together with all the other components and be included as a first-class component in Camel and whatelse is needed.

[cjmamo]

Okay sounds good. Do you have a good plan how to move forward?
Would the smooks team need time to evaluate this proposal?

Posted this proposal in the dev forum for input but I'm not expecting any hurdles.

For the forked code, then I wonder if me, you or someone else from the smooks team can do that? For ASF to accept the code, then it can be a PR on github, or code attached as .zip to a camel JIRA ticket in the issue tracker

I can open a PR to get the ball rolling and then someone from the Camel community can push it over to the finish line. Should the PR reference CAMEL-19985?

Yeah we could try that, so the fork could then be adjusted to ASF Camel, and be part of upcoming release. And then we can see if that works out well, and the smooks catridge can be deprecated, and point users to use the camel released instead.

I'm realising that probably we won't be able to deprecate the whole cartridge because the cartridge allows the developer to send data to Camel endpoints from within Smooks as well. In other words, some cartridge functionality can be deprecated and eventually stripped away, but not all of it.

[davsclaus]

Okay sounds good. Do you have a good plan how to move forward?
Would the smooks team need time to evaluate this proposal?

Posted this proposal in the dev forum for input but I'm not expecting any hurdles.

For the forked code, then I wonder if me, you or someone else from the smooks team can do that? For ASF to accept the code, then it can be a PR on github, or code attached as .zip to a camel JIRA ticket in the issue tracker

I can open a PR to get the ball rolling and then someone from the Camel community can push it over to the finish line. Should the PR reference CAMEL-19985?

Yes this is appreciated for PRs to link to a jira ticket (if any exists). So the usual style is CAMEL-12345: blah blah.

Yeah we could try that, so the fork could then be adjusted to ASF Camel, and be part of upcoming release. And then we can see if that works out well, and the smooks catridge can be deprecated, and point users to use the camel released instead.

I'm realising that probably we won't be able to deprecate the whole cartridge because the cartridge allows the developer to send data to Camel endpoints from within Smooks as well. In other words, some cartridge functionality can be deprecated and eventually stripped away, but not all of it.

Okay do you know if this kind of functionality is in much use?

[cjmamo]

Okay do you know if this kind of functionality is in much use?

I can't say but I'm assuming that this functionality should not be ported over to the new Camel Smooks component.

[davsclaus]

Okay do you know if this kind of functionality is in much use?

I can't say but I'm assuming that this functionality should not be ported over to the new Camel Smooks component.

Yeah likely not initially.

But maybe later we can come up with some kind of plugin API that smooks uses in those places, and then requires the user to install the apache camel smooks component that then comes with the implementation. Me saying this without having looked at the smooks source code. But just an idea on top of my mind.