Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
Description
In a variety of scenarios one may want to verify that a change to a dependency of Solr will fix a problem in Solr or that a fix for the dependency isn't going to be disruptive to solr. Currently this is very difficult because our tests define a security policy that prohibits access to ~/.m2/repository
Most folks can figure out that they need to get the build to look at mavenLocal() and this is expert usage so we may or may not want to ease that (it works to put it in the repositories block of globals.gradle).
However, it recently took me hours to realize that not only was a security manager in play with the tests, but the tests use a completely different policy file than solr uses as an application (so tracking it down via the enablement instructions for Solr 8 led me to exactly the wrong place!) This situation was made doubly confusing by the fact that Java swallows security exceptions relating to Classpath loaded files (apparently by design), and the lucene error message was slightly misleading because it only mentioned file existence, and not the possibility that the file would be silently ignored by a SecurityManager (https://github.com/apache/lucene/issues/12300)
We may also wish to better document the existence of options in gradle/lucene-dev/lucene-dev-repo-composite.gradle for the lucene case in particular (something in /dev-docs/ ? ) but that's a separate issue.
So this ticket will add an entry to only the solr-tests.policy file allowing access to <user.home>/.m2/repository
Thus if folks do the dependency dance described in dev-docs/dependency-upgrades.adoc and add the mavenLocal() reference that should be sufficient to run the tests against a modified dependency.
