Matched Dependencies
The second type of Dependency is Matched Dependencies in the "Manage Library Dependencies" series. Let's discuss this dependency in more detail.
If you are familiar with Apache Ivy, Maven, or Coursier, which is how sbt implements managed dependencies, you shouldn't have too much trouble. You can smoothly list your dependencies in the setting libraryDependencies most of the time.
In order to externally configure your dependencies, you can also create a Maven POM file or an Ivy configuration file. Sbt can then use those external configuration files. More information on that is available here.
We can declare a dependency using the below command:
libraryDependencies += groupID % artifactID % revision
Here, groupID, artifactID, and revision are strings.
Another way of declaring a dependency is:
libraryDependencies += groupID % artifactID % revision % configuration
The below command shows how libraryDependencies are declared in Keys:
val libraryDependencies = settingKey[Seq[ModuleID]]("Declares managed dependencies.")
The % methods convert strings into ModuleID objects, which you then add to libraryDependencies.
Getting the appropriate Scala version using %%
In this section of "Manage Library Dependencies," we will discuss the proper way for getting the Scala version using %%.
The binary Scala version of your project will be included in the artifact name if you use the organization%% moduleName% version rather than the organization% moduleName% version (the difference is the double%% after the organization). It's just a shortcut. This might be written without the %%:
libraryDependencies += "org.scala-stm" % "scala-stm_2.13" % "0.9.1"
Assuming the scalaVersion for the build is 2.13.8, the below command is equal:
libraryDependencies += "org.scala-stm" %% "scala-stm" % "0.9.1"
The concept is that a lot of dependencies are built for various versions of Scala. And you should select the version that is compatible with your project to ensure binary compatibility.
Ivy Revision
In this section of "Manage Library Dependencies," we will discuss the Ivy Revision in detail.
The version in organization% moduleName% doesn't need to be a single fixed version. Ivy can select the latest versions of a module based on the constraints you give. You specify "latest.integration", "2.9.+", or "[1.0,)" in place of a fixed revision like "1.6.1". You can refer to the Ivy revisions documentation for more information.
Occasionally, a dependency (transitive or otherwise) is specified via a Maven "version range," such as [1.3.0,]. sbt will utilize the given dependency version if it is declared in the build and falls within the range. If not, Coursier might search the Internet for the most recent version. Even though a specific version of the library satisfies the range constraint, this would lead to an error where the effective version keeps changing over time.
Maven version ranges will be replaced with their lower bound during the build so that it will be used when a suitable version is found in the dependency graph. The JVM flag -Dsbt.modversionrange=false can be used to stop this behavior from occurring.
Resolvers
Not all packages are stored on the same server; by default, sbt uses the Maven2 standard repository. You will need to add a resolver to help Ivy find your dependency if it isn't stored in one of the usual repository locations.
Use the below command to add an additional repository with the special at between two strings:
resolvers += name at location
For example:
resolvers += "Sonatype OSS Snapshots" at "https://oss.sonatype.org/content/repositories/snapshots"
The resolvers key is described as follows in Keys:
val resolvers = settingKey[Seq[Resolver]]("The user-defined additional resolvers for automatically managed dependencies.")
Here, the at method is creating a Resolver object from the two strings.
If you add it as a repository, sbt can search your local Maven repository:
resolvers += "Local Maven Repository" at "file://"+Path.userHome.absolutePath+"/.m2/repository"
You can use the below command for convenience:
resolvers += Resolver.mavenLocal
Frequently Asked Questions
How does Play Framework work?
Play is a web framework for the JVM that deviates from the Servlet Specification. Through the use of futures for asynchronous programming, work stealing to maximize the number of available threads. And Akka for task distribution, Play embraces a completely reactive programming style.
Where is Play Framework used?
Play is a high-productivity web app framework for programming languages, mainly Java and Scala, whose code is compiled and run on the JVM. It includes the parts and APIs required for the creation of contemporary web applications.
Why is Play Framework used?
Scala & Java developers can create web apps quickly and easily with Play Framework. Play's architecture is lightweight, stateless, and suitable for the web. Play, based on Akka, gives highly scalable applications predictable and minimal resource consumption (CPU, memory, threads).
Conclusion
We have discussed the topic of Manage Library Dependencies. We have seen the types of Dependencies, Scala version, Ivy Revision, and Resolvers in the "Manage Library Dependencies" series.
We hope this blog has helped you enhance your knowledge of Manage Library Dependencies. If you want to learn more, check out our articles Guidelines for writing Play documentation, Dictionary, TreeMap, and many more on our platform Coding Ninjas Studio.
But suppose you have just started your learning process and are looking for questions from tech giants like Amazon, Microsoft, Uber, etc. In that case, you must look at the problems, interview experiences, and interview bundle for placement preparations.
However, you may consider our paid courses to give your career an edge over others!
Happy Learning!
245+ registered 
