Scala and Maven: which scope should scala-library be in?

Hi. I think 'provided' is normally what you want. This will make the
scala library .jar file visible when compiling and testing, but assume
that you don't need to bundle it when your .jar file (project
artifact) is put to use.

> IMHO, compile scope is the right choice, as you
> can't count on the bin/scala script doing the "providing."

I'm pretty sure bin/scala does include the scala library in the
classpath (if you've installed the distribution right), whereas
bin/java does not.

Rob

On Thu, Jun 17, 2010 at 10:04 AM, Andreas Sewe
wrote:
> Hi all,
>
> I hope this is the right mailing-list to post to. (If not, please point me
> in the right direction.)
>
> When working with Scala and Maven I noticed that there seems to be some
> disagreement about the scope the scala-library dependency should be in:
> compile or provided.
>
> Most notably scala-compiler, scalacheck, and scala-archetype-simple (the
> archetypical Scala project!) opt for a compile-scoped dependency on the
> library, whereas scalatest and specs use only the provided-scope. Which
> interpretation is right? (IMHO, compile scope is the right choice, as you
> can't count on the bin/scala script doing the "providing.")
>
> Best wishes,
>
> Andreas
>

Hi Rob,

> Hi. I think 'provided' is normally what you want. This will make the
> scala library .jar file visible when compiling and testing, but assume
> that you don't need to bundle it when your .jar file (project
> artifact) is put to use.

well, that's the question: do you want to bundle scala-library with your
application? Given that a dependency on the Scala library is often
enough a dependency on a particular version of scala-library, I would
argue that you indeed want to include it in your bundle.

>> IMHO, compile scope is the right choice, as you
>> can't count on the bin/scala script doing the "providing."
>
> I'm pretty sure bin/scala does include the scala library in the
> classpath (if you've installed the distribution right), whereas
> bin/java does not.

Yes, bin/scala does include the scala-library, but bin/java does not. In
my understanding the dependency scopes of Maven are defined w.r.t. to a
regular Java installation (that's why you don't see provided-scoped
dependencies on the JRE), not w.r.t. to a Scala installation. So
scala-library cannot normally be assumed to be provided.

But that's just my 5 cents.

What really confuses me is that there seems to be no agreement on the
scope of scala-library in the Scala world (which seems to have adopted
Maven quite thoroughly). I fear that this inconsistent treatment will
sooner or later make a mess of Maven's attempt at dependency management. :-(

Best wishes,

Andreas Sewe

On Thu, Jun 17, 2010 at 06:32:36PM +0200, Andreas Sewe wrote:
> What really confuses me is that there seems to be no agreement on the
> scope of scala-library in the Scala world (which seems to have adopted
> Maven quite thoroughly).

Maybe if all you have is a giant hammer-like monster which likes to
smash things, everything looks like tokyo.

Scala has adopted maven *repositories* not maven itself.   A significant number of scala projects use Simple Build Tool for their build environments.   You can resolve artifacts from a maven repository from any number of tools.

In any case, the answer to your question depends on your situation.  Rob's answer is correct for a number of projects.  However, For popular Scala libraries, I've tried to switch the old standard from "provided" to "compile" for the primary reason of detecting differing scala versions in a build.   Scala is not backwards-binary-compatible the way Java tries to be, so it's dangerous (and usually fatal) to mix scala versions.   Marking the dependencies as compile allows the maven-scala-plugin divergent-scala-version check to work.   Otherwise you'll run into silent errors.  I'd rather have users "exclude" Scala specifically (something not done frequently) if desired than receive dozens of "why is the maven scala plugin broken" emails.
Note that in my experience of deploying Scala "in production" having the compile dependency was rather helpful.  Downstream artifacts would not have to specify scala as a dependency and the WAR/EAR/uber jar creation was nice and simple.   I'd also recommend determining a way to either isolate your scala components classloaders or batch deploy a scala upgrade to *all* items you run in production.
- Josh
P.S. Paul - I love the analogy. 


On Thu, Jun 17, 2010 at 12:42 PM, Paul Phillips <paulp@improving.org> wrote:

On Thu, Jun 17, 2010 at 06:32:36PM +0200, Andreas Sewe wrote:
> What really confuses me is that there seems to be no agreement on the
> scope of scala-library in the Scala world (which seems to have adopted
> Maven quite thoroughly).

Maybe if all you have is a giant hammer-like monster which likes to
smash things, everything looks like tokyo.

--
Paul Phillips      | Appreciation is a wonderful thing; it makes what is
Moral Alien        | excellent in others belong to us as well.
Empiricist         |     -- Voltaire
up hill, pi pals!  |----------* http://www.improving.org/paulp/ *----------