In the midst of all this hackery I have been using Gradle 6.9 and it seems to have support for Java 15 - should we switch? Might be easier than going to 7
On Thu, Aug 19, 2021 at 4:26 PM Michael Sokolov <[email protected]> wrote: > > ah nvm I see it is the wrong version of junit - I had 4.12 and need to > get to 4.13 > > On Thu, Aug 19, 2021 at 4:21 PM Michael Sokolov <[email protected]> wrote: > > > > Thanks for your sympathy :) I am told the situation here should > > improve soon... After working around the security policy I am able to > > run some tests, but I still have some dependency issues around junit > > methods -- I think maybe it's some issue w/hamcrest? What I see is > > most methods get resolved correctly, but eg assertThrows does not. > > > > I see we have this tricksy logic in test-framework's build.gradle: > > > > - api ("com.carrotsearch.randomizedtesting:randomizedtesting-runner", > > { > > - exclude group: "junit" > > - }) > > - api ("junit:junit", { > > - exclude group: "org.hamcrest" > > - }) > > - api ('org.hamcrest:hamcrest') > > > > and I wonder why we need these exclusions? > > > > > > On Thu, Aug 19, 2021 at 8:44 AM Dawid Weiss <[email protected]> wrote: > > > > > > Ok, clear. I understand the reasons these things are shielded from the > > > internet. I'm sure gradle folks have thought about such scenarios > > > though - gradle is used across enterprises with similar setups? I > > > really know nothing about it but I feel pretty confident artifact > > > resolution can be redirected to only known locations. Sorry you have > > > to hack around! > > > > > > Dawid > > > > > > On Thu, Aug 19, 2021 at 2:00 PM Michael Sokolov <[email protected]> > > > wrote: > > > > > > > > > This seems a tad insane? > > > > > > > > Agree, and yes it's an Amazon thing. Basically our build servers are > > > > not connected to the internet, and we use an internal repository and > > > > corresponding gradle plugin for resolving dependencies that is > > > > somewhat idiosyncratic (not Maven or anything else familiar, but acts > > > > kind of like Maven repo). Uwe, I am basically doing what you say, > > > > re-using as much as I can from our excellent Lucene build system, but > > > > wrapping alone is insufficient: I have to make invasive changes here > > > > and there. Believe me this will be a big improvement from the hacked > > > > ant build we have been using. > > > > > > > > On Thu, Aug 19, 2021 at 5:00 AM Uwe Schindler <[email protected]> wrote: > > > > > > > > > > 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] > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > 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]
