JDK dependencies in module.xml don't work

[CeylonMigrationBot]

[@quintesse] Adding a dependency like:

    <module name="javax.xml" slot="7"/>

to a module.xml file doesn't work, resulting in errors like:

Exception in thread "main" java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at com.redhat.ceylon.launcher.Launcher.run(Launcher.java:86)
    at com.redhat.ceylon.launcher.Launcher.main(Launcher.java:21)
Caused by: org.jboss.modules.ModuleLoadError: Module javax.base:7 is not found in local module loader @279ad355 (roots: /home/tschotan/projects/ceylon/ceylon-dist/dist/repo)
    at org.jboss.modules.ModuleLoadException.toError(ModuleLoadException.java:78)
    at org.jboss.modules.Module.getPathsUnchecked(Module.java:1191)
    at org.jboss.modules.Module.loadModuleClass(Module.java:522)
    at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182)
    at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
    at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
    at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
    at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
    at ceylon.modules.jboss.runtime.AbstractJBossRuntime.createRepository(AbstractJBossRuntime.java:107)
    at ceylon.modules.jboss.runtime.AbstractJBossRuntime.createRepository(AbstractJBossRuntime.java:138)
    at ceylon.modules.jboss.runtime.JBossRuntime.createModuleLoader(JBossRuntime.java:31)
    at ceylon.modules.jboss.runtime.AbstractJBossRuntime.loadModule(AbstractJBossRuntime.java:77)
    at ceylon.modules.api.runtime.AbstractRuntime.execute(AbstractRuntime.java:110)
    at ceylon.modules.Main.execute(Main.java:69)
    at ceylon.modules.Main.main(Main.java:42)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.jboss.modules.Module.run(Module.java:270)
    at org.jboss.modules.Main.main(Main.java:294)
    at ceylon.modules.bootstrap.CeylonRunTool.run(CeylonRunTool.java:162)
    at com.redhat.ceylon.tools.CeylonTool.run(CeylonTool.java:302)
    at com.redhat.ceylon.tools.CeylonTool.execute(CeylonTool.java:265)
    ... 6 more

Also see discussion on #4732

[Migrated from ceylon/ceylon-runtime#46]

[CeylonMigrationBot]

[@FroMage] Didn't you fix this already?

[CeylonMigrationBot]

[@FroMage] Ah no I guess not. Well, unless @alesj can fix this today we'll have to live without it.

[CeylonMigrationBot]

[@alesj] Do you have a test to reproduce this?

[CeylonMigrationBot]

[@alesj] javax.xml::7 -- this is Ceylon only notion.
Before you get into CeylonModuleLoader you cannot know about this.

The way you solve this is to have so called "system" module,
which exposes this package(s).

Let me check if we have something like that already.

[CeylonMigrationBot]

[@alesj] This is what I'm taking about:

• https://github.com/ceylon/ceylon-runtime/blob/master/dist/repo/com/redhat/ceylon/module-resolver/_version_/module.xml#L38

... which is already in CMR ...

[CeylonMigrationBot]

[@FroMage] OK, so you're saying this issue is only for our modules, not for other modules loaded by ceylon code that will have module.xml files?

[CeylonMigrationBot]

[@quintesse]
@alesj It's a Ceylon-only notion, but we'd like it integrated somehow with the runtime. Otherwise we'll have two different systems: people can do import java.base "7" in module.ceylon files, but cannot do the same in module.xml or module.properties files.

The class com.redhat.ceylon.cmr.api.JDKUtils has all the functions necessary to look up the packages belonging to a modules name like java.base.

[CeylonMigrationBot]

[@alesj] Runtime, CMR, etc also uses JBoss Modules to "assemble" itself -- but using only default JBoss Modules things, pretty much similar to Wildfly. Hence it only knows default module.xml stuff.

Whereas Ceylon modules are loaded by custom ModuleLoader, CeylonModuleLoader.
Where the imports / dependencies come from doesn't matter; can be ceylon.import, module.xml, module.properties, etc
Any Ceylon module will understand 'java.base 7'.

To have this before, you would have a chicken-n-egg problem. ;-)

[CeylonMigrationBot]

[@alesj]
@FroMage so, yes.

[CeylonMigrationBot]

[@quintesse] Well the JDKUtils are completely independent from Ceylon, so I don't see why the same way that we have our own module.properties reader we couldn't have our own XML reader that just turns an import like java.base/7 into the appropriate ExportPath invocations. (not saying we can do it now, it might take some time, but I don't see why it can't be done).

[CeylonMigrationBot]

[@FroMage] OK, then fair enough, this is not so important if it only applies to our bootstrap modules.

[CeylonMigrationBot]

[@FroMage] Though perhaps it messes things up for ceylon modules that import our bootstrap modules?

[CeylonMigrationBot]

[@FroMage] As in, the Ceylon module that imports one of our bootstrap module, will look at its shared imports, and where it should see something like java.base/7 it will see what?

[CeylonMigrationBot]

[@quintesse] No, it won't see those because we don't have them defined. That's why it's a less than ideal solution what we have now. Nothing really major I think, but not really correct either.

[CeylonMigrationBot]

[@gavinking]

Though perhaps it messes things up for ceylon modules that import our bootstrap modules?

Like @lucaswerkmeister's stuff.

[CeylonMigrationBot]

[@alesj] It shouldn't mess things up imo, as the class(loader) should be the same -- the system classloader.

[CeylonMigrationBot]

[@FroMage] I mean, they won't see that the modules depend on JDK stuff, but this slips to 1.1 anyways.

[CeylonMigrationBot]

[@alesj]

they won't see that the modules depend on JDK stuff

What do you mean by this?

[CeylonMigrationBot]

[@quintesse]

What do you mean by this?

It means that if you ask for the module's dependencies "javax.xml/7" won't be part of it.

[CeylonMigrationBot]

[@alesj] It depends who uses this module.xml.
If it's JBoss Modules directly, then you need to use that system export feature -- see CMR' module.xml in Runtime.
If it's Ceylon, then it should work, as the CeylonModuleLoader has those semi-hard coded.

[CeylonMigrationBot]

[@FroMage] Moving to 1.2, unfortunately.