Re: [wildfly-dev] Module slots may be deprecated
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