Writing a port that needs to download a large number of files

[Xavi Garcia]

Hi,

This can be the plan B if we cannot host the builds. I will discuss with
the colleagues.

My concern is accessing old builds, in case we are tracking a quarterly
branch for stability, because the developer is only offering builds for the
latest version.

Regarding the software we want to port, it is GPLv3 and it shouldn't be a
problem if we release our own builds.

Kind regards,

Xavier Garcia


2017-04-20 11:10 GMT+02:00 Dmytro Bilokha <dmytro at posteo.net>:

> 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 at 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
>
>