निर्भरता समाधान उपकरण शब्दार्थ

निर्भरता समाधान उपकरण

एक निर्भरता रिज़ॉल्वर (बाद में रिज़ॉल्वर के रूप में संदर्भित किया जाता है। लगभग अनुवाद।) या एक पैकेज प्रबंधक एक प्रोग्राम है जो उपयोगकर्ता द्वारा निर्धारित प्रतिबंधों को ध्यान में रखते हुए मॉड्यूल के एक निरंतर सेट को परिभाषित करता है।

बाधाएं आमतौर पर मॉड्यूल नामों और संस्करण संख्याओं द्वारा निर्दिष्ट की जाती हैं। जेवीएम पारिस्थितिकी तंत्र में मावेन मॉड्यूल के लिए, संगठन का नाम (समूह आईडी) भी संकेत दिया जाएगा। इसके अलावा, प्रतिबंधों में संस्करण श्रेणी, बहिष्कृत मॉड्यूल, संस्करण ओवरराइड आदि शामिल हो सकते हैं।

संकुल की तीन मुख्य श्रेणियां OS संकुल (होमब्रे, डेबियन पैकेज आदि) द्वारा दर्शायी गयी हैं।
विशिष्ट प्रोग्रामिंग भाषाओं के लिए मॉड्यूल (CPAN, RubyGem, Maven, आदि) और एप्लिकेशन-विशिष्ट एक्सटेंशन (ग्रहण प्लगइन्स, IntelliJ प्लगइन्स, वीएस कोड एक्सटेंशन)।

रिज़ॉल्वर शब्दार्थ

पहले सन्निकटन में, हम मॉड्यूल की निर्भरता का प्रतिनिधित्व एक डीएजी (निर्देशित एसाइक्लिक ग्राफ, निर्देशित एसाइक्लिक ग्राफ) के रूप में कर सकते हैं।

इस प्रतिनिधित्व को निर्भरता ग्राफ कहा जाता है। दो मॉड्यूल की निर्भरता पर विचार करें:

• a:1.0 c:1.0 पर निर्भर करता है
• b:1.0 c:1.0 और d:1.0 पर निर्भर करता है

 +-----+ +-----+ |a:1.0| |b:1.0| +--+--+ +--+--+ | | +<-------+ | | vv +--+--+ +--+--+ |c:1.0| |d:1.0| +-----+ +-----+ 

यदि मॉड्यूल a:1.0 और b:1.0 पर निर्भर करता है, तो निर्भरता की पूरी सूची a:1.0 , b:1.0 , c:1.0 और d:1.0 । और यह सिर्फ एक ट्री टूर है।

यदि संक्रमणीय निर्भरता संस्करणों की एक श्रृंखला द्वारा निर्दिष्ट की जाती है, तो स्थिति और अधिक जटिल हो जाएगी:

• a:1.0 c:1.0 पर निर्भर करता है
• b:1.0 c:[1.0,2) और d:1.0 पर निर्भर करता है

 +-----+ +-----+ |a:1.0| |b:1.0| +--+--+ +--+--+ | | | +-----------+ | | | vvv +--+--+ +--+------+ +--+--+ |c:1.0| |c:[1.0,2)| |d:1.0| +-----+ +---------+ +-----+ 

या, यदि विभिन्न संस्करण सकर्मक निर्भरता के लिए निर्दिष्ट हैं:

• a:1.0 c:1.0 पर निर्भर करता है
• b:1.0 c:1.2 और d:1.2 पर निर्भर करता है

या, यदि अपवाद निर्भरता के लिए फेंक दिए जाते हैं:

• a:1.0 पर निर्भरता, जो c:1.0 पर निर्भर करता है, c:* को छोड़कर
• b:1.0 c:1.2 और d:1.2 पर निर्भर करता है

विभिन्न रिज़ॉल्वर उपयोगकर्ताओं द्वारा निर्धारित प्रतिबंधों की अलग-अलग व्याख्या करते हैं। मैं ऐसे नियमों को रिज़ॉल्वर के शब्दार्थ कहता हूं।

उदाहरण के लिए, आपको इनमें से कुछ शब्दार्थों को जानना पड़ सकता है:

