cvogt / cbt

CBT - fun, fast, intuitive, compositional, statically checked builds written in Scala
Other
488 stars 60 forks source link

Handle dependency import scope #558

Open Baccata opened 6 years ago

Baccata commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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: https://github.com/cvogt/cbt/pull/559

Let me know if I can help with something.

Baccata commented 6 years ago

@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)]?