On 30 October 2013 19:48, Matthieu Moy <matthieu....@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
