Re: [ee4j-build] Artifact caching

[Frederic Gurr <frederic.gurr@xxxxxxxxxxxxxxxxxxxxxx>]

Hi,

On 18.10.18 12:05, Tomas Kraus wrote:
> Hi Frederic and Mikael,
> 
> I saw several build jobs failed with
> 
> [ERROR] Plugin some.group.id:some-artefact:pom:1.2.3 or one of its dependencies could not be resolved:
>         Failed to read artifact descriptor for some.group.id:some-artefact:pom:1.2.3:
>         Could not transfer artifact some.group.id:some-artefact:pom:1.2.3 from/to central
>         (https://repo.maven.apache.org/maven2): Connection reset -> [Help 1]
> 
> With current setup, each job always downloads all the artifacts from
> maven central again and again. This looks like central servers are
> refusing requests from eclipse.org from time to time.
Yes, this is a known problem.

> Did you consider some way of caching?
Yes :)

> 1. there can be some local nexus cache on your machines which can speed
> up downloading and reduce number of central download requests
Every EE4J JIPP already has a Maven settings file set up that specifies
our local Nexus instance as cache for Maven Central. Unfortunately in
the new infra we have not found a way to make this the default Maven
settings file for _all_ Maven builds. That's why you need to specify it
manually.

In a freestyle job - if you haven't already - you need to inject the
settings file as a config file and set a variable (e.g. MVNSETTINGS),
which you can reference later with "mvn -s $MVNSETTINGS clean verify
[...]". The name of the settings file has the format
settings-<projectshortname>.xml, e.g. settings-metro.xml.

I will also add this to the wiki.

> 2. some permanent workspace for each job with maven repository
> (~/.m2/repository) pointing there may reduce job download requests as well
We have set this up for the glassfish project, but we probably won't set
this up for each project.

> 
> Today my https://jenkins.eclipse.org/metro/job/wsit-ee4j8-build/ failed
> for 3rd time in a row with this error, but each time it was different
> artifact in random phase of the build. That's why I think we need at
> least some way of artifacts caching.
> 
> 
> Tomas
>

Regards,

Fred

-- 
Frederic Gurr
Release Engineer | Eclipse Foundation Europe GmbH

Annastr. 44, D-64673 Zwingenberg
Handelsregister: Darmstadt HRB 92821
Managing Directors: Ralph Mueller, Mike Milinkovich, Chris Laroque