How do I migrate an Artifactory repo to a shared filesystem repo?

1
votes

I teach high school computer science using Scala and I've managed to set up an Artifactory repo so that when my students download dependencies, we're doing most of our downloading inside the lab, rather than over the internet.

However, all our home folders are on a network drive and the terminals the students use don't have their own hard disks, so it seems silly to have dozens of copies of the same dependencies. Unfortunately, even with an Artifactory repo, SBT/Ivy copies all the artifacts into each user's ~/.ivy2/cache directory.

I've heard that, if I set up a shared filesystem repo then the artifacts won't be copied. What I can't figure out is how to export all the artifacts that Artifactory has cached for me in a format that would be recognized as a filesystem repo. (Exporting normally puts each remote repo in a separate folder that I suppose I'd have to somehow unify, but I'm not exactly sure how to do that. If that's the easiest thing to do, please explain how carefully.)

What I think I'd like to export is the remote-repos virtual repository, but that's not available as a choice on the Export page.

The other tricky part of this is that the same build file should be usable at home, where there is no proxy repo, so I'm relying on the fact that I can use /etc/sbt/sbtopts to override the repository resolution within the lab environment.

3
sbtivyartifactory
As often happens, after I submitted this, I had a brain-storm. If I let SBT copy all the dependencies for my projects into my ~/.ivy2/cache, could I then copy the contents into a directory and label that as my shared filesystem repo? – Todd O'Bryan

3 Answers

1
votes

Change Ivy home

Define your sbt script with ${SBT_OPTS}:

exec java -Xmx1512M -XX:MaxPermSize=512M ${SBT_OPTS} -jar /etc/sbt/sbt-launch-0.13.0.jar "$@"

Then only in your network environment set SBT_OPTS as:

$ export SBT_OPTS="-Dsbt.ivy.home=/etc/sbt/repository"

The students probably need writing rights to the dir.

0
votes

What you also can do is use davfs2 on Linux or "web folders" on Windows to simply mount Artifactory as a WebDAV resource (read-only). This avoids any indirection via a local file system, and keeping such a copy up to date.

0
votes

Unmanaged dependency

How about a solution that will get you out of Ivy?

In your original build using managed dependency, run

> show full-classpath

This should display something like the following:

[info]  List(Attributed(/home/foo/helloworld/target/scala-2.10/classes), Attributed(/home/foo/.ivy2/cache/com.eed3si9n/treehugger_2.10/jars/treehugger_2.10-0.3.0.jar), Attributed(/foo/.sbt/0.13.0/boot/scala-2.10.2/lib/scala-library.jar), Attributed(/home/foo/.ivy2/cache/com.github.scopt/scopt_2.10/jars/scopt_2.10-3.0.0.jar))

Create a directory named /shared/project1/lib or something and copy all the above jars in there, except for scala-library.jar.

Next, make a copy of your build and replace libraryDependency with the following:

unmanagedBase := file("/shared/project1/lib")

You should still be able to compile the code.