[wildfly-dev] Module slots may be deprecated

[Sanne Grinovero]

I'm a bit sad from this, as the notion of "slot" was very useful, but
I understand that the alternatives will work the same. So +1 for your
proposal, if that helps with Jigsaw.. however beyond how things are
represented, I'd hope we will be able to still evolve the notion of
"slots" as a concept, for example to one day be able to validate that
it's illegal for a user to depend on both "org.hibernate:4.1" and
"org.hibernate:5.0", just to name one.

About the transition period and the idea of "escaping" the ":"
character in the name: maybe it would be better to avoid such escaping
so that we could already make the transition on some projects, without
enforcing the new naming scheme on all of them?

It might be useful to start publishing some modules with e.g.
name="org.hibernate.search-engine:6.0.0.Final" and yet be able to
depend on this via the couple { name="org.hibernate.search-engine",
slot="6.0.0.Final" } from another project:
we're having at this point several projects which depend on each other
in a complex matrix, with different release times and possibly
targeting different WildFly versions and different product builds.

Support for aliases will stay I hope? Those have been extremely useful too.

Thanks!
Sanne



On 22 June 2016 at 07:18, Sebastian Laskawiec <slaskawi at redhat.com> wrote:
> In Infinispan we actually use both approaches (with and without slots).
>
> We use slots when creating modules for WF/EAP [1][2]. The idea is to copy
> them directly into the modules directory and use in your deployment. Note
> that we want to be able to put multiple versions there (like ispn-8.2 and
> ispn-9.0 for example).
>
> The default slot is used for WF Clustering and when we create our own HotRod
> server [3].
>
> I think those changes look fine and everything should still work as it did
> before.
>
> Thanks
> Sebastian
>
> [1] https://github.com/infinispan/infinispan/tree/master/as-modules/embedded
> [2] https://github.com/infinispan/infinispan/tree/master/as-modules/client
> [3]
> https://github.com/infinispan/infinispan/tree/master/server/integration/feature-pack
>
> On Wed, Jun 22, 2016 at 1:13 AM, Scott Marlow <smarlow at redhat.com> wrote:
>>
>> This might impact the second Infinispan module name that OGM will likely
>> use for remote Infinispan access, since the base module name was going
>> to be identical to the WildFly infinispan module, with the slot name
>> used to distinguish between the different Infinispan modules.
>>
>> The WildFly JPA container currently supports a persistence unit hint
>> (jboss.as.jpa.providerModule=name) to specify a non-default persistence
>> provider.  This is probably used by some applications.  Recently, Sanne
>> also mentioned some use cases for Hibernate Search applications to
>> depend on jboss.as.jpa.providerModule as well.  Applications that
>> currently include the slot with "jboss.as.jpa.providerModule", could
>> need changes when the slot support is removed.
>>
>> Have you created a WFLY tracking issue yet for deprecating module slots?
>>   I'm thinking that the JPA container should check if
>> "jboss.as.jpa.providerModule" specifies a slot and if yes, log a
>> deployment warning about the application referencing a slot that needs
>> change to not require the slot.  We should also create a dependent jira
>> for the JPA container change to log the warning.
>>
>> The JPA container also supports a similar "jboss.as.jpa.adapterModule"
>> persistence unit property but I don't think that is used much, if at
>> all.  Applications that specify a slot in
>> "jboss.as.jpa.adapterModule=name", should also get a deployment warning
>> logged about deprecated slot usage.
>>
>> The other related change, will be the convention that we use for legacy
>> Hibernate module names, which use the module slot as well.
>>
>>  From a compatibility point of view, of future WildFly versions, with
>> WildFly 10, when we pull the switch for removing module slot support
>> completely, I'm not really sure if that breaks application compatibility
>> or more that the user needs to move the system/user modules that use
>> slot, to a non-slot module.  For example, if the application persistence
>> unit specifies "jboss.as.jpa.providerModule=org.hibernate:4.1", then the
>> user will need to move their Hibernate 4.x jars into a different folder.
>>
>> Another thing, I'm not sure if in that future WildFly version that
>> removes slots completely, if the JPA container, should translate the
>> "jboss.as.jpa.providerModule=org.hibernate:4.1" into ModuleName + slot,
>> with the colon separator removed, so
>> "jboss.as.jpa.providerModule=org.hibernate:4.1" becomes
>> ""jboss.as.jpa.providerModule=org.hibernate4.1", which could cause a
>> deployment error until the user moves the Hibernate jars from
>> "org.hibernate:4.1" to "jboss.as.jpa.providerModule=org.hibernate4.1"
>> (in the user or system module folder).
>>
>> Scott
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev