From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hilco Wijbenga Subject: Re: Help needed from Java developer to finish maven Date: Sun, 23 Apr 2017 18:20:58 -0700 Message-ID: References: <58F9E310.4070201@crazy-compilers.com> <22f7c69e-da5c-6652-ecc4-13b97e83506b@crazy-compilers.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d2Sgs-0006uI-02 for guix-devel@gnu.org; Sun, 23 Apr 2017 21:21:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d2Sgq-0003eU-CA for guix-devel@gnu.org; Sun, 23 Apr 2017 21:21:21 -0400 Received: from mail-yw0-x22b.google.com ([2607:f8b0:4002:c05::22b]:36522) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d2Sgq-0003eP-6i for guix-devel@gnu.org; Sun, 23 Apr 2017 21:21:20 -0400 Received: by mail-yw0-x22b.google.com with SMTP id l18so11820293ywh.3 for ; Sun, 23 Apr 2017 18:21:19 -0700 (PDT) In-Reply-To: <22f7c69e-da5c-6652-ecc4-13b97e83506b@crazy-compilers.com> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Hartmut Goebel Cc: guix-devel Hi Hartmut, On 23 April 2017 at 13:34, Hartmut Goebel wr= ote: > 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 =E2=80=93= 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 fixi= ng 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