5
Opis strategii o nazwie scalony o nazwie zmienił nazwę brzmiał, jakby mógł pozwolić na coś podobnego do operacji cieniowania z maven-shade-plugin, która przeniesie klasy i ich odniesienia, aby zezwolić na zarządzanie niekompatybilnymi wersjami bibliotek.Czy w przypadku sbt-assembly należy przeprowadzić przeniesienie klas w stylu "maven-shade-plugin"?
Czy byłoby właściwe, aby montaż sbt wykonywał tę funkcję?
Użyłem następującej strategii scalania, aby spróbować użyć zmiany nazwy jako mechanizmu relokacji, ale gdy pasuje do wszystkich plików, przechodzi przez nie prosto (co jest spójne z przeglądaniem kodu).
assemblyMergeStrategy in assembly := { s =>
s match {
case PathList("com", "clearspring", "analytics", _*) => {
println("match_cs: " + s)
MergeStrategy.rename
}
case x => {
println("x: " + x)
val oldStrategy = (assemblyMergeStrategy in assembly).value
oldStrategy(x)
}
}
}
widzę część ta zostanie odebrane [tutaj] (http://stackoverflow.com/questions/24596914/sbt-assembly-rename-class-with-merge-conflicts-shade), które sbt- montaż nie zacienia się. Który opuszcza część "czy byłoby to właściwe"? – Traveler
Czy to kiedykolwiek działało? Jestem w tej samej sytuacji ... – acidghost
@acidghost: Nie, na mój link, sbt-assembly nie dokona tej transformacji. Po prostu musisz małpować z wykluczeniem sbt i są one bardzo zależne od bieżącego zestawu zależnych słoików. – Traveler