Support Maven modules in Herd

[jvasileff]

This request is to replace the current support for "legacy jars" in Herd with full support for serving actual maven artifacts, including pom.xml.

As far as I can tell, there are a two main problems with the current (legacy jar) approach.

First, repackaged maven modules are seen as distinct from their maven equivalents. For instance, org.slf4j.api "1.6.1" and "org.slf4j:slf4j-api" "1.6.1" refer to the same class files, but are not seen as the same by the module resolver. This is sure to cause problems as a module may import the Herd version, but also import some other module (Herd or otherwise) that imports the maven version. This may result in duplicate or incorrect classes occurring in the classpath today (if the versions are diff), and will break things like ceylon/ceylon-spec#1134 in the future.

Now, it does appear that in some cases, modules like org.hsqldb.hsqldb "2.3.1" and "org.hsqldb:hsqldb" "2.3.1" are seen as equivalent, but inconsistently and in ways that I don't fully understand.

Second, any restating of module metadata from pom.xml to something like module.xml runs the risk of losing or altering information, which may cause breakages. The effective metadata for org.hsqldb.hsqldb "2.3.1" should be identical, regardless of the source - Herd, aether, etc. There are many reasons for this, but one obvious case is that if you upgrade to a new version 2.3.2, either explicitly or through some version resolution mechanism, you shouldn't expect breakages or other changes due to the fact that you may now be using a maven repo as the source, instead of Herd.

It is an appealing concept to have Herd modules be higher quality/cleaned up versions of their maven equivalents. But this would only work if maven integration (aether) were abandoned, and I don't think that is even close to feasible - there's no way that the maven universe can be duplicated and kept up to date on Herd. And, of course, cleaned up is very subjective.

[jvasileff]

To put this in real terms:

I’ve played around with ceylon.logging integrations for Log4j, slf4j, etc. But what should the dependencies for these integration libraries be? Clearly the maven versions, e.g. "org.slf4j:slf4j-api" "1.6.1”, since that’s what other Java libraries will list as a dependencies.

But then, It would be awkward to upload a slf4j-ceylon-integration module to Herd, since anyone using it would have to enable aether. And, of course, any application that also imports the Herd version of slf4j will break in strange ways.

[gavinking]

Yeah, I agree. Actually it's something I've proposed before: that Herd be able to act as a proxy for a maven repo. I forget what @FroMage had to say in response to that at the time.

[FroMage]

I don't think we should proxy Maven Central, for various reasons including time to implement and costs in bandwidth. But your problem really is ceylon/ceylon-module-resolver#59. Note that Herd currently allows dependencies to be resolved from Maven Central without requiring them to be on Herd.

[jvasileff]

Ok, yeah, implementing those items would cover these concerns.

Herd currently allows dependencies to be resolved from Maven Central

So it seems this should be required by policy, today. I know there would be a usability hit in some cases (requiring aether), but at least it would be correct.

For core dependencies, like those of ceylon.language and ceylon.sdk, perhaps they should be on Herd, but with altered Java package names, as is done in the JDK and elsewhere.

[FroMage]

Closing as Maven modules are now required to contain : and Herd supports resolving them from Maven Central.