From owner-freebsd-ports@freebsd.org Tue Jun 7 22:26:46 2016 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C26AB6D27B for ; Tue, 7 Jun 2016 22:26:46 +0000 (UTC) (envelope-from mi+oro@aldan.algebra.com) Received: from vms173017pub.verizon.net (vms173017pub.verizon.net [206.46.173.17]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DE4DA1232; Tue, 7 Jun 2016 22:26:43 +0000 (UTC) (envelope-from mi+oro@aldan.algebra.com) Received: from vz-proxy-m005.mx.aol.com ([64.236.83.15]) by vms173017.mailsrvcs.net (Oracle Communications Messaging Server 7.0.5.32.0 64bit (built Jul 16 2014)) with ESMTPA id <0O8F00AF67JS0UA0@vms173017.mailsrvcs.net>; Tue, 07 Jun 2016 16:26:21 -0500 (CDT) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=Nc0brD34 c=1 sm=1 tr=0 a=NimJJ1rWho3RDXpqkQh0Zg==:117 a=pD_ry4oyNxEA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=XyNkT6AWKRbtJzirpyUA:9 a=QEXdDO2ut3YA:10 a=JnXXqFm9kBBqcp0jT58A:9 a=twdp1yP4JajsTAbJ:21 a=_W_S_7VecoQA:10 Received: by 100.1.241.90 with SMTP id 486e73e6; Tue, 07 Jun 2016 21:26:21 GMT To: freebsd-ports@FreeBSD.org From: "Mikhail T." Subject: Building JAVA-applications with maven Cc: yerenkow@gmail.com, portmgr@FreeBSD.org Message-id: Date: Tue, 07 Jun 2016 17:26:17 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 22:26:46 -0000 Application-authors using maven tend to rely on the tool to download -- at build-time -- the third-party JARs their application needs to build and/or run. The number of such downloads can be substantial. For example, to build jruby from source (which the port is not currently doing), mvn downloads over 300 JAR-files. This poses obvious challenges for all porters -- be they FreeBSD ports, Net/OpenBSD pkgsrc, or even Linux RPM/deb maintainers. I think, we'd all like: 1. the downloads to happen at the download stage (a.k.a. make fetch) 2. the checksums of the downloaded files to be verified (although maven can do this itself) 3. the downloaded JARs to be shared between multiple users -- mvn would stick them into ${HOME}/.m2 if allowed 4. the downloaded JARs to survive make clean -- so they should not be under ${WRKDIR} either 5. to avoid downloads and bundling of JARs, which are parts of other, already ported packages and applications -- right now I count 18 (!) ports, which bundle junit.jar, for example -- a shame. Currently the ports of maven-using applications seem to either resign to simply installing pre-built JAVA-applications (instead of building them from source as port ought to), or -- like eclipse -- using pre-bundled dependencies. Neither is very satisfactory... Ports-system needs some way of dealing with these issues properly and orderly. What should the strategy be? How about allowing a port to declare the following needs, which would be taken care of for it: 1. It needs the following JARs, which /aren't/ already available from other ports, downloaded -- into ${DISTDIR}/jars or some such. 2. It needs its pom.xml file(s) patched to use the following list of JARs, which /are/ available from other ports, directly. (Hopefully, the JARs on the first list of each port will gradually make its way into the second.) This may still leave the a. and b. unsatisfied -- or partially satisfied -- but those really are the least important of the problems. The item 2. may be "hairy" -- somewhat like the patching of libtool and friends we've had for some time. But it is doable... Does this seem like a valid concern? Does the proposal seem like a good idea? Anyone up to creating Uses/maven.mk? Even just testing the new facility with a port of their own would be helpful... -mi