Add support for importing OSGi modules

[luolong]

Now that ceylon/ceylon-compiler#1456 has added support for generating OSGi meta-data of the module dependencies, we need some way to declare dependencies on non-Ceylon OSGi modules.

There are couple of different use cases:

• For the core OSGi Core and Compendium specification apis some sort of meta-import just like we do for java.* packages makes sense.
• Adding dependencies to 3rd party OSGi bundles available in remote (or local) bundle repositories.

[FroMage]

Not only that, but I'd like an API which, given a ZipFile (containing a .jar) and a module name/version can give me a descriptor of the module (name,version,type), and its (unresolved) dependencies (name,version,shared,optional) that would load dependencies in that order:

• module/name/module_.class for Ceylon modules
• META-INF/jbossmodules/module/name/version/module.properties for JBoss modules
• META-INF/jbossmodules/module/name/version/module.xml for JBoss modules
• META-INF/maven/module/name/pom.xml for Maven modules
• META-INF/MANIFEST.MF (or wherever the hell it's stored) for OSGi modules

A stub of this API is available as DependencyResolver in the CMR but it only works for JBoss modules ATM.

You think you can do that @alesj?

[FroMage]

That's clean up my ceylon/ceylon.language#370 a lot.

[alesj]

@FroMage so you want to inspect the contents of the .zip for those descriptors?
As atm we only check this if they are "next" (not inside) to the module.
(well for Ceylon module_.class we do check inside .car)

btw: do we already have some .zip --> JBoss Modules module mechanism?

[FroMage]

Yes, inside, because this will be used to load module descriptors from the classpath, where every jar is in the same folder. In that case we can't have external descriptors because they would all have the same name, and it just doesn't happen in practice.

As for the JBoss Modules descriptor in jars, I add them during the build to our distrib repo jars under META-INF/jbossmodules/module/name/version/module.xml.

[alesj]

@FroMage why the long path?
Why not just META-INF/jbossmodules/module.xml ?

[alesj]

Yes, inside, because this will be used to load module descriptors from the classpath, where every jar is in the same folder.

Will you know when you're gonna read from flat classpath vs.per-module directory?

[FroMage]

The long path is to make it possible to have modules in a directory tree. Classpath is jar or folder, and if you have more than one module in the folder then we need to make the module descriptor path unique.

[FroMage]

Well, if we're in a repo structure we have either external descriptors (for jboss modules) or internal if missing (or if ceylon, maven, osgi). And the new API I ask for would be for jars specifically, it takes a ZipFile as input. Naturally it'd also be nice if the repo part of the CMR would load OSGi and internal pom.xml files too if the other descriptors are missing, so it may use this API somehow.

[alesj]

@FroMage I added this: https://github.com/alesj/ceylon-module-resolver/tree/desc1
Would this work?
(I can then work on the OSGi and pom.xml)

[FroMage]

It does look like what I had in mind.

[alesj]

@FroMage I've added simple Maven and OSGi resolvers:

• alesj@e4daad3

Feel free to test and merge and etc ...

[FroMage]

OK thanks.

[FroMage]

Why the hell is this in your repo and not the Ceylon organisation's? :(

[alesj]

What's the problem if this is there? Merge it. ;)

On Jun 19, 2014, at 17:30, Stéphane Épardaud [email protected] wrote:

Why the hell is this in your repo and not the Ceylon organisation's? :(

—
Reply to this email directly or view it on GitHub.

[FroMage]

So, I've tested it and it seems that rather than just reading the pom.xml file, our resolver will fetch artifacts from the Maven repos and bitch if they don't exist. That's not what I want here: I want the dependencies name/version and that's it, since they are supposed to be in the classpath somewhere. Can we get a version like that?

[FroMage]

I couldn't find how to make aether do that.

[quintesse]

@FroMage is it possible to merge @alesj 's changes now without the change you ask for? He has included some other fixes in that branch that I'm waiting for.

[FroMage]

Yes, OK I'll merge it as-is for now.

[quintesse]

Ok thanks!

[FroMage]

Sorry, I can't commit yet, the tests don't pass, there's something failing wrt maven resolution. Hopefully Monday.

[alesj]

rather than just reading the pom.xml file, our resolver will fetch artifacts from the Maven repos and bitch if they don't exist

Ah, I see.
Hmmm, @kpiwko, is there a way to configure this?
All we need is just to read the info, not to try and resolve the thing.

[FroMage]

I have merged this, though there's an issue remaining with Maven resolving.

[FroMage]

So leaving open until we fix it.

[kpiwko]

I miss use case here: you are trying to just parse the top level pom? Because Aether needs to resolve pom.xml file(s) of transitive deps in order to build effective POM. In case you want just to parse pom.xml, Resolver does not support it. I'm not sure whether that could effectively be done via Aether.

I can check if that would be possible to skip artifact downloads and download just metadata. If that would help you, please file a FR in https://issues.jboss.org/browse/SHRINKRES.

[FroMage]

I think we only want to parse the pom, definitly not download or validate the presence/absence of any module in any repo.

[alesj]

Yes, we just need to grab the info out of the pom.xml.
W/o trying to do anything else; while not complaining on any missing artifact, going online, etc

[quintesse]

Agreed, ideally the resolver would never cause any network requests as we're only interested in what kind of dependencies are directly specified in the POM itself.

[kpiwko]

How far you need to go with direct dependencies? Would pom.xml files have any parent? Would they have dependencyManagement section? Versions managed via properties?

[FroMage]

Ah, good questions. Those are poms we find in jars. Are they already resolved/substituted or just lame copies of the build pom?

[FroMage]

Moving to 1.2, unfortunately.