Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RabbitMQ native support #1531

Closed
ppalaga opened this issue Aug 15, 2020 · 15 comments
Closed

RabbitMQ native support #1531

ppalaga opened this issue Aug 15, 2020 · 15 comments
Assignees
Milestone

Comments

@ppalaga
Copy link
Contributor

ppalaga commented Aug 15, 2020

Contributions are welcome. Adding an integration test would the the first step. ActiveMQ is a good place to look how such an integration test should look like https://github.com/apache/camel-quarkus/tree/master/integration-tests/activemq

@Jeansen
Copy link
Contributor

Jeansen commented Aug 15, 2020

@ppalaga That was a quick reply ;-) I've already checked how the project is setup with extensions for quarkus and JVM. I also thought that the ActiveMQ extension would be a candidate to start with. Currently I am all new to Quarkus and Camel. But maybe I'll be able to contribute something.

So far I've already created a simple project with a camel route on my local system. Building native worked and the program spits out the same text when run in JVM (dev) mode.

@ppalaga
Copy link
Contributor Author

ppalaga commented Aug 16, 2020

Feel free to ask if you have specific questions. We also have a step by step guide for promoting extensions from JVM to native https://camel.apache.org/camel-quarkus/latest/contributor-guide/promote-jvm-to-native.html

@Jeansen
Copy link
Contributor

Jeansen commented Aug 17, 2020

Oh, great. I'll check it out!

@Jeansen
Copy link
Contributor

Jeansen commented Aug 21, 2020

I've forked the project and stared implementing an integration test. @ppalaga Would you assign this issue to me, then?

@Jeansen
Copy link
Contributor

Jeansen commented Aug 22, 2020

@ppalaga I've started the integration test. But for some reason I cannot get it connect to the container. Obviously I am missing something but maybe you could direct me?

https://github.com/apache/camel-quarkus/compare/master...Jeansen:rabbitmq-quarkus-native?expand=1

@ppalaga
Copy link
Contributor Author

ppalaga commented Aug 22, 2020

For the camel.component.* props (that you produce in RabbitmqTestResource) to be picked by the application, you need to add the camel-quarkus-main dependency to the test project. It is documented here, but there is perhaps some potential to state the relationship between camel.component.* props and camel-quarkus-main even clearer. We should perhaps also mention it somewhere in the contributor guide.

@Jeansen
Copy link
Contributor

Jeansen commented Aug 23, 2020

Great. Thanks. Now, I almost feel ashamed. I could have simply diffed the two POM files from the ActiveMQ test with mine ... 😊 and seen it. I just ran the test again and it was successful. Thank you 😃

@Jeansen
Copy link
Contributor

Jeansen commented Aug 23, 2020

@ppalaga I've created a PR. Please review.

@ppalaga
Copy link
Contributor Author

ppalaga commented Aug 24, 2020

here is perhaps some potential to state the relationship between camel.component.* props and camel-quarkus-main even clearer. We should perhaps also mention it somewhere in the contributor guide.

Addressed in 9752ff6

@ppalaga
Copy link
Contributor Author

ppalaga commented Aug 24, 2020

Resolved via #1567

@ppalaga ppalaga closed this as completed Aug 24, 2020
@ppalaga
Copy link
Contributor Author

ppalaga commented Aug 24, 2020

Thanks again, @Jeansen !

@ppalaga ppalaga added this to the 1.1.0 milestone Aug 31, 2020
@Jeansen
Copy link
Contributor

Jeansen commented Sep 10, 2020

@ppalaga
Copy link
Contributor Author

ppalaga commented Sep 10, 2020

Well, native support is indeed since 1.1.0, but the JVM-only extension was there since 1.0.0. So the extension as a whole is since 1.0.0. Should we make this more explicit on the web page?

@Jeansen
Copy link
Contributor

Jeansen commented Sep 11, 2020

Hm, I am not sure. It might be of interest. At the moment there are not that many versions but in the future it might be of interest since which version native support is available. There might be situations where users simply cannot use the latest versions but have to stick to a specific version. So the argument would be not to use the latest but at least a the version that also supports native.

Long story short: I would say yes and suggest to also ad a column for native :-)

@ppalaga
Copy link
Contributor Author

ppalaga commented Sep 11, 2020

I think you are making a valid point. Could you please file a new issue for that?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants