Re: Input needed: Plan for packaging scala

[Ricardo Wurmus <rekado@elephly.net>]

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> On Sun, Feb 26, 2017 at 12:08:37AM +0100, Ricardo Wurmus wrote:
>> 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?

I don’t know about wars, but the jars we worked with at the MDC worked
just fine on top of the JVM provided by the icedtea packages.

> Why don't we accept these particular build tools as binary bootstraps
> for now?

The reason is that we cannot make one decision for all tools.  A big
chunk of the work is to figure out *which* of the dependencies can be
considered an “impossible” dependency.  Having a binary for Maven alone
wouldn’t be very helpful.  The primary purpose of Maven is to download
required binaries from a central site.  It doesn’t help us *build* any
packages from source.  When we provide Maven it has to be with a
maven-build-system that takes all Java inputs and arranges them in the
layout that a local Maven repository containing all these inputs would
have.  Maven on its own would not be very useful.

In fact, I’ve been packaging libraries that officially require Maven to
build them, but I used plain ant with the default build.xml the
ant-build-system generates.

> Guix is not exactly pure anyway - we bootstrap build binaries for
> pragmatic reasons.

And we try very hard to reduce the number of bootstrap binaries.  I
don’t think it would be a good idea to open the flood gates and accept
binaries for Java tools — because that’s not an exceptional case;
downloading binaries is in the fabric of the Java culture.

We need a few more libraries packaged the hard way, which would make the
next steps a lot easier.  My recommendation is to continue following the
bootstrap path of Maven and its dependencies and see where that leads
us.

> But, if no one is actively working on Maven, I suggest to use a jar
> for the time being.

I’ll get back to it soon.  It’s in my own interest to reduce the number
of unpushed patches I have on my machines :)

> 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.

(Hartmut also worked on it and I’m still working on some of his
abandoned patches in a branch.)

I would be very happy to collaborate with others who are interested in
moving Java on Guix forward.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net