Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle dependency import scope #558

Open
Baccata opened this issue Sep 10, 2017 · 3 comments
Open

Handle dependency import scope #558

Baccata opened this issue Sep 10, 2017 · 3 comments

Comments

@Baccata
Copy link
Contributor

Baccata commented Sep 10, 2017

I was thinking I'd start implementing a docker plugin, by replicating sbt-native-packager, which uses spotify's docker client.

Spotify's docker client depends on jersey-client, the parent of which contains an "import dependency" (see maven's import scope)

As of now, CBT doesn't handle import scopes (ie an import dependency should be replaced by the dependencies contained in the pom it references). I therefore implemented a method to resolve imports which I call in dependencyVersions (see here).

Thanks to that, the resolver goes a bit further, but crashes here because it can't resolve javax.el.version in this pom : http://repo1.maven.org/maven2/org/glassfish/hk2/hk2-bom/2.4.0-b25/hk2-bom-2.4.0-b25.pom

I have no idea where this property is supposed to come from (and therefore how the resolver should behave). If somebody can unblock me and explain where that property is supposed to come from, I might be able to fix it and submit a PR against cbt.

Here's the build I'm testing against :

import cbt._

class Build(val context: Context) extends Plugin with Ensime {
  override def dependencies =
    super.dependencies ++
    Resolver( mavenCentral, sonatypeReleases ).bind(
      MavenDependency( "org.glassfish.jersey.core", "jersey-client", "2.22.2")
    )
}
@Baccata
Copy link
Contributor Author

Baccata commented Sep 11, 2017

Okay my logic is faulty, instead of "resolving" the imports recursively, I should amend the current pom's xml by replacing the "imports" by what the referenced pom contains, and then resolve the current pom.

When I have time I'll update and submit a PR

@cvogt
Copy link
Owner

cvogt commented Sep 11, 2017

This is great. Adding support for missing maven features like this will be very helpful.

@Baccata, I turned your branch into a PR for easier comparison: #559

Let me know if I can help with something.

@Baccata
Copy link
Contributor Author

Baccata commented Sep 12, 2017

@cvogt is there ever a case where this getOrElse is triggered ?

I'm hitting a case where there are several artifacts with different groupIds, and therefore the computation of"dependencyVersions" creates a problem of precedence. Would it be possible to make it return Map[(String, String), String] instead of Map[String, (String, String)]?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants