ceylon / ceylon-runtime

DEPRECATED
24 stars 5 forks source link

JDK dependencies in module.xml don't work #46

Open quintesse opened 11 years ago

quintesse commented 11 years ago

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 ceylon/ceylon-module-resolver#70

FroMage commented 11 years ago

Didn't you fix this already?

FroMage commented 11 years ago

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

alesj commented 11 years ago

Do you have a test to reproduce this?

alesj commented 11 years ago

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.

alesj commented 11 years ago

This is what I'm taking about:

... which is already in CMR ...

FroMage commented 11 years ago

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?

quintesse commented 11 years ago

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

alesj commented 11 years ago

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

alesj commented 11 years ago

@FroMage so, yes.

quintesse commented 11 years ago

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

FroMage commented 11 years ago

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

FroMage commented 11 years ago

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

FroMage commented 11 years ago

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?

quintesse commented 11 years ago

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.

gavinking commented 11 years ago

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

Like @lucaswerkmeister's stuff.

alesj commented 11 years ago

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

FroMage commented 11 years ago

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

alesj commented 11 years ago

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

What do you mean by this?

quintesse commented 10 years ago

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.

alesj commented 10 years ago

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.

FroMage commented 10 years ago

Moving to 1.2, unfortunately.