Remove our Narayana auto-configuration in favor of their own support

[wilkinsona]

We currently have auto-configuration and starters for three JTA implementations:

• Atomikos
• Bitronix
• Narayana

Looking at Maven Central download numbers for the starters and project creation on start.spring.io, I don't think their usage justifies the ongoing maintenance cost. This is particularly true for Narayana where the maintenance cost has been higher than for Atomikos and Bitronix.

In addition to the usage being low, relatively speaking it's dropping. In February 2017, 0.76% of projects generated on start.spring.io used one of the three JTA options. In January 2018, that'd dropped to 0.41%.

There has been some discussion in the past about Narayana's auto-configuration being maintained externally. That's largely been driven by different release cadences. The request by @gytis to make these changes in 1.5.x is the latest example of this.

2.0 is the ideal opportunity to drop the starters and auto-configuration. I think we should take it.

[snicoll]

Dropping JTA support from the core would remove quite a lot of complexity so that's a good thing but I am afraid we're a bit late to do this. How about acking the drop in 2.1? implementations that are willing to keep Spring Boot support can take the auto-configuration code (and starter) on their side.

[philwebb]

I agree with @snicoll that it's a bit late to drop support entirely in 2.0, especially as we'd really need to find a new home for the existing code.

[gytis]

I've moved the Narayana integration code to a separate project: https://github.com/snowdrop/spring-boot-narayana. I've split the starter into two as the JMS and JDBC wrappers were moved to a different package for Spring Boot 2.0.
It is configured before the JTA configuration located in Spring Boot code base (https://github.com/snowdrop/spring-boot-narayana/blob/master/spring-boot-1-narayana-starter/src/main/java/me/snowdrop/boot/narayana/SpringBoot1NarayanaConfiguration.java#L69) so it can work without removing original transaction integrations.
If you agree, we could initially replace it in start.spring.io and eventually when it is convenient to you, you could remove the code too.

[snicoll]

@gytis thanks for sharing. I've opened 3 issues in that repo, could you please have a look?