[jira] [Assigned] (SPARK-1844) Support maven-style dependency resolution in sbt build
[ https://issues.apache.org/jira/browse/SPARK-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Apache Spark reassigned SPARK-1844: --- Assignee: Josh Rosen (was: Apache Spark) > Support maven-style dependency resolution in sbt build > -- > > Key: SPARK-1844 > URL: https://issues.apache.org/jira/browse/SPARK-1844 > Project: Spark > Issue Type: Improvement > Components: Build >Reporter: Patrick Wendell >Assignee: Josh Rosen > > [Currently this is a brainstorm/wish - not sure it's possible] > Ivy/sbt and maven use fundamentally different strategies when transitive > dependencies conflict (i.e. when we have two copies of library Y in our > dependency graph on different versions). > This actually means our sbt and maven builds have been divergent for a long > time. > Ivy/sbt have a pluggable notion of a [conflict > manager|http://grepcode.com/file/repo1.maven.org/maven2/org.apache.ivy/ivy/2.3.0/org/apache/ivy/plugins/conflict/ConflictManager.java]. > The default chooses the newest version of the dependency. SBT [allows this > to be > changed|http://www.scala-sbt.org/release/sxr/sbt/IvyInterface.scala.html#sbt;ConflictManager] > though. > Maven employs the [nearest > wins|http://techidiocy.com/maven-dependency-version-conflict-problem-and-resolution/] > policy which means the version closes to the project root is chosen. > It would be nice to be able to have matching semantics in the builds. We > could do this by writing a conflict manger in sbt that mimics Maven's > behavior. The fact that IVY-813 has existed for 6 years without anyone doing > this makes me wonder if that is not possible or very hard :P -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org For additional commands, e-mail: issues-h...@spark.apache.org
[jira] [Assigned] (SPARK-1844) Support maven-style dependency resolution in sbt build
[ https://issues.apache.org/jira/browse/SPARK-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Apache Spark reassigned SPARK-1844: --- Assignee: Apache Spark (was: Josh Rosen) > Support maven-style dependency resolution in sbt build > -- > > Key: SPARK-1844 > URL: https://issues.apache.org/jira/browse/SPARK-1844 > Project: Spark > Issue Type: Improvement > Components: Build >Reporter: Patrick Wendell >Assignee: Apache Spark > > [Currently this is a brainstorm/wish - not sure it's possible] > Ivy/sbt and maven use fundamentally different strategies when transitive > dependencies conflict (i.e. when we have two copies of library Y in our > dependency graph on different versions). > This actually means our sbt and maven builds have been divergent for a long > time. > Ivy/sbt have a pluggable notion of a [conflict > manager|http://grepcode.com/file/repo1.maven.org/maven2/org.apache.ivy/ivy/2.3.0/org/apache/ivy/plugins/conflict/ConflictManager.java]. > The default chooses the newest version of the dependency. SBT [allows this > to be > changed|http://www.scala-sbt.org/release/sxr/sbt/IvyInterface.scala.html#sbt;ConflictManager] > though. > Maven employs the [nearest > wins|http://techidiocy.com/maven-dependency-version-conflict-problem-and-resolution/] > policy which means the version closes to the project root is chosen. > It would be nice to be able to have matching semantics in the builds. We > could do this by writing a conflict manger in sbt that mimics Maven's > behavior. The fact that IVY-813 has existed for 6 years without anyone doing > this makes me wonder if that is not possible or very hard :P -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org For additional commands, e-mail: issues-h...@spark.apache.org