[wildfly-dev] Module slots may be deprecated

[David M. Lloyd]

I'll answer your questions inline.

On 06/22/2016 10:11 AM, Sanne Grinovero wrote:
> 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.

Sounds like a potentially useful feature.  This could be implemented as 
a ModuleLoader policy.

> 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?

Sure, code can transition to using String names and avoid any kind of 
special handling.  Also, I believe that at present the filesystem module 
loader does not support : in names, so it won't have any issue with 
escaping.  Or are you proposing something else?

> 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.

Something of note is that I will also be adding version support.  The 
version string will not have any core function (other than to display 
the correct version in the module stack trace, a new feature of Java 9) 
- in particular it won't be used as part of the module's identification 
for loading modules - but ModuleLoaders can use it for whatever purpose 
they wish (for example the ModuleLoader could generate the version based 
on the module name) including policy enforcement decisions.

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

Yes, though there will be some implementation changes (independently of 
this change) because alias unloading does not presently work properly.

-- 
- DML