You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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.
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.
@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)]?
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.pomI 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 :
The text was updated successfully, but these errors were encountered: