search

eclipse-archived / ceylon

The Ceylon compiler, language module, and command line tools
http://ceylon-lang.org
Apache License 2.0
399 stars 62 forks source link

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

Open CeylonMigrationBot opened 11 years ago

CeylonMigrationBot commented 11 years ago

[@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 commented 11 years ago

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

CeylonMigrationBot commented 11 years ago

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

CeylonMigrationBot commented 11 years ago

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

CeylonMigrationBot commented 11 years ago

[@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 commented 11 years ago

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

... which is already in CMR ...

CeylonMigrationBot commented 11 years ago

[@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 commented 11 years ago

[@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 commented 11 years ago

[@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 commented 11 years ago

[@alesj] @FroMage so, yes.

CeylonMigrationBot commented 11 years ago

[@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 commented 11 years ago

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

CeylonMigrationBot commented 11 years ago

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

CeylonMigrationBot commented 11 years ago

[@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 commented 11 years ago

[@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 commented 11 years ago

[@gavinking]

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

Like @lucaswerkmeister's stuff.

CeylonMigrationBot commented 11 years ago

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

CeylonMigrationBot commented 11 years ago

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

CeylonMigrationBot commented 11 years ago

[@alesj]

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

What do you mean by this?

CeylonMigrationBot commented 10 years ago

[@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 commented 10 years ago

[@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 commented 10 years ago

[@FroMage] Moving to 1.2, unfortunately.