No, not quite.
Your internal Nexus will act as a caching layer. You won't make repeated
calls to Maven central, or other external repos. But Maven will always
still use a local repository to cache artifacts right on the machine
performing the Maven command. And as Baptiste mentioned, this is not safe
to share.
If you are using the MavenBuild type then Jenkins can create one local repo
per executor. If you are using mostly FreestyleBuild type jobs, then you
can actually add a flag like this to every Maven command:
-Dmaven.repo.local=${JENKINS_HOME}/${EXECUTOR_NUMBER}
to get mostly the same effect. It's a good compromise between a global
local repo (impossible) and separate local repos for every job. You'll
probably find that many projects share a lot of common dependencies (and
transitive dependencies) so you'll have lots of cache hits once a local
repo is sufficiently populated.
As far as cleanup goes, we purge the local repos every morning. Since the
local repos have predictable paths, it's very easy to write a System Groovy
script which iterates over jenkins.model.Jenkins#getComputers() and removes
all local repos.
This mechanism allows us to waste almost no disk space and provides very
good performance. We get about one ticket per quarter WRT corrupt artifacts
in the local repo, which is very good.
On Monday, February 24, 2014 1:40:54 PM UTC-5, Seena Kasmai wrote:
>
> We use Nexus as our snapshot and release repositories; If we instruct all
> of our maven installations (on each slave) to download everything from
> nexus (i.e. like
> this<https://support.sonatype.com/entries/20943003-Configure-Maven-to-Download-from-Nexus>),
>
> would Jenkins+Maven-plugin effectively now use nexus as its local maven
> repo (cache), or local m2. checks will always happen before going to remote
> nexus?
>
> appreciate the feedback.
>
> --Seena
>
>
>
>
> On Saturday, February 22, 2014 9:59:45 AM UTC-5, Baptiste Mathus wrote:
>>
>> This is actually unsafe. You take the risk to corrupt the "maven local
>> repository" (badly named, think more about it like a cache). And there's
>> also potential issues of having a stale dependency installed in the local
>> cache/repository (and if it's not a snapshot, it will never be downloaded
>> again unless you delete it).
>>
>> In your case, as you're likely to have many executors per slave (which
>> btw i wouldn't recommend) the probability to corrupt the cache is even
>> bigger.
>> Then, on top of that, using NFS increases the risk even more, since (your
>> executors count) processes will access the cache concurrently.
>>
>> Having a 'private' repository and cleaning it up on a regular basis is in
>> fact simple and quite straightforward. The only downside is the disk space,
>> but as having more disks is certainly cheaper than spending time to debug
>> corrupted repository issues.
>>
>> Hth
>> Le 21 févr. 2014 17:08, "Seena Kasmai" <see...@gmail.com> a écrit :
>>
>>> Greetings -
>>>
>>> It seems there is an outstanding maven issue "Concurrent-safe access to
>>> local Maven repository <http://jira.codehaus.org/browse/MNG-2802>"
>>> which would advise against setting up all Jenkins servers to use a shared
>>> (e.g NFS mount) maven local repo - Can anyone confirm or share experience
>>> on how unsafe this would be?
>>>
>>> The issue with having different repo is managing the cleaning up for
>>> each and also not optimized when running same job in different slaves, all
>>> maven artifacts have to be republished etc...(this is for a setup of 1000s
>>> of jobs across 10 slaves)
>>>
>>> Any suggestions/advise would be helpful.
>>>
>>> Thanks,
>>> --Seena
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-use...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
