Poll: Who has a custom ivysettings.xml, and do you do anything special with your <caches/> ?

[Patrick Lawson]

Motivation: I'm working on a patch right now that will localize the directory ivy uses to write out resolution reports, while allowing us to keep the artifact repository (where all of the jars live) in the user's home directory.  This will eliminate a large class of bugs that can currently happen when pants is run concurrently in different workspaces on the same machine.  These bugs pop up a _lot_ on Jenkins.

In order for this patch to work, all custom ivysettings.xml will need to thread through a JVM-style property provided by pants in the <caches/> directive in ivysettings.xml.  Here's what the default should look like:

  <caches

    defaultCacheDir="${ivy.cache.repository.dir}"

    resolutionCacheDir="${ivy.cache.resolution.dir}"

    lockStrategy="artifact-lock-nio"

  />

I think this should be a really easy change, even if you have custom caches.  The issue is that it's tough to give a good error message to the user if they've failed to set these properly--instead the failure will happen downstream due to symlink/classpath issues.  So I'd like to figure out whether I should investigate a thorough way of generating such an error, or if this is a non-issue and we can get away with just ripping off the bandaid now.

[Eric Zundel Ayers]

Yes, we use a custom ivysettings.xml. Our current <caches> setting is just the boilerplate one:

  <caches default="default" lockStrategy="no-lock" useOrigin="false">
    <cache name="default" basedir="${ivy.cache.dir}"/>
  </caches>

We also have an ivysettings-publish.xml. Will it need to have this caches setting too?

Although I’m not sure that running multiple workspaces on the same machine is a configuration I’d recommend to others (use containerization instead), I would like to see the resolution reports somewhere other than the ~/.ivy2/pants cache dir.

​

[Patrick Lawson]

I'm not sure about the publish example--if pants doesn't rely on looking for the reports that publish produces, then it shouldn't matter.  But personally I'd recommend just setting up caches in all ivysettings as described above, since you have a custom ivysettings.xml anyway.  It should be strictly safer and just as performant, even if it isn't needed for publish.

[Paul Groudas (Urban Compass)]

We use a custom ivysettings to restrict access to an externally managed directory of jars for most use cases.

For example:

  <caches defaultCacheDir="${ivy.cache.dir}" ivyPattern="${s3-synced.repo.pom}" 
    artifactPattern="${s3-synced.repo.artifact}"
    useOrigin="true"
    lockStrategy="no-lock"/>

Will we just need to add to this the property resolutionCacheDir="${ivy.cache.resolution.dir}" ?

In that case I wouldn't go through the extra effort, provided that this note makes it into the release notes.