Re: Input needed: Plan for packaging scala

[Pjotr Prins <pjotr.public12@thebird.nl>]

On Sun, Feb 26, 2017 at 12:08:37AM +0100, Ricardo Wurmus wrote:
> I’ve done a bit of work in the past to get some Java things packaged and
> had to stop when I realised that nobody in the Java world seems to build
> dependencies from source.  This makes it very hard for us to construct
> proper dependency graphs for Java packages.
> 
> This is the primary reason why we only have a handful of Java packages
> in Guix.  We don’t want to make an exception for Java and accept
> pre-built binaries just to increase the number of packages.  (Luckily
> for us, Java build artifacts are often quite portable, so there’s not as
> much urgency to make it work with Guix as there is for applications
> written in other languages.)

You mean that users can easily deploy JVM packages (jars and wars) on
top of on existing Guix JVM? 

> The same applies to build systems other than ant.  Maven cannot be built
> without Maven, and its dependencies have dependency cycles.  I’ve been
> using the ant-build-system’s feature to generate a default build.xml to
> build some of these dependencies that would usually require Maven to
> build them.  I’m not currently working on Java packaging (though I still
> have a couple of patches that are almost ready).

(...)

> Are you aware of any other implementation of the Scala toolchain that we
> might be able to use for bootstrapping purposes?

sbt is pretty much it. The advantage and disadvantage of a relatively
young language. Maybe sbt can be taught to generate ant or Makefiles.
It probably is possible with some Scala hacking.

It appears to me that we should have a discussion here. If we were to
provide support for JVM build tools, such as Maven and sbt, we could
move forward providing proper packages for almost all projects on the
JVM (10Ks)

Why don't we accept these particular build tools as binary bootstraps
for now? It will be a limited set of true FOSS tools that are very
visible with their source code. Also, unlike other binaries, JVM byte
code is reversible - so we can actually get the source code even if it
is not commented and copyrighted and that can be compared to the
original source code. I am sure that when enough people start using
this maven and sbt functionality there will be volunteers who will
look into removing those binaries again. It is just a matter of time.

Guix is not exactly pure anyway - we bootstrap build binaries for
pragmatic reasons.  Having users now deploy their own jars on top of
Guix appears to be the lesser solution to me - we are forcing them to
use insecure software! I think the real problem now is that we have
few people interested in the JVM. But, do realize that the reason
could be that we do not properly support it. I am sure there would be
great interest in JVM support - the JVM's dependency hell is just as
large as any.

Nix, as far as I remember, simply installs jars. At least that way the
depency graph is under control. We could do better by only
bootstrapping the 'impossible' dependencies as jars and continue
building source from there. It may look lame to purists to bootstrap
the build tools, but for those who are most critical I ask you to fix
the problem instead. In the end it all software and fixable. But, if
no one is actively working on Maven, I suggest to use a jar for the
time being. 

Q: who here wants to work on this eyesore and challenge called Maven?
   So far Ricardo and Roel have worked on it and given up.

Time for some heroics. Or take the pill.

Pj.