textual module descriptor inside car files

This document argues against compiling module descriptors to a binary format.

Now, we already generate maven- and OSGi-format metadata inside .cars, but those aren’t really “native” formats for us. I wonder if there would be some advantage to additionally generating a JBoss modules modules.xml file (or something else, if that doesn’t work for us).

I guess it would make it easier for tools to get at module metadata.

WDYT, @FroMage, @quintesse?

[quintesse]

WARNING: Long rant that should not really be here because it got way off-topic. But this issue is what triggered its writing. We can move it to its own issue if people think it’s worth it or it can be deleted if people think it’s obnoxious drivel. Anyway…

This issue reminds me of something that I argued for only a short while ago (a couple of weeks at most) on the Ceylon channel. It’s a conclusion I arrived at trying to think of a way to make Ceylon more easily integrated with existing Java projects and to get rid of as many (perceived) obstacles to better adoption of Ceylon in environments where Java is, and will stay for an unforeseen time, the main development language.

So the first thing I realized is the fact that Ceylon hard-codes all details of dependencies goes completely against the idea that code should not contain any build-specific information. Why do we specify in code (!) that the same code depends on a certain version of a certain Maven module for example?

What do we care where the dependency comes from? As long as it’s there. And when an end-user of our module wants to change the location where the dependency comes from or wants to use a different version they have to deal with a completely different “shadow” module descriptor: the overrides.xml. (Even if we would at some point make the overrides file use Ceylon syntax it would still be a separate, non-compiled, file… so why not make it a separate file to begin with?).

In general I think that “imposing” module dependencies from within the Ceylon framework might have been a mistake. As seen by the difficulties that arise when trying to use Ceylon in combination with systems that already come with their own dependency management, like Maven and Gradle. In those cases we’re always left with something that doesn’t really map well.

Separating those responsibilities into separate tools would allow us to treat the “flat classpath”, that we now have as a separate tool, as something normal: as long as all necessary dependencies are on the classpath the compiler and the runtime would run just fine. JBoss Modules would become a special “nice to have” option that Ceylon comes with by default, but by no means necessary.

In fact with the latest improvements in Maven support where we can now properly push to Maven repositories I’m wondering if we shouldn’t just phase out The Herd, What good does it do us to have a whole separate ecosystem? Any really interesting libraries (the ones that people would want to use from other languages as well) should be in Maven anyway and all our own modules are now available there as well. This duplication doesn’t do us any good I think. (Of course we’d have to do this for JS as well, publishing everything to NPM)

I feel that if we want to make progress in convincing people to convert to Ceylon we must make it extremely easy to just throw some Ceylon into any old Java project. We did a lot of great work lately in improving the Java-Ceylon interop at the language level and now I think the same should be done at the build level.

I envision a situation where somebody working on a Java project could decide to write some new section of the code in Ceylon. I’m specifically saying “section” here and not “module”, because I don’t want to force that person into having to accept Ceylon’s module system. Do that and you’ll make their life more difficult. Suddenly they’ll have to explain why they decided to introduce this foreign module with it’s own class loaders and it’s own way of dependency handling etc. What they need is the ability to introduce Ceylon into the code the same way they’d introduce a new library: add some dependency to their Maven or Gradle build file and off they go coding and running Ceylon! (The fact that we only have a small required language module makes this a no-brainer)

I can even imagine that this might mean that we don’t compile by default to .car files anymore. Or at all! It’s another decision that I feel has set us more apart from the Java ecosystem than was good for us. Tools tend to not understand .car files by default and even we rename them to .jar for example when using the “fat-jar” and similar commands.

In essence I think Ceylon should go back to basics and embrace the ecosystems it’s part of and stop trying to set up its own. Hopefully more people will then embrace Ceylon in return.

[jvasileff]

@quintesse it should be no surprise that I fully agree with you. I have felt this way since first trying to use Ceylon.

A few thoughts:

• The success of the language should not be bound by the success of its module system
• The language and its module system should be orthogonal concerns. If a module system is offered, it should compete on equal footing with third party solutions, and importantly, the language should not be implemented in a way that favors the first-party module system to the detriment of others (with others to include nothing at all, as in, a directory full of jars or class files.)
• The Ceylon project’s primary contribution should be the very cool and very well liked language, not a module system. Attempting to build a module system takes resources away from work on the language, and needlessly duplicates efforts of external projects.
• After multiple years, the worst predictions have proven true: 1) interoperability with the broader Java ecosystem is still a huge challenge, and 2) the module system remains incomplete, missing key features such as version resolution. What does work: recompiling the universe of all Ceylon modules after every 0.1 release, and very quickly and conveniently getting started with simple “learner” type applications.
• The module system has not helped towards the goal of building a rich ecosystem of reusable software components. In fact, I fully believe the contrary is true. We do know, however, that despite valid complaints and varying levels of distaste, the Maven module system has proven to be sufficient to foster the growth of a massive ecosystem of reusable components.

Of course, the above was written with the JVM in mind.