Module splitting up

I’ve already split some things up:

• com.redhat.ceylon.langtools.classfile from com.redhat.ceylon.compiler.java so that the language module can use it without depending on the compiler. Itself does not depend on anything and is a split of the javac fork.
• com.redhat.ceylon.tool.provider from ceylon.language which removed the dependencies to the compilers and typecheckers from the language module.

We need further splits:

• Remove the tools part of com.redhat.ceylon.common to com.redhat.ceylon.tools, because the language module depends on common but does not need the tools.
• Remove the CMR dependency from the language module. This requires moving a few things from CMR into common.
• Remove jandex dependency. I’m fairly sure we can do what we need with langtools.classfile, although we have to make sure it’s as efficient.
• Remove shrinkwrap from the Maven equation. Aether seems small and only depends on httpclient (already a dependency of sardine) and org.slf4j:jcl-over-slf4j which drags slf4j but we already depend on it (not sure why). That should make the Maven support smaller. And besides our Aether deps is outdated.
• Possibly make our WebDAV CMR provider optional. That would remove dep on sardine, and httpclient (even though it’s used by aether too). We don’t use most of that for Herd and we can easily replace it with the JDK net connections.

Once this is done, we should review the minimal size for language module dependencies and see if we can do further improvements. Splitting the metamodel and serialisation out of it may be useful too, but that means untangling “reified is” out of the metamodel, which may not be very useful since it depends on the model module and I suppose the metamodel is comparatively smaller.

OTOH if we can split subtyping into its own pure-Ceylon independent module (unlikely) it would mean reusability in JS, which is hard ATM.

[jvasileff]

I’m not sure if this is a good idea or not, but FYI: https://github.com/google/guava/wiki/UsingProGuardWithGuava

[FroMage]

Does this mean that support for Java 8 default methods will dramatically reduce the method count?

I suspect so.