CODEWITHSUNDEEP
scalaimportsbt
Chris J Harris
Chris J Harris

Reputation: 1851

What is the relationship between the sbt libraryDependency and the import statement in Scala?

This is probably an easy one but I haven't been able to find the answer anywhere. When I am importing libraries into Scala via a build.sbt, is there any way to infer what the import statement should look like, based on the sbt libraryDependency?

Right now I am trying to use the flexmark package, which I can successfully incorporate into my project by adding "com.vladsch.flexmark" % "flexmark-all" % "0.61.26", to my sbt libraryDependencies.

However, it is not obvious to me how I should actually import it into the code itself - ie, what my import statement should look like. Can I guess that from the sbt libraryDependency? Or should I try to obtain it from each project's documentation? If I look at what else I'm using, I can't see any clear pattern. I've managed to scrape by without knowing this in the past but I've come to a bit of a blockage on this one. Thanks in advance for any help.

Upvotes: 0

Views: 105

Answers (2)

Mario Galic
Mario Galic

Reputation: 48420

IDEs help with auto importing, for example in IntelliJ you type the name and then Alt + Enter.

Without IDE support you would have to look up Scaladoc/Javadoc.

Another option is to search the online repos, say, GitHub repository and look at the package statements in the source code

  1. Navigate to https://github.com/vsch/flexmark-java

  2. Press t which activates file finder

    enter image description here

  3. Start typing the name and if you are lucky it will correspond to the filename

  4. Look at the package statement at the top of the source file

Upvotes: 2

Mateusz Kubuszok
Mateusz Kubuszok

Reputation: 27595

I would assume no dependency.

When you publish library on Nexus you are asked to prove that you have some right to the domain that you use as organization. So e.g. if you are an owner of example.com then you could publish artifacts under com.example - but you would be required by maintainers of Nexus or Sonatype or someone else to provide a proof that you own the domain - e.g. by settings some DNS record.

That has nothing to do with how you name your packages, which in turn how your users will import them. You could follow the same naming rules and use com.example as package name. But for many reasons people might not want to do it e.g.

  • Cats libraries live under org.typelevel organization but typing org.typelevel.cats would be long and annoying so they chose to use simply cats
  • Monix has io.monix organization but everything in in package monix
  • Endpoints have org.julienrf organization but code lives in endpoints package

etc.

They are completely independent of each other and if someone has it consistent it is only because they chose to use it this way, not because they had to. So just check the documentation, and maybe use IntellIJ's automatic import.

Upvotes: 3

Related Questions