Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Jul 2019 07:08:56 -0500
From:      Jimmy Kelley <ljboiler@gmail.com>
To:        freebsd-ports@freebsd.org
Subject:   Re: How to package maven based ports
Message-ID:  <4C4DBC58-F44E-4435-BC92-37A19D555243@gmail.com>

next in thread | raw e-mail | index | archive | help


Sent from my iPhone

> On Jul 20, 2019, at 14:33, Daniel Morante <daniel@morante.net> wrote:
>=20
> 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.
>=20
>> 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.  D=
on't take this personally, I applaud you for taking the time and effort in m=
aking the Eclipse port.  I use it on my systems.  However, I feel that it's i=
mportant that I point this out.  There are potential problems with this appr=
oach.  Most notably that the source of the dependencies gets changed from th=
e original location.  The consequences could be serious should something hap=
pen to your repository.
>=20
> This in my opinion is a bigger issue caused by these so called 'modern' pa=
ckage managers that are becoming popular to use (maven, npm, yarn, and compo=
ser to name a few).  Historically like what is currently done with perl and p=
ython (and to a lesser extent ruby), we would create ports for each of these=
 libraries and let the ports system handle the rest.
>=20
> Ideally the FreeBSD ports system should have the needed tooling to fetch t=
hese type of dependencies as part of the same process used during the dist f=
iles 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 t=
o 'pre-warm' a local cache as you are doing.  Then set the environment to us=
e the local cache instead of downloading during the build phase.
>=20
> I think this may be possible to hack together using the current make targe=
ts 'pre-fetch' and 'post-fetch'?  Further thinking about this, having the po=
m.xml in the skeleton may not even be needed is you can use the post-fetch t=
arget?
>=20
>> 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.
>>>=20
>>> You can create a localised repository that only contains the
>>> dependancies required by the project by specifying:
>>>   -D maven.repo.local=3D/my/local/repo
>>>=20
>>> 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.
>>=20
>> Now I need someone for testing the port, as I do not use it and are
>> therefor I'm not able to test it.
>>=20
>> The final step would be to do some clean up a make the port more pretty.
>>=20
>> I try later to write a short summary if some one else needs to build a
>> port with maven how it could be done.
>>=20
>> Gru=C3=9F
>> Matthias
>>=20
While using a pre-warmed repository does change the source of the dependenci=
es, one thing it protects you  from is when a specific version of a needed d=
ependency is suddenly removed from the source repo.  I saw this happen too m=
any times working the Eclipse port over the years (and thanks Jonathan for t=
aking this over) - Eclipse would be released being built against a snapshot v=
ersion of something and two weeks later an official release of that =E2=80=98=
something=E2=80=99 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 mav=
en 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 a=
ll projects - definitely not something as complex as a Eclipse.

Jimmy=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C4DBC58-F44E-4435-BC92-37A19D555243>