Doesn't the Debian Scala package depend on the Ant build?

@martijnhoekstra Good point, although I think that getting those usually completed outdated builds of Scala out of Debian is a plus. :)

I can see that not having Scala in Debian - which also means no Scala in most downstreams like Ubuntu - is a sacrifice that one could be willing to make, due to how old those packages tend to be.

But SBT in Debian - and downstreams - would be really nice, even if it is an older version. And without Scala in Debian, all hope for eventually having SBT in Debian is ruled out.

@martijnhoekstra Wouldn't the exceptions from the bootstrapping requirements not apply to SBT?

Having SBT in Debian would be great, although to really benefit from it we should probably change the versioning scheme to SBT 1.0.0.0-x so that it can receive updates. :-)

@soc I asked around about SBT quite a while ago on the Debian packaging IRC channel on FreeNode, where it was indicated they insisted on a make build rather than a build that had to be bootstrapped. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639910 is the request for packaging in Debian.

Reading through it again, I may be mistaken that Debian requires all build-deps to have a free Debian package - and the recursive build dependency may be allowed for at least Scala.

I think the issue is that no one from the SBT team seemed to communicate how/if it is possible to compile SBT without internet access.
(A problem which is still unsolved, and manifests itself in many different instances, like SBT downloading dozens of jar files with a few dozen kBs instead of one package during first start.)

Back to the Scala Debian package itself though: is requiring sbt a blocker for that package, and is that enough reason not to merge the patch? Should the package maintainer be contacted for that?

Reading through it again, I may be mistaken that Debian requires all build-deps to have a free Debian package - and the recursive build dependency may be allowed for at least Scala.

I'm not sure about the free requirement, IIRC someone suggested uploading sbt (with a prebuilt sbt in the source package as to have no build-deps) to contrib or non-free. Bootsrapping into main could then happen from there on.
As @soc mentioned, I think the major blocker is the internet connectivity during build.

Considering that, I would also think that requiring an sbt build would effectively ban scala from debian until sbt is available as a package.

Since it appears that dropping internet connectivity for sbt is not so trivial, has anyone considered making scala and sbt available on the non-free repository? I'm not sure how to go about it but it seems to be a viable compromise, at least for a first step.

Scala package in Fedora is built with Ant. Removing Ant build script would make things much more difficult for us and in worst case scenario in could even result in dropping Scala from the distribution.

Hi, I'm one of the volunteers currently maintaining Scala in Debian (and indirectly Ubuntu). Debian 8 currently ships a rather old 2.9.2 version, but the upcoming Debian 9 and the last 3 releases of Ubuntu have Scala 2.11.6. Scala 2.11.8 should arrive in Debian soon. So the package used to be outdated, but we're trying to do better nowadays.

The Debian package is built with Ant and dropping this build system would seriously impact us since we don't have SBT in Debian. We would be really grateful if you could keep supporting the Ant build (or consider alternative build systems supported in Debian like Maven or Gradle).

On a side note, we are rather short-staffed on people knowledgeable in Scala. If there are developers interested in improving the Scala ecosystem in Debian/Ubuntu please contact us on debian-java@lists.debian.org.

I quickly checked the other Linux distributions, Gentoo, Arch and SUSE also build Scala with Ant.

Of course they do, that's been the official build system for Scala until recently.

Personally I think we should remove the burden of supporting both build tools, and forward-fix whatever is necessary to continue to allow for a scala package in the various distributions.

@dwijnand if forward-fixing entails helping the distros package SBT in so far they haven't been able to yet, and helping them package Scala under an SBT build, is there a reasonable guarantee of this actually happening?

Once the community build starts using pre-built Scala artifacts, the ant build will be essentially unsupported because there are no CI jobs using it anymore. PR validation and nightly builds are already ant-free. The goal is to get rid of ant as quickly as possible. We don't want to maintain multiple build systems (one is more than enough, considering the complexity of the build setup).

BTW, internet connectivity shouldn't be required for building with sbt. You can populate a local repository with all required artifacts and use that as the only bootstrap repository.

@szeiger I'm sure it's possible, but it's not straight-forward enough for anyone to depend on it. There should be one fat-jar that delivers everything the SBT launcher needs on first startup, even if it was just for performance reasons.

