Date: Thu, 20 Apr 2017 12:10:59 +0300 From: Dmytro Bilokha <dmytro@posteo.net> To: Xavi Garcia <xavi.garcia@gmail.com> Cc: freebsd-ports@freebsd.org Subject: Re: Writing a port that needs to download a large number of files Message-ID: <8a87f1414c9f09e3d5023adbf0b8aba0@posteo.net> In-Reply-To: <CAPonemzVBczKZ8yATABJ6skHSLB4yffE4u4-NGLqOBR9yVXb3w@mail.gmail.com> References: <CAPonemzuMLP5CdBzkTp__1GGarm%2Bocda5TiCmjYp7tQ1Bk1KVg@mail.gmail.com> <39470c3e111a92fd41ad183a77ccc2ac@posteo.net> <CAPonemzVBczKZ8yATABJ6skHSLB4yffE4u4-NGLqOBR9yVXb3w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20.04.2017 11:02, Xavi Garcia wrote: > Hi, > Hi! > I'd definitely download a compiled version but the developer is > hosting the builds in Amazon S3 and you need to receive a token via > e-mail in order to download the files, which is awful in my opinion. > I agree with you, its awful. But, I saw ports which shows you a message like "Please download this file: http://blahblah... and put in in the distfiles, because of the license reasons it is not allowed to download it by automatic tool. Then run make again". It is not convenient, but possible if there are no another options. > The other option is to compile my own builds and host them somewhere > in the Internet. As for me, it would be the best option. But, be careful, it is possible that by software license you are not allowed to build your version of the application and provide it to users. > > Kind regards, > > Xavier Garcia > > 2017-04-19 22:29 GMT+02:00 Dmytro Bilokha <dmytro@posteo.net>: > >> On 19.04.2017 19:27, Xavi Garcia wrote: >> >>> Hi all, >>> >>> We are writing a port for a Java software that downloads a large >>> number of >>> jar files (around 200) with Gradle (https://gradle.org/ [1]), >>> that is similar >>> to other package managers like Pip or Ruby Gems but for Java >>> projects. >>> >>> What would be the best practice in this scenario? I am aware that >>> we can >>> only download files in the fetch phase but I am not sure if my >>> solution is >>> clean enough. >>> >>> We will be deploying this port in our servers via Portshaker and >>> Poudriere >>> but we would also like to commit it to the ports tree. >>> >>> In short, I am using the 'pre-fetch' phase together with >>> FETCH_DEPENDS to >>> drop the Gradle wrapper in ${DISTDIR}/${PORTNAME} and then I use >>> the >>> 'dependencies' task to download all the dependencies. >>> >>> The 'do-build' stage will run again the Gradle wrapper to build >>> the >>> software, but using the offline mode. >>> >>> You can find attached the Makefile. >>> >>> Kind regards, >>> >>> Xavier Garcia >> >> Hi! >> If you need examples of the "best practice", >> probably, you can take a look at already exsisting >> ports of Java software. >> >> For example, I've checked the Glassfish port and >> it was made with different approach: >> 1. During fetch phase distribution zip-file with >> already compiled Java classes is downloaded. >> 2. Then it is unzipped to some directory, like >> /usr/local/glassfish. >> 3. Some scripts put, package registered, etc. >> >> So here there is no building of Java app from sources, >> mostly fetching already built, some tweaking and putting >> to the right place. >> I saw similar procedure for some another ports >> of Java software. >> >> I am not sure, but it seems because of such reasons: >> 1. With Java you won't gain a lot with building application >> from sources. If OS has JVM you can just run already >> compiled -- it should work. >> 2. For port its better to have as least dependencies, >> as possible. So, making your port dependent on >> Gradle (which fast evolving itself) and/or another >> Java build tooling can make port fragile and not >> very stable. >> 3. Building the big Java project from sources could be >> time and traffic consuming task. Usualy users >> don't like this. >> >> --- >> Best regards, >> Dmytro Bilokha > > > > Links: > ------ > [1] https://gradle.org/ --- Best regards, Dmytro Bilokha
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8a87f1414c9f09e3d5023adbf0b8aba0>