Hi, would you give us some hints what you are trying to do? Is this related to the Lucene build system and are you preparing a PR or is this some Amazon-only rewrite? In the latter case, can't you not wrap the execution of gradlew in your "internal" build system? You can also configure gradle to fetch dependencies from other repositories than maven central.
Uwe ----- Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: [email protected] > -----Original Message----- > From: Michael Sokolov <[email protected]> > Sent: Thursday, August 19, 2021 5:18 AM > To: Lucene Dev <[email protected]> > Subject: Re: Gradle HELP > > 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(TestRuleSetup > AndRestoreClassEnv.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/clas > ses/java/test, > > > > /local/home/sokolovm/workspace/lucene/src/Lucene/lucene/codecs/build/reso > urces/test, > > > > /local/home/sokolovm/workspace/lucene/src/Lucene/lucene/codecs/build/clas > ses/java/main, > > > > /local/home/sokolovm/workspace/lucene/src/Lucene/lucene/codecs/build/reso > urces/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/randomizedtesti > ng-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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
