Auto-export MVN dependencies

[FroMage]

As shown in ceylon/ceylon-compiler#1100 it can be extremely hard to use maven dependencies since maven doesn't export the imported modules that it exposes in its shared API, which break the Ceylon module contract. When we resolve mvn dependencies, we should scan its jar and see if its shared API (public classes, their supertypes,interfaces, their public methods/fields, inner classes) exposes a class that does not come from its jar, and find out which of its imported modules exposes that class and automatically mark its import as shared.

This is likely to be expensive, but only need to be done once per mvn jar and cached, we can/should also make (cached) indexes of the classes defined in each mvn jar to make this process faster.

WDYT @alesj?

[tombentley]

@FroMage don't we also need to do something like this in ceylon import-jar?

[alesj]

It's doable - I just wrote something similar on bytecode level.

But how do you know from which jar to take the depending class?
Possible issues: plenty of jars to scan, multiple possible jars, which jar version, ...

This can bring more problems then solve them imo.
e.g. magic vs. explicit import

I do agree it's a pita, but once the user knows this can fail,
(s)he can explicitly add the dependency, and it should work.

[FroMage]

But how do you know from which jar to take the depending class?

From the jars in the list of direct imported modules, no? Can this be anywhere else?

[FroMage]

don't we also need to do something like this in ceylon import-jar?

Well, no I guess not because import-jar imports a single jar, we don't have any info about modules, such as we have with Maven modules.

Oh I guess we also have to do this check for JBoss modules defined with module.properties and module.xml.

[tombentley]

Well import-jar could at least warn the users about classes in the public API that are not in that jar, nor in the users default repos. Otherwise users are going to see import-jar exists, use it, see no errors reported but then be surprised when their code doesn't work.

[FroMage]

Yes.

[FroMage]

ceylon/ceylon-compiler#1105

[alesj]

From the jars in the list of direct imported modules, no? Can this be anywhere else?

Yes.
But Maven has this range import / dependency as well ...

[FroMage]

Well, it may have a range, but when we query there must be an option to "select" which imported version was chosen by aether, no?

[FroMage]

So, perhaps this is only something that is needed for compilation, and not at runtime, because @alesj tells me we should not get ClassNotFound exceptions from imported types that leak into public APIs, as long as we don't use them explicitely, and I guess that if we did use them we'd have to import them. Those imported types should be visible to the module that imported them, even if not to others, so resolving should work. So perhaps we can work around that in the compiler too…

[FroMage]

All Maven issues move to 1.0

[FroMage]

Superceded by #81