Would it be possible to deprecate the Ant build in Scala 2.12 (using SBT as the main build system) and removing it in Scala 2.13? Debian 9 will be frozen at the end of the year, and unless someone steps up to package SBT it's unlikely we'll have it in time. This means we won't be able to ship Scala 2.12 in Debian 9.

@soc The artifacts required by the sbt launcher are not sufficient. You need additional plugins for the build plus the actual build dependencies. I don't see how an sbt fat jar would help with this. You still need to bootstrap your own setup through a proxy repo if you want offline builds.

@ebourg I think it would be better to package SBT(-launcher), as this has the chance of keeping itself updated. I'd rather not have to deal with questions from people who have Debian and run into bugs in prehistoric versions of Scala.

@szeiger No one is denying that a project that defines dependencies needs those dependencies to compile. What I have in mind are the dozens of JAR files SBT needs regardless of any actual project.

@soc Packaging the SBT launcher alone wouldn't help, because the Debian builds must run offline. We need SBT and all its runtime dependencies packaged first, and this isn't a trivial task.

@soc Sure, I'm not saying it wouldn't be useful in general, it's just that it doesn't solve the problem at hand. We have the knowledge how to build a fat distribution, the Activator team has done it (Activator is sbt plus some extra plugins, available either as a minimum download like sbt or a complete distribution with all dependencies). You'd have to convince the sbt team that it would be beneficial to do it.

Or maybe a better solution is to document how to do it so that interested parties can do it themselves (like building your own Windows installation image with additional drivers). As far as sbt configuration goes, it's really simple. I have not yet tried to use a repository proxy with the goal of building a standalone repo (that can be accessed through a file: URL).

I get that nobody wants to maintain multiple build systems, but I don't get putting a change on hold to make sure that nobody depends on the old situation, the discussion shows people do depend on the old situation, and then concluding that doesn't matter. Did I misunderstand the on-hold reason?

@szeiger I think that repo maintainer having to mess around with local repositories and proxies is hardly an improvement. I think what they want is a simple tar.gz that contains what SBT needs to build Scala.

@martijnhoekstra I'd be in favor of deprecating, but keeping the ant scripts for 2.12 to not increase the pain as current distros work on shipping their next release. I just don't want to keep things around forever, because the pressure to migrate to the SBT build might not be there until the ant scripts are finally gone.

I opened this as on-hold as a wake-up call for everyone who may still depend on ant. The migration to sbt has been going for the last 10 months with the goal to complete it for 2.12.0. The conclusion from the discussion here is not that it doesn't matter, but neither is it "we won't do it". Since we're so close to 2.12.0-RC1 it may be reasonable to keep the ant build around (even though it is no longer tested) in the 2.12.x branch and do any further build improvements in 2.13.

It just occurred to me that the Scala modules are sbt-based. How does Debian deal with that? You already cannot build a Scala distribution without using sbt.

I'm testing the necessary changes to the community build here: https://scala-ci.typesafe.com/job/scala-2.12.x-integrate-community-build/499/console

tracking the community build work at scala/community-build#274 ; once that's done, this PR will be merged. (sorry, this wasn't the outcome some people preferred. we read your feedback and considered carefully.)

I'd suggest continuing discussion about support for Debian et al at https://issues.scala-lang.org/browse/SI-9299

This should be ready to merge! I've started another community build that should fix the last glitch in my previous run, but nothing fundamental blocking the removal of ant. https://scala-ci.typesafe.com/job/scala-2.12.x-integrate-community-build/544/console

It took a little detour, but the community build is now ant-free!

LGTM

is there a ticket of record, somewhere else, on the Debian situation?

ah: https://issues.scala-lang.org/browse/SI-10172

a lot of organizations out of these installations(including ours) have a convention that - they strictly do not install/depend any package which is not in debian and ubuntu repo.

#5311 (comment)
Those 900/6000 installations aren't to "build things on top of it", I'd wager they're just to have a quick repl, maybe sometimes call scalac. For everything else they're using sbt or some other build tool instead of the scala distribution

please take any further Debian discussion to the JIRA ticket