OK I see it's because this build system puts the output in a different folder that is not covered by the security policy. phew.
On Wed, Aug 18, 2021 at 10:30 PM Michael Sokolov <[email protected]> wrote: > > Update: running tests with -Dtests.useSecurityManager=false got over > that hump. Not sure why the security manager would be behaving > differently in this setup... > > On Wed, Aug 18, 2021 at 6:41 PM Michael Sokolov <[email protected]> wrote: > > > > ah interesting. I may have broken it in the midst of debugging > > something else. I did manage to get most of the module jars built, and > > I'm moving on to trying to get tests to run. I'm running into what > > looks like more dependency/classpath resolution problems, but with our > > module-module dependencies. If anyone has a clue what might be going > > on or can suggest some futher debugging tips, I'd be very > > appreciative. Here are the gory details... > > > > > > For example, tests in o.a.l.codecs are failing because: > > > > org.apache.lucene.codecs.uniformsplit.TestUniformSplitPostingFormat > > > classMethod FAILED > > java.lang.ExceptionInInitializerError > > at org.apache.lucene.codecs.Codec.getDefault(Codec.java:141) > > at > > org.apache.lucene.util.TestRuleSetupAndRestoreClassEnv.before(TestRuleSetupAndRestoreClassEnv.java:133) > > ... > > java.lang.IllegalArgumentException: An SPI class of type > > org.apache.lucene.codecs.Codec with name 'Lucene90' does not exist. > > You need to add the corresponding JAR file supporting this SPI to your > > classpath. The current classpath supports the following names: > > [SimpleText] > > > > and I print out the classpath used to run the test by: > > > > tasks.withType(Test) { > > doFirst { > > println "Test $allJvmArgs" > > println "Test classpath " + classpath.getFiles().toString() > > } > > } > > > > and the classpath includes > > > > ...build/lib/lucene-core-9.0.jar > > > > and that jar includes > > > > -rw-r--r-- 843 18-Aug-2021 21:40:50 > > META-INF/services/org.apache.lucene.codecs.Codec > > > > which has the expected content -- so I am kind of confused. Are these > > Codec files supposed to be merged together? Or is this a conflict > > resolved by classpath-order? > > > > and there are other dependency issues, but I think it would just be > > more confusing to list them all here. > > > > PS: full listing below: > > > > Test classpath > > [/local/home/sokolovm/workspace/lucene/src/Lucene/lucene/codecs/build/classes/java/test, > > /local/home/sokolovm/workspace/lucene/src/Lucene/lucene/codecs/build/resources/test, > > /local/home/sokolovm/workspace/lucene/src/Lucene/lucene/codecs/build/classes/java/main, > > /local/home/sokolovm/workspace/lucene/src/Lucene/lucene/codecs/build/resources/main, > > /local/home/sokolovm/workspace/lucene/src/Lucene/build/lib/lucene-test-framework-9.0_az.jar, > > /local/home/sokolovm/workspace/lucene/src/Lucene/build/lib/lucene-codecs-9.0_az.jar, > > /local/home/sokolovm/workspace/lucene/src/Lucene/build/lib/lucene-core-9.0_az.jar, > > /local/home/sokolovm/workspace/lucene/env/gradle-cache-2/brazil/junit/4.12/junit-4.12.jar, > > /local/home/sokolovm/workspace/lucene/env/gradle-cache-2/brazil/Hamcrest/1.3/Hamcrest-1.3.jar, > > /local/home/sokolovm/.gradle/caches/modules-2/files-2.1/com.carrotsearch.randomizedtesting/randomizedtesting-runner/2.7.2/84ed6b5f70906f9ef173db67ccde657b43ea60df/randomizedtesting-runner-2.7.2.jar, > > /local/home/sokolovm/.gradle/caches/modules-2/files-2.1/junit/junit/4.12/2973d150c0dc1fefe998f834810d68f278ea58ec/junit-4.12.jar, > > /local/home/sokolovm/.gradle/caches/modules-2/files-2.1/org.hamcrest/hamcrest-core/1.3/42a25dc3219429f0e5d060061f71acb49bf010a0/hamcrest-core-1.3.jar, > > /local/home/sokolovm/.gradle/caches/modules-2/files-2.1/org.hamcrest/java-hamcrest/2.0.0.0/f1c8853ade0ecf707f5a261c830e98893983813/java-hamcrest-2.0.0.0.jar] > > > > On Wed, Aug 18, 2021 at 4:30 PM Mike Drob <[email protected]> wrote: > > > > > > I believe it is one of the built in gradle tasks available to us. > > > https://docs.gradle.org/current/userguide/dependency_locking.html > > > > > > On Wed, Aug 18, 2021 at 3:22 PM Michael Sokolov <[email protected]> > > > wrote: > > > > > > > > I am trying to get Lucene to build in a very "special" build system > > > > based on Gradle, and I am stumbling across all kinds of things I don't > > > > really understand (which is most of everything about gradle at this > > > > point). Cookie cutter cargo cultism is getting me pretty far, but one > > > > thing I don't understand: we have this in the precommit task: > > > > > > > > // Root-level validation tasks. > > > > dependsOn ":verifyLocks" > > > > dependsOn ":versionsPropsAreSorted" > > > > dependsOn ":checkWorkingCopyClean" > > > > > > > > What is the "verifyLocks" task? I can't seem to find it defined anywhere > > > > > > > > -Mike > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