• अपने स्वयं के मॉड्यूल के शब्दार्थ (आपके द्वारा उपयोग किए जाने वाले निर्माण उपकरण द्वारा निर्धारित);
• आपके द्वारा उपयोग किए जाने वाले पुस्तकालयों के शब्दार्थ (निर्माण उपकरण द्वारा उपयोग किए गए लेखक द्वारा निर्धारित);
• मॉड्यूल के शब्दार्थ जो आपके मॉड्यूल एक निर्भरता (एंड-यूज़र बिल्ड टूल द्वारा परिभाषित) के रूप में उपयोग करेंगे।

JVM पारिस्थितिकी तंत्र में निर्भरता समाधान उपकरण

चूंकि मैं sbt समर्थन करता sbt , मुझे मुख्य रूप से JVM पारिस्थितिकी तंत्र में काम करना होगा।

शब्दार्थ मावेन: निकटतम-जीत

ऐसे ग्राफ़ में जहां निर्भरता का संघर्ष होता है (निर्भरता ग्राफ़ में घटक d कई अलग-अलग संस्करण होते हैं, उदाहरण के लिए d:1.0 और d:2.0 ), मावेन संघर्ष को हल करने के लिए निकटतम-जीत की रणनीति का उपयोग करता है।

निर्भरता को हल करने का संघर्ष - एक प्रक्रिया जो यह निर्धारित करती है कि किसी विरूपण साक्ष्य के किस संस्करण का चयन किया जाएगा अगर निर्भरता के बीच एक ही विरूपण साक्ष्य के कई संस्करण मिलते हैं। मावेन निकटतम परिभाषा का चयन करता है। यानी उस संस्करण का उपयोग करता है जो निर्भरता के पेड़ में आपकी परियोजना के सबसे करीब है।
आप हमेशा प्रोजेक्ट के पीओएम में स्पष्ट रूप से घोषित करके सही संस्करण का उपयोग करने की गारंटी दे सकते हैं। ध्यान दें कि यदि निर्भरता के दो संस्करणों की वृक्ष में समान गहराई है, तो पहले वाले का चयन किया जाएगा। निकटतम परिभाषा का अर्थ है कि निर्भरता के पेड़ में परियोजना के निकटतम संस्करण का उपयोग किया जाएगा। उदाहरण के लिए, यदि A , B और C लिए निर्भरता A -> B -> C -> D 2.0 और A -> E -> D 1.0 रूप C परिभाषित की जाती है, तो, A , D 1.0 निर्माण करते समय उपयोग किया जाएगा, क्योंकि A से D तक का मार्ग E छोटा है ( B और C माध्यम से, लगभग। अनुवाद।)।

इसका मतलब है कि मावेन का उपयोग करके प्रकाशित कई जावा मॉड्यूल nearest-wins शब्दार्थों का उपयोग करके संकलित किए गए थे। उपरोक्त वर्णन करने के लिए, एक साधारण pom.xml बनाएं:

 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.example</groupId> <artifactId>foo</artifactId> <version>1.0.0</version> <packaging>jar</packaging> <dependencyManagement> <dependencies> <dependency> <groupId>com.typesafe.play</groupId> <artifactId>play-ws-standalone_2.12</artifactId> <version>1.0.1</version> </dependency> </dependencies> </dependencyManagement> </project> 

mvn dependency:build-classpath हल किए गए classpath लौटाता है।
यह उल्लेखनीय है कि परिणामी पेड़ com.typesafe:config:1.2.0 का उपयोग करता है, भले ही Akka 2.5.3 com.typesafe:config:1.3.1 रूप से com.typesafe:config:1.3.1 पर निर्भर हो com.typesafe:config:1.3.1 ।

