Return-Path: 
 <users-return-134224-apmail-maven-users-archive=maven.apache.org@maven.apache.org>
X-Original-To: apmail-maven-users-archive@www.apache.org
Delivered-To: apmail-maven-users-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 974D3109A1
	for <apmail-maven-users-archive@www.apache.org>;
 Thu, 31 Oct 2013 01:01:32 +0000 (UTC)
Received: (qmail 51987 invoked by uid 500); 31 Oct 2013 01:01:30 -0000
Delivered-To: apmail-maven-users-archive@maven.apache.org
Received: (qmail 51795 invoked by uid 500); 31 Oct 2013 01:01:29 -0000
Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:users-unsubscribe@maven.apache.org>
List-Help: <mailto:users-help@maven.apache.org>
List-Post: <mailto:users@maven.apache.org>
List-Id: "Maven Users List" <users.maven.apache.org>
Reply-To: "Maven Users List" <users@maven.apache.org>
Delivered-To: mailing list users@maven.apache.org
Received: (qmail 51784 invoked by uid 99); 31 Oct 2013 01:01:29 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 Oct 2013 01:01:29 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
	tests=RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of baerrach@gmail.com designates
 209.85.220.176 as permitted sender)
Received: from [209.85.220.176] (HELO mail-vc0-f176.google.com)
 (209.85.220.176)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 Oct 2013 01:01:24 +0000
Received: by mail-vc0-f176.google.com with SMTP id ia6so1454789vcb.7
        for <users@maven.apache.org>; Wed, 30 Oct 2013 18:01:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=otNPx7eUVtc0ULRF9p3SVvYB0IZxZonKHXDUtswoN88=;
        b=QhlPJcznM/gXzMl49UFSjg+E4vQqiknjyFkLmWMbwQLsJucOnEmUEBWpu9+3EA7++n
         552EHaFwqpGdMItl5Yr56qlh5bCvbo7kPVU0Kq0f53jt4juBqXiHcevBCaOiQFQUKMhC
         jKIMmAAAWtz+ZXnCZrZY8KMorMKTIrYOpEd/sHbOTcGh184E/iUKy/gIhuxNxgInALUl
         ErjQFN23FRNCdngde8KrG5qb0y/eCNm6yYPv02q43apV48snqOlvqDRlwnwjxN1OZFSg
         4nnl2S+FXDwSlnBn1SVWZaInYF0hpxfImGs2xLyn+rWErzYexhEtpaHxSrh3jAG4/tKE
         CPPw==
MIME-Version: 1.0
X-Received: by 10.220.196.66 with SMTP id ef2mr224770vcb.7.1383181262874; Wed,
 30 Oct 2013 18:01:02 -0700 (PDT)
Received: by 10.58.163.65 with HTTP; Wed, 30 Oct 2013 18:01:02 -0700 (PDT)
In-Reply-To: <vpqvc0fm806.fsf@anie.imag.fr>
References: <1617140979.4777131.1383039481273.JavaMail.root@imag.fr>
	<58EAA08AF8232344ADDB2E31D4996BFD3E3023BA@SMAPEXCHIDAG3.prod.ad.merc.chicago.cme.com>
	<CADVp3v-hkN3zOZ+suzb3=wu4BViMeHdR7V4zmLVcm2tUw7-0Dg@mail.gmail.com>
	<vpqvc0fm806.fsf@anie.imag.fr>
Date: Thu, 31 Oct 2013 11:31:02 +1030
Message-ID: 
 <CADVp3v_hOo9LYyzvEPwcPb67167rABAzfnBf7v=zAsLE_euSHA@mail.gmail.com>
Subject: Re: System-wide, read-only repository
From: Barrie Treloar <baerrach@gmail.com>
To: Maven Users List <users@maven.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Virus-Checked: Checked by ClamAV on apache.org

On 30 October 2013 19:48, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> Local disk space is cheap. NFS-shared, RAID & backed-up disk space, less
> so. I can live with a few Gb of waste, but I was just wondering whether
> we could do any better.

As others have pointed out, its not possible to do better at the moment.

The students ~/.m2 does not need to be backed-up/NFS/RAID as
everything is generated. Local disk on each machine is fine.  As long
as you have a Maven Repository Manager to cache the central artifacts,
otherwise it will be too slow to re-seed the local Maven cache (i.e.
~/.m2/repository).

I'd put things the student's local Maven cache in /tmp/maven_cache/<userid>.
It doesn't need to survive reboots.
Depending on your level of trust, you will need to write scripts to
scan these directories for unauthorized files being squirreled here.

If you are doing full release cycles then you will also need somewhere
for students to deploy their released artifacts.  The local Maven
cache is not where you deploy these, so its fine for the local cache
to get removed as the released artifacts will be fetched from the
deployed location.

A side benefit of local disk is that you wont get NFS latency and your
builds will continue to work when NFS is flaky.

>> If they dont have direct access to the internet,

Then you need to make sure there is sufficient documentation on how
they should configure Maven, if they are not connecting to their Maven
Repository Manager it will be too slow.
A simple FAQ "Why is Maven slow?" should fix that. And its a natural
penalty for those who cant follow instructions.


If you have advanced students then they might want to attempt to patch
maven so the local cache is thread safe. They'd need to also think
about how to handle failed/stalled downloads correctly so it doesn't
block everyone else using the cache. But you still have the problem
that people working on the same artifacts will be clobbering each
others build output.  So Stephen's suggestion of a "tiered" repository
layout would be necessary. And as Curtis points out it is something
that would be useful, especially for Jenkins, At the very least,
writing up some thoughts on the problem/solutions would be helpful.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org