[jboss-jira] [JBoss JIRA] (WFLY-11225) The 'local provider builder' dependencies from org.wildfly.transactions.client module should be made optional

[Brian Stansberry (Jira)]

     [ https://issues.jboss.org/browse/WFLY-11225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-11225:
------------------------------------
    Description: 
The org.wildfly.transactions.client module includes some non-optional dependencies that appear to only be required if JBossLocalTransactionProvider.builder() is used by outside code that provides a local transaction provider. AKA the transaction subsystem.  This means those dependencies are optional in cases where there is no such caller.

The outside caller (i.e. the transaction subsystem module) can ensure that a non-optional dependency on the required modules exists.

This change will allow other modules that have a classloading dependency on org.wildfly.transactions.client but don't necessarily care whether a local tx provider is actually installed to depend on the module without forcing inclusion of these dependencies.

Features provided by modules that depend on org.wildfly.transactions.client and that also require that a local tx provider be installed should create a management model requirement for a capability. See WFLY-11166.

See also discussion at http://post-office.corp.redhat.com/archives/eap-pm-list/2018-October/msg00131.html

  was:
The org.wildfly.transactions.client module includes some non-optional dependencies that appear to only be required if JBossLocalTransactionProvider.builder() is used by outside code that provides a local transaction provider. AKA the transaction subsystem.  This means those dependencies are optional in cases where there is no such caller.

The outside caller (i.e. the transaction subsystem module) can ensure the required modules are present.

This change will allow other modules that have a classloading dependency on org.wildfly.transactions.client but don't necessarily care whether a local tx provider is actually installed to depend on the module without forcing inclusion of these dependencies.

Features provided by modules that depend on org.wildfly.transactions.client and that also require that a local tx provider be installed should create a management model requirement for a capability. See WFLY-11166.

See also discussion at http://post-office.corp.redhat.com/archives/eap-pm-list/2018-October/msg00131.html



> The 'local provider builder' dependencies from org.wildfly.transactions.client module should be made optional
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-11225
>                 URL: https://issues.jboss.org/browse/WFLY-11225
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Transactions
>            Reporter: Brian Stansberry
>            Assignee: Tom Jenkinson
>            Priority: Major
>
> The org.wildfly.transactions.client module includes some non-optional dependencies that appear to only be required if JBossLocalTransactionProvider.builder() is used by outside code that provides a local transaction provider. AKA the transaction subsystem.  This means those dependencies are optional in cases where there is no such caller.
> The outside caller (i.e. the transaction subsystem module) can ensure that a non-optional dependency on the required modules exists.
> This change will allow other modules that have a classloading dependency on org.wildfly.transactions.client but don't necessarily care whether a local tx provider is actually installed to depend on the module without forcing inclusion of these dependencies.
> Features provided by modules that depend on org.wildfly.transactions.client and that also require that a local tx provider be installed should create a management model requirement for a capability. See WFLY-11166.
> See also discussion at http://post-office.corp.redhat.com/archives/eap-pm-list/2018-October/msg00131.html



--
This message was sent by Atlassian Jira
(v7.12.1#712002)