https://gradle.com/ logo
Join Slack
Powered by
<https://github.com/apache/iceberg/pull/10460>
# community-support
c
c
Did you check the output of the dependencies task? It’s likely given what you’re seeing that the runtime and compile classpaths are seeing different versions of Jackson.
c
I pasted the output of 
./gradlew :iceberg-mr:dependencies | grep 'com.fasterxml.jackson'
on the issue comment, I suppose the Jackson version should be consistent
c
Why did you pipe the output through grep? It’s a dependency tree it loses most if not all of it’s meaning when you start filtering lines.
and you lose the context of which configuration is which
 just save it to a file if it’s big and attach it to the issue.
c
I don’t think this is a simple “version not match” issue.
A common cause of 
NoSuchFieldError
is running with a different ABI (binary interface) than the code is compiled against, at runtime its unable to find 
ALLOW_LEADING_PLUS_SIGN_FOR_NUMBERS
.
The error indicates that 
ALLOW_LEADING_PLUS_SIGN_FOR_NUMBERS
isn’t available in the Jackson version that is being used at runtime when the test is executed. I checked and 
ALLOW_LEADING_PLUS_SIGN_FOR_NUMBERS
was introduced with Jackson 2.14, meaning that the test is using an earlier Jackson version.

that’s the likely cause. It would be helpful to run the test with 
--scan
and share that link.
c
@Chris I updated the whole dep tree in comment
c
@Chris Lee that should be visible in the dependencies output
 since we’ll be able to see the two dependency graphs used for the runtime and compile classpaths.
c
@Cheng Pan that scan is for the dependency graph output - possible to regenerate with invoking the problematic task?
c
this is quite useful built-in functionality to share the building report
👍 1
c
This stands out as being inconsistent between prod / test code
c
the code is located at src/test, I suppose that testCompileClasspath takes effect
c
I’ll generally use something like this to force the runtime classpath versions to match the compile classpath ones
Copy code
java {
                consistentResolution {
                    useCompileClasspathVersions()
                }
            }
Yes, if using defaults the code in 
src/test
uses the test* configurations - presumably your build script is adding dependencies to 
testImplementation
etc.
c
Copy code
+ implementation enforcedPlatform(libs.jackson.bom)
- testImplementation platform(libs.jackson.bom)
seems does not work too.
c
another variation on this issue is having Jackson on different classpaths - it looks like its also on the build script classpath (see 
Build dependencies
), pulled in by an OpenAPI Gradle plugin, at version 2.14.0 (difference than 2.14.2 using in other classpaths). May be worth confirming what specific jackson-core release added that enum value.
c
where can I find the gradle plugins dep tree? from this page?
c
Build Dependencies
on the left bar
c
I see
so, the plugins deps also present in classpath when running tests?
any workaround to isolate them? something like running test in a separate JVM with the exact declared test runtime classpath
c
they shouldn’t generally leak into runtime classpaths. there’s a bunch of other plugin stuff going on there - perhaps see if its possible to create a simple reproducer project, sidestepping plugins etc - just add the minimal deps needed to run a test that trips into the offending code.
c
thanks for the suggestion, let me investigate
v
Nah, they don't leak.
It's quite simple if you know it. 😄
org.apache.calcite.avatica:avatica:1.8.0
is misbehaving. It re-packages an old version of 
jackson-core
without shading it. You have that dependency in your 
test
classpaths and it comes in the classpath before the 
jackson-core
dependency. It does not contain 
com.fasterxml.jackson.core.json.JsonReadFeature
, so the one from 
jackson-core
is used. 
com.fasterxml.jackson.core.json.JsonReadFeature
of the newer 
jackson-core
uses 
com.fasterxml.jackson.core.JsonParser.Feature.ALLOW_LEADING_PLUS_SIGN_FOR_NUMBERS
in its static initialization. 
com.fasterxml.jackson.core.JsonParser.Feature
is taken from 
avatica
but is so old that it of course does not have that constant, so it fails.
c
Jesus 
 let me exclude 
avatica
and try
v
Or do not use a version released 2016
I'd say chances are high this was fixed in the last 8 years 😄
c
BTW, could you please share how to find these evil jars when I run into this situation
v
I cloned the project, let it synchronize and then checked which of the jars contains the problematic classes.
c
-verbose:class
is also a possibility
 that way you can see which jar the offending class is coming from
v
1.9.0 indeed fixed it with resolving this issue: https://issues.apache.org/jira/browse/CALCITE-1224
Before they relocated some but missed Jackson. After they released non-shaded version and a shaded version and fixed the relocation to include Jackson.
c
many thanks, test passed after excluding 
org.apache.calcite.avatica:avatica
👌 1
2 Views
Open in Slack
PreviousNext
Powered by