mvn dependency:tree उस दृश्य की पुष्टि देता है:

 [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ foo --- [INFO] com.example:foo:jar:1.0.0 [INFO] \- com.typesafe.play:play-ws-standalone_2.12:jar:1.0.1:compile [INFO] +- org.scala-lang:scala-library:jar:2.12.2:compile [INFO] +- javax.inject:javax.inject:jar:1:compile [INFO] +- com.typesafe:ssl-config-core_2.12:jar:0.2.2:compile [INFO] | +- com.typesafe:config:jar:1.2.0:compile [INFO] | \- org.scala-lang.modules:scala-parser-combinators_2.12:jar:1.0.4:compile [INFO] \- com.typesafe.akka:akka-stream_2.12:jar:2.5.3:compile [INFO] +- com.typesafe.akka:akka-actor_2.12:jar:2.5.3:compile [INFO] | \- org.scala-lang.modules:scala-java8-compat_2.12:jar:0.8.0:compile [INFO] \- org.reactivestreams:reactive-streams:jar:1.0.0:compile 

कई पुस्तकालय पिछड़े संगतता प्रदान करते हैं, लेकिन कुछ अपवादों के साथ प्रत्यक्ष संगतता की गारंटी नहीं है, जो कि खतरनाक है।

अपाचे आइवी के शब्दार्थ: नवीनतम-जीत

डिफ़ॉल्ट रूप से, अपाचे आइवी निर्भरता संघर्ष को हल करने के लिए नवीनतम-जीत की रणनीति का उपयोग करता है।

यदि यह कंटेनर मौजूद नहीं है, तो डिफ़ॉल्ट संघर्ष प्रबंधक सभी मॉड्यूल के लिए उपयोग किया जाता है। वर्तमान डिफ़ॉल्ट संघर्ष प्रबंधक "नवीनतम-संशोधन" है।
नोट: कंटेनर का conflicts आइवी फाइल में से एक है।

संस्करण SBT 1.3.x आंतरिक निर्भरता रिज़ॉल्वर अपाचे आइवी है। पहले इस्तेमाल किया गया pom.xml एसबीटी में थोड़ा और संक्षेप में वर्णित है:

 ThisBuild / scalaVersion := "2.12.8" ThisBuild / organization := "com.example" ThisBuild / version := "1.0.0-SNAPSHOT" lazy val root = (project in file(".")) .settings( name := "foo", libraryDependencies += "com.typesafe.play" %% "play-ws-standalone" % "1.0.1", ) 

sbt shell दर्ज किए गए क्लासपाथ को प्राप्त करने के लिए show externalDependencyClasspath sbt shell डालें। इसे com.typesafe:config:1.3.1 के संस्करण को इंगित करना चाहिए। इसके अलावा, निम्नलिखित चेतावनी अभी भी प्रदर्शित की जाएगी:

 [warn] There may be incompatibilities among your library dependencies; run 'evicted' to see detailed eviction warnings. 

sbt shell में evicted को कॉल करने से आपको संघर्ष समाधान रिपोर्ट प्राप्त करने की अनुमति मिलती है:

 sbt:foo> evicted [info] Updating ... [info] Done updating. [info] Here are other dependency conflicts that were resolved: [info] * com.typesafe:config:1.3.1 is selected over 1.2.0 [info] +- com.typesafe.akka:akka-actor_2.12:2.5.3 (depends on 1.3.1) [info] +- com.typesafe:ssl-config-core_2.12:0.2.2 (depends on 1.2.0) [info] * com.typesafe:ssl-config-core_2.12:0.2.2 is selected over 0.2.1 [info] +- com.typesafe.play:play-ws-standalone_2.12:1.0.1 (depends on 0.2.2) [info] +- com.typesafe.akka:akka-stream_2.12:2.5.3 (depends on 0.2.1) 

latest-wins शब्दार्थ में, निर्दिष्ट config:1.2.0 व्यवहार में "मुझे संस्करण 1.2.0 या उच्चतर के साथ प्रदान करें"।
यह व्यवहार nearest-wins रणनीति की तुलना में थोड़ा अधिक बेहतर है, क्योंकि संक्रमणीय पुस्तकालयों के संस्करण डाउनग्रेड नहीं हैं। हालांकि, evicted कॉल को यह देखने के लिए जांचना चाहिए कि क्या प्रतिस्थापन सही तरीके से किए गए थे।

शब्दार्थ न्यायालय: नवीनतम-जीत

इससे पहले कि हम शब्दार्थ के विवरण के बारे में बात करें, मैं एक महत्वपूर्ण प्रश्न का उत्तर दूंगा - कर्टसीयर का उच्चारण कैसे किया जाता है। एलेक्स अरशाम्बो के नोट के अनुसार, यह चिक-सी का उच्चारण है।

दिलचस्प बात यह है कि कोर्टसियर के दस्तावेज में संस्करण पर एक पृष्ठ है, जो निर्भरता को हल करने के शब्दार्थों के बारे में बात करता है।

दिए गए अंतराल के प्रतिच्छेदन पर विचार करें:

• यदि यह खाली है (अंतराल अंतराल नहीं है), तो एक संघर्ष है।
• यदि कोई अंतराल निर्दिष्ट नहीं किया जाता है, तो यह माना जाता है कि चौराहे (,) (सभी संस्करणों के अनुरूप अंतराल) द्वारा दर्शाया गया है।
  फिर, विशिष्ट संस्करणों पर विचार करें:
  
  • हम अंतराल की सीमाओं के नीचे विशिष्ट संस्करणों को छोड़ देते हैं।
  • यदि अंतराल की सीमाओं के ऊपर विशिष्ट संस्करण हैं, तो एक संघर्ष है।
  • यदि विशिष्ट संस्करण अंतराल की सीमाओं के भीतर हैं, तो परिणाम उनमें से नवीनतम होना चाहिए।
  • यदि अंतराल सीमाओं के भीतर या ऊपर कोई विशिष्ट संस्करण नहीं हैं, तो परिणाम एक अंतराल होना चाहिए।

क्योंकि यह कहा , इसलिए - यह latest-wins का शब्दार्थ है।
आप इसे sbt 1.3.0-RC3 का उपयोग करके सत्यापित कर सकते हैं, जो कि कोर्टियर का उपयोग करता है।

 ThisBuild / scalaVersion := "2.12.8" ThisBuild / organization := "com.example" ThisBuild / version := "1.0.0-SNAPSHOT" lazy val root = (project in file(".")) .settings( name := "foo", libraryDependencies += "com.typesafe.play" %% "play-ws-standalone" % "1.0.1", ) 

sbt 1.3.0-RC3 कंसोल sbt 1.3.0-RC3 से show externalDependencyClasspath sbt 1.3.0-RC3 को वापस com.typesafe:config:1.3.1 । संघर्ष संकल्प रिपोर्ट एक ही रिपोर्ट:

 sbt:foo> evicted [info] Here are other dependency conflicts that were resolved: [info] * com.typesafe:config:1.3.1 is selected over 1.2.0 [info] +- com.typesafe.akka:akka-actor_2.12:2.5.3 (depends on 1.3.1) [info] +- com.typesafe:ssl-config-core_2.12:0.2.2 (depends on 1.2.0) [info] * com.typesafe:ssl-config-core_2.12:0.2.2 is selected over 0.2.1 [info] +- com.typesafe.play:play-ws-standalone_2.12:1.0.1 (depends on 0.2.2) [info] +- com.typesafe.akka:akka-stream_2.12:2.5.3 (depends on 0.2.1) 

नोट: अपाचे आइवी nearest-wins के शब्दार्थ का अनुकरण करता है?

जब मावेन रिपॉजिटरी से मॉड्यूल निर्भरता को हल करते हुए, आइवी ivy.xml फ़ाइल को कनवर्ट करता है और कैश में ivy.xml में force="true" विशेषता डालता है।

उदाहरण के लिए, cat ~/.ivy2/cache/com.typesafe.akka/akka-actor_2.12/ivy-2.5.3.xml :

  <dependencies> <dependency org="org.scala-lang" name="scala-library" rev="2.12.2" force="true" conf="compile->compile(*),master(compile);runtime->runtime(*)"/> <dependency org="com.typesafe" name="config" rev="1.3.1" force="true" conf="compile->compile(*),master(compile);runtime->runtime(*)"/> <dependency org="org.scala-lang.modules" name="scala-java8-compat_2.12" rev="0.8.0" force="true" conf="compile->compile(*),master(compile);runtime->runtime(*)"/> </dependencies> 

आइवी प्रलेखन कहता है:

ये दो latest संघर्ष प्रबंधक force निर्भरता विशेषता को ध्यान में रखते हैं।
इस प्रकार, प्रत्यक्ष निर्भरता एक force विशेषता (निर्भरता देखें) की घोषणा कर सकती है, यह दर्शाता है कि प्रत्यक्ष निर्भरता और अप्रत्यक्ष संशोधनों के कारण, प्रत्यक्ष निर्भरता संशोधनों को वरीयता दी जानी चाहिए।

मेरे लिए, इस सूत्रीकरण का अर्थ है कि latest-wins तर्क को फिर से परिभाषित करने और nearest-wins शब्दार्थों का अनुकरण करने के लिए force="true" कल्पना की गई थी। लेकिन, सौभाग्य से, ऐसा होना तय नहीं था, और अब हमारे पास latest-wins : जैसा कि हम देख सकते हैं, sbt 1.2.8 com.typesafe:config:1.3.1 को com.typesafe:config:1.3.1 ।

हालांकि, कोई एक सख्त संघर्ष प्रबंधक का उपयोग करते समय force="true" के प्रभाव force="true" का पालन कर सकता है, जो टूटने लगता है।

 ThisBuild / conflictManager := ConflictManager.strict 

समस्या यह है कि एक सख्त संघर्ष प्रबंधक संस्करण प्रतिस्थापन को रोकने के लिए नहीं लगता है। show externalDependencyClasspath com.typesafe:config:1.3.1 ख़ुशी से लौटता है। com.typesafe:config:1.3.1 ।
एक संबंधित समस्या यह है कि com.typesafe:config:1.3.1 का एक संस्करण जोड़ना, जो कि एक सख्त संघर्ष प्रबंधक ग्राफ में डालता है, एक त्रुटि की ओर जाता है।

 ThisBuild / scalaVersion := "2.12.8" ThisBuild / organization := "com.example" ThisBuild / version := "1.0.0-SNAPSHOT" ThisBuild / conflictManager := ConflictManager.strict lazy val root = (project in file(".")) .settings( name := "foo", libraryDependencies ++= List( "com.typesafe.play" %% "play-ws-standalone" % "1.0.1", "com.typesafe" % "config" % "1.3.1", ) ) 

यह इस तरह दिखता है:

 sbt:foo> show externalDependencyClasspath [info] Updating ... [error] com.typesafe#config;1.2.0 (needed by [com.typesafe#ssl-config-core_2.12;0.2.2]) conflicts with com.typesafe#config;1.3.1 (needed by [com.example#foo_2.12;1.0.0-SNAPSHOT]) [error] org.apache.ivy.plugins.conflict.StrictConflictException: com.typesafe#config;1.2.0 (needed by [com.typesafe#ssl-config-core_2.12;0.2.2]) conflicts with com.typesafe#config;1.3.1 (needed by [com.example#foo_2.12;1.0.0-SNAPSHOT]) 

वर्जनिंग के बारे में

हमने latest-wins शब्दार्थों का उल्लेख किया है, यह सुझाव देते हुए कि किसी स्ट्रिंग क्रम में संस्करण कुछ क्रम में हो सकते हैं।
इसलिए, वर्जनिंग शब्दार्थ का हिस्सा है।

अपाचे आइवी में वर्जनिंग प्रक्रिया

इस Javadoc टिप्पणी में कहा गया है कि संस्करणों का तुलनित्र बनाते समय, आइवी ने PHP से संस्करणों की तुलना करने के कार्य पर ध्यान केंद्रित किया:

यह फ़ंक्शन पहले एक बिंदु के साथ _, - और + बदलता है . संस्करणों के स्ट्रिंग प्रतिनिधित्व में और भी जोड़ता है . पहले और बाद में सब कुछ एक संख्या नहीं है। इसलिए, उदाहरण के लिए, '4.3.2RC1' '4.3.2.RC.1' बन जाता है। वह फिर बाएं से दाएं प्राप्त भागों की तुलना करती है।

विशेष तत्वों वाले भागों ( dev , alpha या a , beta या b , RC या RC , # , pl या p ) * के लिए, तत्वों की तुलना निम्नलिखित क्रम में की जाती है:

कोई भी स्ट्रिंग जो एक विशेष तत्व नहीं है <dev <Alpha = a <beta = b <RC = rc <# <pl = p।

इस प्रकार, न केवल विभिन्न स्तरों (उदाहरण के लिए, '4.1' और '4.1.2') की तुलना की जा सकती है, बल्कि PHP- विशिष्ट संस्करणों में विकास की स्थिति के बारे में जानकारी होती है।
* लगभग। ट्रांस।

हम जांच सकते हैं कि एक छोटे से फ़ंक्शन को लिखकर संस्करणों को कैसे ऑर्डर किया जाता है।

 scala> :paste // Entering paste mode (ctrl-D to finish) val strategy = new org.apache.ivy.plugins.latest.LatestRevisionStrategy case class MockArtifactInfo(version: String) extends org.apache.ivy.plugins.latest.ArtifactInfo { def getRevision: String = version def getLastModified: Long = -1 } def sortVersionsIvy(versions: String*): List[String] = { import scala.collection.JavaConverters._ strategy.sort(versions.toArray map MockArtifactInfo) .asScala.toList map { case MockArtifactInfo(v) => v } } // Exiting paste mode, now interpreting. scala> sortVersionsIvy("1.0", "2.0", "1.0-alpha", "1.0+alpha", "1.0-X1", "1.0a", "2.0.2") res7: List[String] = List(1.0-X1, 1.0a, 1.0-alpha, 1.0+alpha, 1.0, 2.0, 2.0.2) 

कौरसियर में संस्करण प्रक्रिया

निर्भरता संकल्प शब्दार्थ पर GitHub पृष्ठ के संस्करण पर एक खंड है।

कोर्टियर मावेन के अनुरूप संस्करण क्रम का उपयोग करता है। तुलना करने से पहले, संस्करणों के स्ट्रिंग प्रतिनिधित्व अलग-अलग तत्वों में टूट गए हैं ...
ऐसे तत्वों को प्राप्त करने के लिए, वर्णों द्वारा संस्करणों को अलग किया जाता है।, -, और _ (और विभाजक स्वयं को छोड़ दिया जाता है), और अक्षर-से-संख्या या संख्या-दर-अक्षर प्रतिस्थापन द्वारा।

परीक्षण लिखने के लिए, निर्भरता libraryDependencies += "io.get-coursier" %% "coursier-core" % "2.0.0-RC2-6" साथ एक libraryDependencies += "io.get-coursier" %% "coursier-core" % "2.0.0-RC2-6" बनाएँ निर्भरताएँ libraryDependencies += "io.get-coursier" %% "coursier-core" % "2.0.0-RC2-6" और console चलाएँ:

 sbt:foo> helper/console [info] Starting scala interpreter... Welcome to Scala 2.12.8 (OpenJDK 64-Bit Server VM, Java 1.8.0_212). Type in expressions for evaluation. Or try :help. scala> import coursier.core.Version import coursier.core.Version scala> def sortVersionsCoursier(versions: String*): List[String] = | versions.toList.map(Version.apply).sorted.map(_.repr) sortVersionsCoursier: (versions: String*)List[String] scala> sortVersionsCoursier("1.0", "2.0", "1.0-alpha", "1.0+alpha", "1.0-X1", "1.0a", "2.0.2") res0: List[String] = List(1.0-alpha, 1.0, 1.0-X1, 1.0+alpha, 1.0a, 2.0, 2.0.2) 

जैसा कि यह पता चला है, कर्टसीयर आईवी की तुलना में पूरी तरह से अलग क्रम में संस्करण संख्याओं का आदेश देता है।
यदि आपने अनुमेय वर्णनात्मक टैग का उपयोग किया है, तो यह आदेश कुछ भ्रम पैदा कर सकता है।

संस्करण रेंज के बारे में

आमतौर पर, मैं संस्करण श्रेणियों का उपयोग करने से बचता हूं, हालांकि वे व्यापक रूप से वेबर और एनवीपी मॉड्यूल में उपयोग किए जाते हैं जो मावेन सेंट्रल पर पुनर्प्रकाशित हैं। मॉड्यूल में "is-number": "^4.0.0" कुछ लिखा जा सकता है "is-number": "^4.0.0" जो कि [4.0.0,5) अनुरूप होगा।

Apache Ivy में वर्जन रेंज हैंडलिंग

इस विधानसभा में, angular-boostrap:0.14.2 angular:[1.3.0,) पर निर्भर करता है angular:[1.3.0,) ।

 ThisBuild / scalaVersion := "2.12.8" ThisBuild / organization := "com.example" ThisBuild / version := "1.0.0-SNAPSHOT" lazy val root = (project in file(".")) .settings( name := "foo", libraryDependencies ++= List( "org.webjars.bower" % "angular" % "1.4.7", "org.webjars.bower" % "angular-bootstrap" % "0.14.2", ) ) 

sbt 1.2.8 show externalDependencyClasspath sbt 1.2.8 को sbt 1.2.8 में angular-bootstrap:0.14.2 और angular:1.7.8 angular-bootstrap:0.14.2 । और 1.7.8 कहां गए? जब आइवी कई संस्करणों का सामना करता है, तो यह अनिवार्य रूप से इंटरनेट पर जाता है और पाता है कि यह क्या खोज सकता है, कभी-कभी स्क्रीनक्रैपिंग का उपयोग भी करता है।

संस्करण श्रेणियों का यह प्रसंस्करण असेंबली को गैर-दोहराव बनाता है (हर कुछ महीनों में एक ही असेंबली चलाने से आपको अलग-अलग परिणाम मिलते हैं)।

कौरसियर में हैंडलिंग वर्जन रेंज

जीथब पृष्ठ पर कर्टसीयर निर्भरता संकल्प अनुभाग
यह पढ़ता है इस प्रकार है:

अंतराल पर विशिष्ट संस्करण पसंद किए जाते हैं
यदि आपके मॉड्यूल में [1.0,2.0) और 1.4 पर निर्भरता है, तो संस्करण अनुमोदन 1.4 के पक्ष में किया जाएगा।
अगर 1.4 पर निर्भरता है, तो यह संस्करण [1.0,2.0] रेंज में पसंद किया जाएगा।

यह आशाजनक लग रहा है।

 sbt:foo> show externalDependencyClasspath [warn] There may be incompatibilities among your library dependencies; run 'evicted' to see detailed eviction warnings. [info] * Attributed(/Users/eed3si9n/.sbt/boot/scala-2.12.8/lib/scala-library.jar) [info] * Attributed(/Users/eed3si9n/.coursier/cache/v1/https/repo1.maven.org/maven2/org/webjars/bower/angular/1.4.7/angular-1.4.7.jar) [info] * Attributed(/Users/eed3si9n/.coursier/cache/v1/https/repo1.maven.org/maven2/org/webjars/bower/angular-bootstrap/0.14.2/angular-bootstrap-0.14.2.jar) 

angular-bootstrap:0.14.2 साथ एक ही असेंबली पर show externalDependencyClasspath angular-bootstrap:0.14.2 रिटर्न angular-bootstrap:0.14.2 और angular:1.4.7 उम्मीद के angular-bootstrap:0.14.2 । यह आइवी पर एक सुधार है।

अधिक जटिल मामले पर विचार करें जब कई असंतुष्ट संस्करण रेंज का उपयोग किया जाता है। उदाहरण के लिए:

 ThisBuild / scalaVersion := "2.12.8" ThisBuild / organization := "com.example" ThisBuild / version := "1.0.0-SNAPSHOT" lazy val root = (project in file(".")) .settings( name := "foo", libraryDependencies ++= List( "org.webjars.npm" % "randomatic" % "1.1.7", "org.webjars.npm" % "is-odd" % "2.0.0", ) ) 

sbt 1.3.0-RC3 में sbt 1.3.0-RC3 में sbt 1.3.0-RC3 show externalDependencyClasspath को निम्न त्रुटि sbt 1.3.0-RC3 :

 sbt:foo> show externalDependencyClasspath [info] Updating https://repo1.maven.org/maven2/org/webjars/npm/kind-of/maven-metadata.xml No new update since 2018-03-10 06:32:27 https://repo1.maven.org/maven2/org/webjars/npm/is-number/maven-metadata.xml No new update since 2018-03-09 15:25:26 https://repo1.maven.org/maven2/org/webjars/npm/is-buffer/maven-metadata.xml No new update since 2018-08-17 14:21:46 [info] Resolved dependencies [error] lmcoursier.internal.shaded.coursier.error.ResolutionError$ConflictingDependencies: Conflicting dependencies: [error] org.webjars.npm:is-number:[3.0.0,4):default(compile) [error] org.webjars.npm:is-number:[4.0.0,5):default(compile) [error] at lmcoursier.internal.shaded.coursier.Resolve$.validate(Resolve.scala:394) [error] at lmcoursier.internal.shaded.coursier.Resolve.validate0$1(Resolve.scala:140) [error] at lmcoursier.internal.shaded.coursier.Resolve.$anonfun$ioWithConflicts0$4(Resolve.scala:184) [error] at lmcoursier.internal.shaded.coursier.util.Task$.$anonfun$flatMap$2(Task.scala:14) [error] at scala.concurrent.Future.$anonfun$flatMap$1(Future.scala:307) [error] at scala.concurrent.impl.Promise.$anonfun$transformWith$1(Promise.scala:41) [error] at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:64) [error] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [error] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [error] at java.lang.Thread.run(Thread.java:748) [error] (update) lmcoursier.internal.shaded.coursier.error.ResolutionError$ConflictingDependencies: Conflicting dependencies: [error] org.webjars.npm:is-number:[3.0.0,4):default(compile) [error] org.webjars.npm:is-number:[4.0.0,5):default(compile) 

तकनीकी रूप से, यह सही है, क्योंकि ये श्रेणियां ओवरलैप नहीं होती हैं। जबकि sbt 1.2.8 इस is-number:4.0.0 sbt 1.2.8 हल करता is-number:4.0.0 ।

इस तथ्य के कारण कि संस्करण श्रेणियां काफी कष्टप्रद हैं, मैं अतिरिक्त latest-wins शब्दार्थ नियमों को लागू करने के लिए कौरियर को एक पुल अनुरोध प्रस्तुत करता हूं जो आपको श्रेणियों के निचले सीमा से बाद के संस्करणों का चयन करने की अनुमति देता है।
देखें प्रांगण / coursier # 1284

निष्कर्ष

रिज़ॉल्वर शब्दार्थ उपयोगकर्ता-परिभाषित बाधाओं के आधार पर एक विशिष्ट क्लासपैथ को परिभाषित करता है।

आमतौर पर, विवरणों में अंतर संस्करण संघर्षों को हल करने के विभिन्न तरीकों से प्रकट होता है।

• मावेन nearest-wins रणनीति का उपयोग करता है, जो सकर्मक निर्भरता को कम कर सकता है।
• आइवी latest-wins रणनीति का उपयोग करता है।
• कोर्टियर मुख्य रूप से latest-wins रणनीति का उपयोग करता है, जबकि संस्करणों को अधिक सख्ती से निर्दिष्ट करने की कोशिश कर रहा है।
• आइवी संस्करण रेंज हैंडलर इंटरनेट पर जाता है, जो समान बिल्ड को गैर-दोहराने योग्य बनाता है।
• कौरसियर और आइवी बहुत भिन्न तरीकों से संस्करणों के स्ट्रिंग प्रतिनिधित्व का आयोजन करते हैं।

26 नवंबर को मॉस्को में स्काला इकोसिस्टम की स्काला इकोसिस्टम की ऐसी सूक्ष्मता पर भी चर्चा नहीं की जाएगी । Artem Seleznev JDBC के बिना कार्यात्मक प्रोग्रामिंग में डेटाबेस के साथ काम करने का अभ्यास शुरू करेगा। Wojtek Pitula एकीकरण के बारे में बात करेंगे और बताएंगे कि कैसे उन्होंने एक एप्लिकेशन बनाया जिसमें उन्होंने सभी कामकाजी पुस्तकालयों को रखा। और तकनीकी कट्टर से भरी 16 और रिपोर्ट सम्मेलन में प्रस्तुत की जाएंगी।