Add micronaut integration

[lucjross]

Hi, Jaiden,

I've been really impressed with this library. The existing Micronaut JMS solution has been problematic because it uses the low-quality messaging lib from Amazon. I've integrated this library ad-hoc with the Kotlin wrapper in a Micronaut application, and your docs are great so it went smoothly. However, compared to the Spring integration, it isn't ergonomic, and Micronaut's interface very closely matches Spring. Thus, I was able to copy and reuse about 95% of the existing Spring integration.

In the process I upgraded a few basic libraries such as Jackson and the AWS SDK. I tried not to step too far outside of scope, but a lot of stuff in here is a bit stale. Note that I had to add a workaround to the AWS X-Ray extension to pin the ElasticMQ and Jackson dependencies to where they were -- I'm not familiar with X-Ray and trying to upgrade things resulted in deprecation warnings.

I imagine this will be valuable to anyone using SQS with Micronaut. Looking forward to your feedback. Also let me know if you want me to target another branch as I didn't see a master.

[JaidenAshmore]

Hey, thanks for the PR!

At a quick glance, I see that there is a lot of duplication with the spring version, so I'll have a think if there are any ways to reduce that or whether this is just a necessity for supporting multiple frameworks. I'll take a more thorough look on the weekend and get back to you.

[lucjross-favor]

No problem. As far as duplication, yeah, the api package is just about identical so I imagine that could be shared. But then these are unrelated frameworks, although they look very similar (like hedgehogs and porcupines). Since they are also just adapters and not core components, I figured it would be OK to keep them separate.

I do also need to add to the README so I'll try to do so before the weekend.

[JaidenAshmore]

Okay I think what I will do is split this up into a couple of changes:

• A change to upgrade the dependencies, e.g. Jackson, AWS.
• Pull out some of the common API probably down to core, e.g. MessageListenerContainerCoordinator could be used for a wider scope and at least the API isn't spring or micronaut specific.

I can try and make those changes sometime this weekend and release a 7.0 version.

From here you can rebase your changes and then this PR should hopefully just be the addition of that micronaut directory with implementation details.

[lucjross-favor]

OK, sounds perfect. Glad to take care of some of that if you'd like.

[JaidenAshmore]

Hey, I have mode those changes and merged them into a new 7.x branch. The gist of it is:

• A bunch of classes were moved to core/api
• A new annotations package was created that handles a bunch of those annotation based implementations
• spring-api was removed.

So from your end:

• you will need to rebase from 7.x
• you can delete micronaut-api I believe and a bunch of core classes
• you will need to implement a PlaceholderResolver class that can resolve arguments like ${my.key}
• If we can get a couple of integration tests in micronaut-core as well that would be super
• Add any README.md/docs changes for helping people set up micronaut that would be super. It doesn't need to be as thorough as the current spring ones, so maybe just the basics of how to get started or just links to the examples you have created.

Let me know if you have any questions.

[lucjross]

I'm working on a Micronaut-appropriate way of identifying listener methods, as opposed to the way SpringMessageListenerContainerCoordinator does it.

[JaidenAshmore]

I'm working on a Micronaut-appropriate way of identifying listener methods, as opposed to the way SpringMessageListenerContainerCoordinator does it.

sounds good!

[lucjross]

@JaidenAshmore I think it's in good shape now.

[JaidenAshmore]

Looks good! thanks for the good work :D

[JaidenAshmore]

I've released 7.0.0 with this change! Thanks again for all the great work. Let me know if there are any problems and we can push any fixes we need.

Thanks :D

[lucjross-favor]

Thanks Jaiden, it was rewarding to work with your library, and this will be helpful to my org for sure! The prettier changes are a little funny to me - it puts static imports before others? And four space indent in yaml? No worries though - consistency is good.

[JaidenAshmore]

yeah the prettier java styling can be a bit odd and from memory I don't agree with a few of their styling choices. But yeah I just use prettier so I can have a single tool run across the entire codebase.