search

ceylon / ceylon-module-resolver

DEPRECATED
Apache License 2.0
23 stars 9 forks source link

Rationalise dependency resolution mechanism in Java distro modules #70

Closed akberc closed 11 years ago

akberc commented 11 years ago

As Ceylon approaches 1.0 and the toolset is mostly stable, can the distro modules (which show up in the IDE repo explorer to be added, but cannot be added) not have the JBoss specific module.xml as the sole dependency resolution mechanism?

For example, Ceylon or Herd will never be aware of javax.xml.stream.api which is a purely JBoss meta-package.

So, one suggestion is -

This will allow much quicker development of tools and frameworks and should not negatively affect anything.

gavinking commented 11 years ago

@akberc I don't understand what you're saying here. (Probably others do, but I don't.)

akberc commented 11 years ago

Ok. Modules from system repo show up in IDE repo explorer to be added. When added, the module.xml dependencies cause errors.

On 7 Oct 2013 10:02, "Gavin King" notifications@github.com wrote:

@akberc https://github.com/akberc I don't understand what you're saying here. (Probably others do, but I don't.)

— Reply to this email directly or view it on GitHubhttps://github.com/ceylon/ceylon-module-resolver/issues/70#issuecomment-25793636 .

quintesse commented 11 years ago

I think this should be investigated as a CMR problem. It's not something specific to the IDE I guess.

akberc commented 11 years ago

Yes. That was just to illustrate.

I suggested a precedence: CMR checks module.ceylon, then module.properties, then module.xml. This way module.xml can remain JBoss specific if needed.

It is only maven-support and compiler that are problems I think.

On 7 Oct 2013 10:23, "Tako Schotanus" notifications@github.com wrote:

I think this should be investigated as a CMR problem. It's not something specific to the IDE I guess.

— Reply to this email directly or view it on GitHubhttps://github.com/ceylon/ceylon-module-resolver/issues/70#issuecomment-25794787 .

quintesse commented 11 years ago

Yes. That was just to illustrate

Sorry yes, for some reason I thought I'd seen this in the eclipse issue list.

This way module.xml can remain JBoss specific if needed.

It's not JBoss specific, it's what the JBoss Modules support that our module system depends on and it's needed to support legacy libraries. The .xml and .properties are just two ways to do this (.properties being simpler but much more limited). We just have to make this work correctly.

akberc commented 11 years ago

Thanks. :) At least system repo modules will be there.

Just thinking aloud : The runtime container is needed to run and not to compile. So maybe properties for compile and xml for run.

Pls update if it is doable for 1.0

On 7 Oct 2013 10:35, "Tako Schotanus" notifications@github.com wrote:

Yes. That was just to illustrate

Sorry yes, for some reason I thought I'd seen this in the eclipse issue list.

This way module.xml can remain JBoss specific if needed.

It's not JBoss specific, it's what the JBoss Modules support that our module system depends on and it's needed to support legacy libraries. The .xml and .properties are just two ways to do this (.properties being simpler but much more limited). We just have to make this work correctly.

— Reply to this email directly or view it on GitHubhttps://github.com/ceylon/ceylon-module-resolver/issues/70#issuecomment-25795450 .

quintesse commented 11 years ago

So maybe properties for compile and xml for run.

I don't know why you would want to do that? Anyway, it doesn't seem like a good idea, then you'd need both files all of the time, which means more maintenance work and an increased possibility of mistakes.

quintesse commented 11 years ago

@akberc Can you give me details of how to reproduce your problem with importing "system modules"? I just made a test project that imports the JBoss Jandex module and uses it and it seems to work just fine.

akberc commented 11 years ago

There aren't that many in the system repo :)

From OP & referenced issues: maven-support. If it is not meant to be used, it should be in lib or 'hidden cmr repo'. Just kidding!

On 7 Oct 2013 12:42, "Tako Schotanus" notifications@github.com wrote:

@akberc https://github.com/akberc Can you give me details of how to reproduce your problem with importing "system modules"? I just made a test project that imports the JBoss Jandex module and uses it and it seems to work just fine.

— Reply to this email directly or view it on GitHubhttps://github.com/ceylon/ceylon-module-resolver/issues/70#issuecomment-25801972 .

quintesse commented 11 years ago

So looking at the linked issues (which you didn't mention in the OP) the real problem is this:

ceylon.build/source/ceylon/build/tasks/repo/module.ceylon:5: error: cannot find module artifact javax.xml.stream.api-main.jar
    shared import 'com.redhat.ceylon.maven-support' "main";
    ^
    - dependency tree: ceylon.build.tasks.repo/0.1 -> com.redhat.ceylon.maven-support/main -> javax.xml.stream.api/main

So why didn't you just say that instead of all the stuff you wrote? ;)

I'm going to ask @alesj if he can chip in on this.

Ales, what I'm seeing is that treating the JDK dependencies as virtual modules causes this. The typechecker has code that validates the dependency tree and it sees what it thinks is a real module and asks for it but because it doesn't really exist it doesn't get any results and decides the dependency is missing.

Any idea what to do about this? (The easiest way is to go back to just putting those dependencies with the artifacts again instead of using those virtual modules, but I wanted to ask you first to see if there's another way)

akberc commented 11 years ago

Thank you. I need some build tasks that involve Maven. Just want to know if org.sonatype.aether.* form maven-support will be available as a regular module or not. If not, we will have to do a bit more work with the org.eclipse.aether.* - the new incarnation of aether.

Yeah - I wrote an essay - sorry. This is not like IDE where the symptom is visual. In the past, if I just write the symptom, then we have to discuss all angles, and all possible reasons why it is not an issue. This way, we still have to discuss, so I'll stick to the short mode again.

I know what it is like to be on the receiving end of issues, but the more issues we can at least point out -whether we fix them for 1.0 or for later - the better. Consider me a tester :)

quintesse commented 11 years ago

I'm not sure if they'll be available as regular modules. At some point I guess they will be. Or maybe Ales know if there is a way to make 1 jar file appear as several modules, that way we could treat the maven-support jar as the bundle of modules it actually is.

FroMage commented 11 years ago

I think we should drop the javax modules from our bootstrap repo and replace the dependencies with the proper virtual java.XXX/7 imports. IIRC javax.xml.stream is defined in one of them.

FroMage commented 11 years ago

Yes they're in javax.xml/7.

quintesse commented 11 years ago

Hmmm, I hadn't thought of that! I'll try to see if that works.

quintesse commented 11 years ago

It almost works. The compiler swallows it hook, line and sinker, but the runtime isn't fooled yet.

quintesse commented 11 years ago

Ok, I at least made things work, but not in the way Stef suggested so I'm going to open a separate issue on the runtime for it because I think it should work. Closing.