How to package maven based ports

[Jimmy Kelley]

Sent from my iPhone

> On Jul 20, 2019, at 14:33, Daniel Morante <daniel at morante.net> wrote:
> 
> I've run into the same issue while attempting to port a few JAVA apps that use maven and more recently one that also uses yarn for dependencies.
> 
>> Have a look at the java/eclipse port. It uses a pre-warmed maven
>> repository that is fetched from github.
> While this is indeed a clever solution, it's (in my opinion) not ideal.  Don't take this personally, I applaud you for taking the time and effort in making the Eclipse port.  I use it on my systems.  However, I feel that it's important that I point this out.  There are potential problems with this approach.  Most notably that the source of the dependencies gets changed from the original location.  The consequences could be serious should something happen to your repository.
> 
> This in my opinion is a bigger issue caused by these so called 'modern' package managers that are becoming popular to use (maven, npm, yarn, and composer to name a few).  Historically like what is currently done with perl and python (and to a lesser extent ruby), we would create ports for each of these libraries and let the ports system handle the rest.
> 
> Ideally the FreeBSD ports system should have the needed tooling to fetch these type of dependencies as part of the same process used during the dist files retrieval step.  One method would be for the porter to include the pom.xml, composer.json, and/or package.json files as part of the port skeleton.  The ports system would (using appropriate tools) download the dependencies to 'pre-warm' a local cache as you are doing.  Then set the environment to use the local cache instead of downloading during the build phase.
> 
> I think this may be possible to hack together using the current make targets 'pre-fetch' and 'post-fetch'?  Further thinking about this, having the pom.xml in the skeleton may not even be needed is you can use the post-fetch target?
> 
>> On 7/14/2019 3:21 PM, Matthias Fechner wrote:
>>> Am 14.07.2019 um 00:23 schrieb Jonathan Chen:
>>> Have a look at the java/eclipse port. It uses a pre-warmed maven
>>> repository that is fetched from github.
>>> 
>>> You can create a localised repository that only contains the
>>> dependancies required by the project by specifying:
>>>   -D maven.repo.local=/my/local/repo
>>> 
>>> Once your project builds correctly, you can create a repo as a project
>>> on Github with its contents that can be retrieved with the port for
>>> the build.
>> thanks a lot for this.
>> I'm not fully done with the port, but I was able to get this maven
>> repository to be pushed to github and the port downloads it and
>> compilation works as expected.
>> Thanks a lot for you answer, it helped a lot.
>> 
>> Now I need someone for testing the port, as I do not use it and are
>> therefor I'm not able to test it.
>> 
>> The final step would be to do some clean up a make the port more pretty.
>> 
>> I try later to write a short summary if some one else needs to build a
>> port with maven how it could be done.
>> 
>> Gruß
>> Matthias
>> 
While using a pre-warmed repository does change the source of the dependencies, one thing it protects you  from is when a specific version of a needed dependency is suddenly removed from the source repo.  I saw this happen too many times working the Eclipse port over the years (and thanks Jonathan for taking this over) - Eclipse would be released being built against a snapshot version of something and two weeks later an official release of that ‘something’ is pushed out and the snapshot repo is deleted.

And while it way work for simple projects to be able to use the built-in maven capability to just resolve and download dependencies (and do nothing else) as a single command in the port fetching phases, this might not work for all projects - definitely not something as complex as a Eclipse.

Jimmy