Re: Help needed from Java developer to finish maven

[Hilco Wijbenga]

Hi Hartmut,

On 23 April 2017 at 13:34, Hartmut Goebel <address@hidden> wrote:
> for what I want to achieve, you need to understand Guix's philosophy:
> One of the major points is to have as few components as possible
> pre-build be external entities. Because only then Guix can ensure that
> the component is build from exactly the known source and not manipulated.

Sure, that makes sense ... up to a point.

First, if it's about trust ("am I really running a stock,
unmanipulated Maven") then there are the checksums and signatures on
the download page which exist for exactly that purpose. If you feel
you cannot rely on those then why trust the SCM that holds the Maven
code? You'd have to become intimately familiar with the entire Maven
code base to be able to state that it wasn't manipulated. In short, if
you can't trust the Maven devs then you should not use Maven.

Second, as an end user this makes it even harder to trust the end
result. I now have to trust both the Maven devs *and* the Guix devs
who worked on the packages. Not only that, but I actually *know* that
Maven has been changed/patched so I can't even check it against the
published checksum/signature. And that's assuming the Guix devs (who
are usually neither Java nor Maven experts) did not make any honest
mistakes. And, again, if my Guix Maven somehow misbehaves I cannot ask
for support from the Maven community because I'm not running a stock
Maven.

It would make much more sense to download the same tarball from, say,
3 different mirrors and confirm that they all have the same
checksum/signature as published on the Maven download page. Then get
Maven's source code (for the same version) and build it with the
binary Maven you just downloaded. Check that the
Maven-built-from-source's checksum and signature match the published
checksum/signature, and voila! An ordinary user would not go through
all that trouble so now you are actually adding value. Moreover, this
*objectively* proves that Maven was not manipulated. I don't have to
trust you not to do anything nefarious nor do I have to take it on
faith that you didn't make any mistakes.

(By the way, I run Gentoo GNU/Linux so I am very familiar with
building from source. For me (and Gentoo) it's more about control and
performance than anything else, though.)

> And this means, that neither adding JARs from Maven Central to the store
> nor putting the maven tar-ball into the store are admissible options for
> Guix. I know other distributions do, like NixOS, but Guix will not.

I can appreciate not wanting to add "random" JARs from Maven Central,
although getting published on Maven Central actually requires going
through a manual process that involves proof of ownership (of the
project). But, still, building such a JAR from source (once Maven is
available) takes little effort and so is worth it. Especially, because
most projects do not publish a checksum and signature. So here
building from source adds value.

> Sadly maven does not support building from source. Even the maven
> "source" includes a jar-file (maven-ant-task), which's job is to
> download JAR files from maven central. So I have a take a lot of effort
> building all (minimum) requirements, manually recreating e.g. meta-data
> files which maven creates, and that like. Most of these packages rely on
> maven for buiilding - which is not yet available.

:-) Well, no, of course not. Maven isn't at the pre alpha state
anymore. So in the spirit of "eat your own dogfood", Maven builds with
Maven.

> My actual gaol is to have some Java applications I need in Guix – but
> the Guix way :-) And this requires to be able to build JARs which are
> build using maven, and for this I need to be able to bootstrap maven
> from source.

Right, that makes perfect sense except for the part where you jump
through hoops and make unexpected changes to Maven just to be able to
build it in a highly unorthodox way. ;-) :-)

> Am 23.04.2017 um 20:43 schrieb Hilco Wijbenga: I had a look at
>> maven-with-guix-versions.patch and I notice that you are changing
>> various version numbers and replacing some JARs with other JARs. Why
>> would you do that? Why do you expect the end result to work well? Or
>> at all? How would anyone be able to trust this patched Maven?
> I assume you are referring so the patch I posted month ago, which is is
> outdated now. For the current status, please have a look at the branch
> "WIP-maven" at https://gitlab.com/htgoebel/guix.git. My question refer
> to this status.
>
> This branch also uses some different versions, but the tar-ball maven
> builds and runs fine when using these versions. See
> https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00536.html for
> details on how I came to this conclusion.

Yes, that's where I looked. That's why I checked the patch file.

>> I hope this is of use to you. If you have more questions, ask away.
>
> If you have an idea what could cause the error I posted, please give fixing 
> it a try. You can find the Guix description at the branch "WIP-maven" at 
> https://gitlab.com/htgoebel/guix.git.

According to msg00536 you patched Maven to use different JARs and
versions. Obviously, that creates a problem so don't do that. Stick
with the JARs/versions that Maven was built with and all will be well.
Going by bin/mvn, you should probably invoke Maven using
org.codehaus.plexus.classworlds.launcher.Launcher instead of
org.apache.maven.cli.MavenCli. But you would be much better off if you
dropped this whole approach as I mentioned above. Even if you somehow
made it work, it would be unreliable.

Cheers,
Hilco