What deprecation rules were you thinking about using? Most of these changes represent significant modifications to the public APIs and typically these should only occur in a major revision of the project.

OK, but which major version of Narayana? Plus you should deprecate where possible rather than just going for a full removal immediately. Maybe you can deprecate in minor versions of Narayana between here and the major version (6?) which at least gives people an idea that these changes are coming?

I think you are wrong in ignoring the Narayana community and stand-alone use cases. You are suggesting making a significant API change within the scope of a micro release?! I do not think that is right and definitely wouldn't be happy to see this happen.

This change has broken ALL existing pom.xml, ivy.xml and Gradle build.gradle files that are using Narayana 5.0.x series - and possibly more. I'm not going to check what else broke...

IMHO, this needs to be reverted, and a 5.0.5.Final release made. Then schedule the change for Narayana 5.1 or 6.0.

I am not really sure how you can say it has broken ALL existing pom.xml files. For people that were including the deprecated TXF code they would still need to modify their poms anyway (version 5.0.4 -> 5.0.5).

No Java APIs were broken - that was the point of the change. That being said, if people want to code against the deprecated TXF API still it would be simpler for them if only the V in GAV changed - I do agree there. As such I have raised https://github.com/jbosstm/narayana/pull/819/files which leaves the deprecated code in the old location.

Thanks for the report,

Tom

Paul Robinson wrote:

 

4) Move Compensations dependency adder to transactions subsytem (JBTM-2224)

The XTS WildFly SubSystem has some code that detects the usage of the Compensating transactions API and then adds the required dependencies to the application. The XTS SubSystem is only loaded in the standalone-xts.xml configuration. This has become a problem, since the Compensating transactions API can now also be used with the standalone.xml configuration for local-only transactions. Therefore, I think we should move this dependency adding code into the Transactions SubSystem so that the required dependencies are added regardless of which WildFly configuration is used.

 

 

Making the transaction subsystem dependent on the compensation API is pulling in a lot of extra dependencies that the vast majority of users do not need. Can we move it back out again and find another solution for systems that specifically want to use these annotations.

Makes sense but would it be possible to give some specifics on what else is being pulled in?

The main problem is that the compensations framework depends on XTS (org.jboss.narayana.xts:jbossxts) which in turn pulls in a number of other dependencies that not required by transactions proper. We should either extract compensation specifics into its own artifact or remove it from the wildfly transaction subsystem. We need input from Paul and Gytis to see which is the best way to proceed.

OK that's definitely not good. ArjunaCore shouldn't know about transports. Why is the compensation framework not fairly abstract in ArjunaCore with specific bindings provided in the other modules? That's pretty much the approach we took back in HP for BTP with compensations supported within 'Core but bindings to SOAP where done in WST.

OK so what's Mike complaining about ?