ppalaga commented on PR #3727: URL: https://github.com/apache/camel-quarkus/pull/3727#issuecomment-1118541347
Hi @javaduke, sorry for the colossal delay, I only found time to have a look now. First of all, thanks a lot for accepting this challenge! It is very appreciated. Since day one of Camel Quarkus, we are hearing requests to have at least a SOAP client. We know there is a lot of interest, but we never came to it because of other priorities and because we knew this won't be easy. Having said that, we are definitely interested to work towards accepting your contribution. Now let me sketch the things we need to make this happen. 1. I can only second to @jamesnetherton 's preference to first split the Camel CXF component into WS and RS parts and clean it up from Spring dependencies. In short, I'd see this PR being blocked by https://issues.apache.org/jira/browse/CAMEL-9627 It would be great if you'd be ready to work on that. If not, we'll have to find another assignee. Ideally, this should be complete for the next Camel LTS (Long Term Support) release (weeks rather than months from now). 2. It would be great if we could find a clean way to support *only* the SOAP client. This is because we do not want to commit to supporting Jetty or Undertow transports CXF server depends on. It is easy to find some hack that will make the Camel CXF Consumer impossible to use on Camel Quarkus. But that's not all. We'd ideally want to also get rid of as much CXF server artifacts as possible. It would be ideal if there was a split into CXF-WS consumer and CXF-WS producer artifacts in Camel. I am not sure at all this will be acceptable for the Camel folks. I do not think there are other components split in this way. If the consumer/producer split is not possible in Camel, then in Camel Quarkus we will need to exclude as many CXF server dependencies as possible. 3. Integration test: * The integration test should not directly depend on any Camel artifacts. The test should show the way how end users are supposed to use the new extension and we should make it as easy as possible. Hence if any of those Camel artifacts is required by the extension, then they should become dependencies of the extension or they should be removed (see the next point). * The test is currently creating a Camel WS service to be able to test the client. I'd vote for packing the service (does not even need to use Camel) into a container and test against that container, so that the test module does not require any CXF server artifacts. I hope this sounds like a realistic plan to you? -- 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]
