Open Baccata opened 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
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.
@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 :