From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hartmut Goebel Subject: Re: maven build system - new insights Date: Thu, 31 Jan 2019 23:48:44 +0100 Message-ID: References: <71F627FD-4E2E-4E8D-B73E-433368CE3B6B@lepiller.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([209.51.188.92]:60140) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gpL8e-0006eK-NY for guix-devel@gnu.org; Thu, 31 Jan 2019 17:48:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gpL8c-0001v6-K3 for guix-devel@gnu.org; Thu, 31 Jan 2019 17:48:52 -0500 Received: from mail-out.m-online.net ([212.18.0.9]:60341) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gpL8b-0001uK-Tw for guix-devel@gnu.org; Thu, 31 Jan 2019 17:48:50 -0500 In-Reply-To: <71F627FD-4E2E-4E8D-B73E-433368CE3B6B@lepiller.eu> Content-Language: en-US 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: Julien Lepiller , guix-devel Hi, Am 31.01.19 um 18:06 schrieb Julien Lepiller: Here are my 2cent: > We found that we need more plugins to be able to build maven projects, and that requires some metadata in the jar file. This metadata is generated by maven-plugin-tools-generators, and maybe we can write a thin java wrapper around it, or use sxml to generate the file. Regarding the thin java layer it might be interesting to have a look at Debians build helpers which might contains some of what we need. Unfortunately it is not well documented (at least i did not find it quickly), but asking the Debian Java packagers might be helpful. > If we are going to use mvn and not xmvn, we could change the ant-build-system to generate the repository structure you describe There seems to be a maven task for doing so: install:install-file [1]. > and have a phase to build a union of these with symlinks. Hopefully, maven will follow the symlinks. The drawback of this approach is: This only works within the build-system. Since within a normal environment or profile, there will be no such unison repo. Thus for every day's work, users will still download artifacts from the Internet and will not be able to use those already installed on the system. One of the points I like at Xmvn is that is does not try to reach out to the internet. And users should be able to simply replace mvn by xmvn to ensure only "well known" packages are used. > It seems we don't need more info in the jar files themselves, but we need to install the pom.xml file alongside the jar itself. Additionnaly, we need "parent poms" because they contain properties and values used by our packages and maven will want to read those. For the jar an pom-files, install:install-file could help [1]. For the parent poms I have no idea, beside the Debians build helpers having some "DebianDependencies" class. > Xmvn looks very cool, but that's still 32 more packages to build properly and generate metadata for, so it's not clear if that's an advantage when we already have a maven package? I'm also a bit worried that it miqht not work properly, as it's an equivalent of 3.0.0, but we have a newer version of maven. Oh, I missed one relevant point: these 32 packages are also dependencies of maven. Thus they are already available. :-) It just that we most probable could throw out 16 packages from the manual bootstrap. (There are 3 additional xmvn packages, though.) The version 3.0.0 is the Xmvn version which seems to be unrelated to maven. Prior to going down the Xmvn-road we should collect a list of questions to ask the developers. E.g. [2] say: "Some parts of XMvn require Gradle". If we need these parts for bootstrapping this would be a show-stopper. > We will also need to override dependency and plugin versions for maven to find guix' versions, so we'll need a parser and generator for pom.xml files. Maybe some xml-search-replace would suffice? E.g. implemented using SXPATH [3] [1] https://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html [2] https://github.com/fedora-java/xmvn/blob/master/README.md [3] https://www.gnu.org/software/guile/manual/html_node/SXPath.html -- Regards Hartmut Goebel | Hartmut Goebel | h.goebel@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |