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]
