Run CI with GraalVM #2476

stevenschlansker · 2023-08-22T22:12:45Z

No description provided.

hgschmie · 2023-08-23T20:24:52Z

.github/workflows/graal-ci.yml

+
+      - name: build
+        env:
+          MAVEN_CONFIG: "-Dbasepom.check.skip-enforcer=false -B"


the ci.yml has -B -fae

Yes, I left this out intentionally, it is easier to track down errors when they are always at the end of the build log

sonarcloud · 2023-08-24T02:33:32Z

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

hgschmie · 2023-08-29T16:27:32Z

internal/build/pom.xml

-
+        <profile>
+            <id>native</id>
+            <activation>


all of the modules where this needs to be activated are packaging jars. can't we just use

<property> <name>packaging</name> <value>!pom</value> </property>

and avoid more dotfiles?

this actually does not work because maven only supports a single property for activation. sigh. maven is terrible.

hgschmie · 2023-08-29T16:29:00Z

internal/build/pom.xml

+                </file>
+            </activation>
+            <build>
+                <pluginManagement>


this should move outside the profile, into the pluginManagement section above.

hgschmie · 2023-08-29T16:29:13Z

internal/build/pom.xml

+                            <configuration>
+                                <!-- ... -->
+                            </configuration>
+                            <executions>


those should stay here, move into the <plugin> below.

hgschmie · 2023-09-01T04:54:47Z

Have you actually gotten this to work? I get

Failures (1):
  JUnit Jupiter
    => java.lang.NoSuchMethodError: java.lang.invoke.MethodHandle.close()
       org.junit.jupiter.engine.descriptor.AbstractExtensionContext.<clinit>(AbstractExtensionContext.java:43)
       java.base@17.0.6/java.lang.Class.ensureInitialized(DynamicHub.java:528)

stevenschlansker · 2023-09-01T20:24:47Z

No, I got stuck there for now. I will take another look at some point.

Eng-Fouad · 2023-11-20T23:09:24Z

Any progress on this? Thanks.

stevenschlansker · 2023-11-21T17:28:18Z

Hi @Eng-Fouad , sorry I did not look any more yet. I did try the suggested junit configuration tweaks but still ran into the NoSuchMethodError above, and didn't really have the tools to understand what went wrong.
I will take a look again at some point but cannot promise urgency. Please feel free to take the current work and experiment and see if you can make it work.

We will get this working eventually.

stevenschlansker · 2023-11-21T23:46:21Z

I rebased the branch and adopted the latest version of the native plugin. Let's see how the build does.

stevenschlansker · 2023-11-22T00:30:22Z

Ok, the good news is the newer Graal and plugin versions seem to make development a lot easier.

stevenschlansker · 2023-11-22T00:54:06Z

Now I am stuck on getting Mockito to work.

  JUnit Jupiter:TestArgumentsRegistry:testWaffleLong()
    MethodSource [className = 'org.jdbi.v3.core.argument.TestArgumentsRegistry', methodName = 'testWaffleLong', methodParameterTypes = '']
    => org.graalvm.nativeimage.MissingReflectionRegistrationError: The program tried to reflectively access the proxy class inheriting [org.mockito.plugins.MockMaker] without it being registered for runtime reflection. Add [org.mockito.plugins.MockMaker] to the dynamic-proxy metadata to solve this problem. Note: The order of interfaces used to create proxies matters. See https://www.graalvm.org/latest/reference-manual/native-image/metadata/#dynamic-proxy for help.
       org.graalvm.nativeimage.builder/com.oracle.svm.core.reflect.MissingReflectionRegistrationUtils.forProxy(MissingReflectionRegistrationUtils.java:89)
       org.graalvm.nativeimage.builder/com.oracle.svm.core.reflect.proxy.DynamicProxySupport.getProxyClass(DynamicProxySupport.java:176)
       java.base@21.0.1/java.lang.reflect.Proxy.getProxyConstructor(Proxy.java:47)
       java.base@21.0.1/java.lang.reflect.Proxy.newProxyInstance(Proxy.java:1034)
       org.mockito.internal.configuration.plugins.PluginLoader.loadPlugin(PluginLoader.java:77)
       [...]
       Suppressed: java.lang.NullPointerException
         org.mockito.junit.jupiter.MockitoExtension.afterEach(MockitoExtension.java:190)
         [...]

I thought the metadata repository would take care of making Mockito work:

[INFO] Downloaded GraalVM reachability metadata repository from file:/home/steven/.m2/repository/org/graalvm/buildtools/graalvm-reachability-metadata/0.9.28/graalvm-reachability-metadata-0.9.28-repository.zip
[INFO] [graalvm reachability metadata repository for org.mockito:mockito-core:5.7.0]: Configuration directory not found. Trying latest version.
[INFO] [graalvm reachability metadata repository for org.mockito:mockito-core:5.7.0]: Configuration directory is org.mockito/mockito-core/4.8.1

Eng-Fouad · 2023-11-22T02:40:21Z

Now I am stuck on getting Mockito to work.

  JUnit Jupiter:TestArgumentsRegistry:testWaffleLong()
    MethodSource [className = 'org.jdbi.v3.core.argument.TestArgumentsRegistry', methodName = 'testWaffleLong', methodParameterTypes = '']
    => org.graalvm.nativeimage.MissingReflectionRegistrationError: The program tried to reflectively access the proxy class inheriting [org.mockito.plugins.MockMaker] without it being registered for runtime reflection. Add [org.mockito.plugins.MockMaker] to the dynamic-proxy metadata to solve this problem. Note: The order of interfaces used to create proxies matters. See https://www.graalvm.org/latest/reference-manual/native-image/metadata/#dynamic-proxy for help.
       org.graalvm.nativeimage.builder/com.oracle.svm.core.reflect.MissingReflectionRegistrationUtils.forProxy(MissingReflectionRegistrationUtils.java:89)
       org.graalvm.nativeimage.builder/com.oracle.svm.core.reflect.proxy.DynamicProxySupport.getProxyClass(DynamicProxySupport.java:176)
       java.base@21.0.1/java.lang.reflect.Proxy.getProxyConstructor(Proxy.java:47)
       java.base@21.0.1/java.lang.reflect.Proxy.newProxyInstance(Proxy.java:1034)
       org.mockito.internal.configuration.plugins.PluginLoader.loadPlugin(PluginLoader.java:77)
       [...]
       Suppressed: java.lang.NullPointerException
         org.mockito.junit.jupiter.MockitoExtension.afterEach(MockitoExtension.java:190)
         [...]

I thought the metadata repository would take care of making Mockito work:

[INFO] Downloaded GraalVM reachability metadata repository from file:/home/steven/.m2/repository/org/graalvm/buildtools/graalvm-reachability-metadata/0.9.28/graalvm-reachability-metadata-0.9.28-repository.zip
[INFO] [graalvm reachability metadata repository for org.mockito:mockito-core:5.7.0]: Configuration directory not found. Trying latest version.
[INFO] [graalvm reachability metadata repository for org.mockito:mockito-core:5.7.0]: Configuration directory is org.mockito/mockito-core/4.8.1

It looks Metadata for Mockito does not include proxy-config.json. Try to add it manually:

proxy-config.json:

[{"interfaces":["org.mockito.plugins.MockMaker"]}]

Then use either -H:DynamicProxyConfigurationFiles=proxy-config.json or -H:DynamicProxyConfigurationResources=proxy-config.json.

stevenschlansker · 2023-11-23T01:54:19Z

So, by enabling the agent experimental predefined classes, the proxy starts working.
However then I run into:

========================================================================================================================
GraalVM Native Image: Generating 'native-tests' (executable)...
========================================================================================================================
[1/8] Initializing...
                                                                                    (0.0s @ 0.14GB)
Error: More than one predefined class with the same name provided: org.mockito.codegen.Connection$MockitoMock$a3lier1op99200N

stevenschlansker · 2023-11-27T19:00:36Z

I filed: mockito/mockito#3183

stevenschlansker · 2024-01-10T19:19:38Z

Some minor progress here - by reducing Mockito usage to only interfaces, and disabling codegen and using Proxy mocks instead, the "more than one class" problem goes away and instead I get some test failures instead. Still more digging needed though.

stevenschlansker · 2024-01-11T22:38:24Z

We now removed all uses of the bytebuddy agent and Mockito only runs with pure JVM proxies in mainline. Rebased on top of that, running the build again...

stevenschlansker · 2024-01-11T22:39:47Z

Failures (3):
  JUnit Jupiter:ConstructorMapperTest:allColumnsOfNullableNestedObjectAbsent()
    MethodSource [className = 'org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest', methodName = 'allColumnsOfNullableNestedObjectAbsent', methodParameterTypes = '']
    => java.lang.IllegalArgumentException: Instance factory 'org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest$NullableNestedBean(java.lang.String,org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest$NullableParameterBean)' parameter '[nested]' has no matching columns in the result set. Verify that the Java compiler is configured to emit parameter names, that your result set has the columns expected, annotate the parameter names explicitly with @ColumnName, or annotate nullable parameters as @Nullable
       org.jdbi.v3.core.mapper.reflect.ConstructorMapper.createSpecializedRowMapper(ConstructorMapper.java:268)
       org.jdbi.v3.core.mapper.reflect.ConstructorMapper.specialize(ConstructorMapper.java:189)
       org.jdbi.v3.core.result.internal.ResultSetResultIterator.<init>(ResultSetResultIterator.java:54)
       org.jdbi.v3.core.result.internal.ResultSetResultIterable.iterator(ResultSetResultIterable.java:51)
       org.jdbi.v3.core.result.ResultIterable.one(ResultIterable.java:171)
       org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest.selectOne(ConstructorMapperTest.java:56)
       org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest.allColumnsOfNullableNestedObjectAbsent(ConstructorMapperTest.java:241)
       java.base@21.0.1/java.lang.reflect.Method.invoke(Method.java:580)
       java.base@21.0.1/java.util.ArrayList.forEach(ArrayList.java:1596)
       java.base@21.0.1/java.util.ArrayList.forEach(ArrayList.java:1596)
  JUnit Jupiter:ConstructorMapperTest:testNullableParameterAbsent()
    MethodSource [className = 'org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest', methodName = 'testNullableParameterAbsent', methodParameterTypes = '']
    => java.lang.IllegalArgumentException: Instance factory 'org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest$NullableParameterBean(java.lang.String,int)' parameter '[s]' has no matching columns in the result set. Verify that the Java compiler is configured to emit parameter names, that your result set has the columns expected, annotate the parameter names explicitly with @ColumnName, or annotate nullable parameters as @Nullable
       org.jdbi.v3.core.mapper.reflect.ConstructorMapper.createSpecializedRowMapper(ConstructorMapper.java:268)
       org.jdbi.v3.core.mapper.reflect.ConstructorMapper.specialize(ConstructorMapper.java:189)
       org.jdbi.v3.core.result.internal.ResultSetResultIterator.<init>(ResultSetResultIterator.java:54)
       org.jdbi.v3.core.result.internal.ResultSetResultIterable.iterator(ResultSetResultIterable.java:51)
       org.jdbi.v3.core.result.ResultIterable.one(ResultIterable.java:171)
       org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest.selectOne(ConstructorMapperTest.java:56)
       org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest.testNullableParameterAbsent(ConstructorMapperTest.java:121)
       java.base@21.0.1/java.lang.reflect.Method.invoke(Method.java:580)
       java.base@21.0.1/java.util.ArrayList.forEach(ArrayList.java:1596)
       java.base@21.0.1/java.util.ArrayList.forEach(ArrayList.java:1596)
  JUnit Jupiter:ConstructorMapperTest:nullableNestedNullableParameterAbsent()
    MethodSource [className = 'org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest', methodName = 'nullableNestedNullableParameterAbsent', methodParameterTypes = '']
    => java.lang.IllegalArgumentException: Instance factory 'org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest$NullableParameterBean(java.lang.String,int)' parameter '[s]' has no matching columns in the result set. Verify that the Java compiler is configured to emit parameter names, that your result set has the columns expected, annotate the parameter names explicitly with @ColumnName, or annotate nullable parameters as @Nullable
       org.jdbi.v3.core.mapper.reflect.ConstructorMapper.createSpecializedRowMapper(ConstructorMapper.java:268)
       org.jdbi.v3.core.mapper.reflect.ConstructorMapper.createSpecializedRowMapper(ConstructorMapper.java:247)
       org.jdbi.v3.core.mapper.reflect.ConstructorMapper.specialize(ConstructorMapper.java:189)
       org.jdbi.v3.core.result.internal.ResultSetResultIterator.<init>(ResultSetResultIterator.java:54)
       org.jdbi.v3.core.result.internal.ResultSetResultIterable.iterator(ResultSetResultIterable.java:51)
       org.jdbi.v3.core.result.ResultIterable.one(ResultIterable.java:171)
       org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest.selectOne(ConstructorMapperTest.java:56)
       org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest.nullableNestedNullableParameterAbsent(ConstructorMapperTest.java:232)
       java.base@21.0.1/java.lang.reflect.Method.invoke(Method.java:580)
       java.base@21.0.1/java.util.ArrayList.forEach(ArrayList.java:1596)
       [...]

I guess some reflection metadata is being lost, despite using the agent.

Eng-Fouad · 2024-01-11T23:27:46Z

Failures (3):
  JUnit Jupiter:ConstructorMapperTest:allColumnsOfNullableNestedObjectAbsent()
    MethodSource [className = 'org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest', methodName = 'allColumnsOfNullableNestedObjectAbsent', methodParameterTypes = '']
    => java.lang.IllegalArgumentException: Instance factory 'org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest$NullableNestedBean(java.lang.String,org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest$NullableParameterBean)' parameter '[nested]' has no matching columns in the result set. Verify that the Java compiler is configured to emit parameter names, that your result set has the columns expected, annotate the parameter names explicitly with @ColumnName, or annotate nullable parameters as @Nullable
       org.jdbi.v3.core.mapper.reflect.ConstructorMapper.createSpecializedRowMapper(ConstructorMapper.java:268)
       org.jdbi.v3.core.mapper.reflect.ConstructorMapper.specialize(ConstructorMapper.java:189)
       org.jdbi.v3.core.result.internal.ResultSetResultIterator.<init>(ResultSetResultIterator.java:54)
       org.jdbi.v3.core.result.internal.ResultSetResultIterable.iterator(ResultSetResultIterable.java:51)
       org.jdbi.v3.core.result.ResultIterable.one(ResultIterable.java:171)
       org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest.selectOne(ConstructorMapperTest.java:56)
       org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest.allColumnsOfNullableNestedObjectAbsent(ConstructorMapperTest.java:241)
       java.base@21.0.1/java.lang.reflect.Method.invoke(Method.java:580)
       java.base@21.0.1/java.util.ArrayList.forEach(ArrayList.java:1596)
       java.base@21.0.1/java.util.ArrayList.forEach(ArrayList.java:1596)
  JUnit Jupiter:ConstructorMapperTest:testNullableParameterAbsent()
    MethodSource [className = 'org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest', methodName = 'testNullableParameterAbsent', methodParameterTypes = '']
    => java.lang.IllegalArgumentException: Instance factory 'org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest$NullableParameterBean(java.lang.String,int)' parameter '[s]' has no matching columns in the result set. Verify that the Java compiler is configured to emit parameter names, that your result set has the columns expected, annotate the parameter names explicitly with @ColumnName, or annotate nullable parameters as @Nullable
       org.jdbi.v3.core.mapper.reflect.ConstructorMapper.createSpecializedRowMapper(ConstructorMapper.java:268)
       org.jdbi.v3.core.mapper.reflect.ConstructorMapper.specialize(ConstructorMapper.java:189)
       org.jdbi.v3.core.result.internal.ResultSetResultIterator.<init>(ResultSetResultIterator.java:54)
       org.jdbi.v3.core.result.internal.ResultSetResultIterable.iterator(ResultSetResultIterable.java:51)
       org.jdbi.v3.core.result.ResultIterable.one(ResultIterable.java:171)
       org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest.selectOne(ConstructorMapperTest.java:56)
       org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest.testNullableParameterAbsent(ConstructorMapperTest.java:121)
       java.base@21.0.1/java.lang.reflect.Method.invoke(Method.java:580)
       java.base@21.0.1/java.util.ArrayList.forEach(ArrayList.java:1596)
       java.base@21.0.1/java.util.ArrayList.forEach(ArrayList.java:1596)
  JUnit Jupiter:ConstructorMapperTest:nullableNestedNullableParameterAbsent()
    MethodSource [className = 'org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest', methodName = 'nullableNestedNullableParameterAbsent', methodParameterTypes = '']
    => java.lang.IllegalArgumentException: Instance factory 'org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest$NullableParameterBean(java.lang.String,int)' parameter '[s]' has no matching columns in the result set. Verify that the Java compiler is configured to emit parameter names, that your result set has the columns expected, annotate the parameter names explicitly with @ColumnName, or annotate nullable parameters as @Nullable
       org.jdbi.v3.core.mapper.reflect.ConstructorMapper.createSpecializedRowMapper(ConstructorMapper.java:268)
       org.jdbi.v3.core.mapper.reflect.ConstructorMapper.createSpecializedRowMapper(ConstructorMapper.java:247)
       org.jdbi.v3.core.mapper.reflect.ConstructorMapper.specialize(ConstructorMapper.java:189)
       org.jdbi.v3.core.result.internal.ResultSetResultIterator.<init>(ResultSetResultIterator.java:54)
       org.jdbi.v3.core.result.internal.ResultSetResultIterable.iterator(ResultSetResultIterable.java:51)
       org.jdbi.v3.core.result.ResultIterable.one(ResultIterable.java:171)
       org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest.selectOne(ConstructorMapperTest.java:56)
       org.jdbi.v3.core.mapper.reflect.ConstructorMapperTest.nullableNestedNullableParameterAbsent(ConstructorMapperTest.java:232)
       java.base@21.0.1/java.lang.reflect.Method.invoke(Method.java:580)
       java.base@21.0.1/java.util.ArrayList.forEach(ArrayList.java:1596)
       [...]

I guess some reflection metadata is being lost, despite using the agent.

According to GraalVM maven plugin docs:

Executing your application with the agent is more involved and requires you to configure a separate mojo execution which allows forking the Java process.

Also:

The agent generates the native configuration files in subdirectories of target/native/agent-output. Although those files will be automatically used if you run your build with the agent enabled, you should consider reviewing the generated files and adding them to your sources instead.

So the sole purpose of the agent is to help generating the native metadata configurations (i.e. refelct-config.json, proxy-config.json, etc.) which can then be included when compiling the app to native.

How about creating the native metadata configuration files manually? See this gist. In addition to the classes mentioned in the gist, we need to include all classes (in tests) that are being constructed/accessed by reflection. For example, the following beans need to be registered in reflect-config:

jdbi/core/src/test/java/org/jdbi/v3/core/mapper/reflect/ConstructorMapperTest.java

Lines 42 to 47 in 5a33a0f

    
           .registerRowMapper(ConstructorMapper.factory(ConstructorBean.class)) 
        
           .registerRowMapper(ConstructorMapper.factory(ConstructorPropertiesBean.class)) 
        
           .registerRowMapper(ConstructorMapper.factory(NamedParameterBean.class)) 
        
           .registerRowMapper(ConstructorMapper.factory(NullableNestedBean.class)) 
        
           .registerRowMapper(ConstructorMapper.factory(NullableParameterBean.class)) 
        
           .registerRowMapper(ConstructorMapper.factory(StaticFactoryMethodBean.class));

For reference, see how they maintain reflect-config.json files in Netty project: https://github.com/search?q=repo%3Anetty%2Fnetty%20reflect-config.json&type=code
For Spring project, it seems they build configuration files dynamically by code: https://github.com/spring-projects/spring-framework/blob/main/spring-core/src/main/java/org/springframework/aot/nativex/NativeConfigurationWriter.java#L80

stevenschlansker · 2024-01-12T17:57:08Z

How about creating the native metadata configuration files manually?

The main reason is that it is a pain in the ass to get right, for something that a human really "shouldn't" have to write, and there are many hundreds of test cases :)
Plus, then we have to manually maintain it going forward, for every test we write that uses SqlObject.
I was hoping the agent would at least get me a starting point that ran the test code. I'll try to manually write one at some point. Hopefully what the agent comes up with is at least close :)

stevenschlansker · 2024-01-12T18:22:04Z

Thanks for the reference to the Netty config - theirs is very short, so I can see how it's not too big of a deal to maintain. Ours is probably going to be much longer, because we have a ton of random types both in main and test that we access via reflection.

Eng-Fouad · 2024-01-13T03:16:55Z

Thanks for the reference to the Netty config - theirs is very short, so I can see how it's not too big of a deal to maintain. Ours is probably going to be much longer, because we have a ton of random types both in main and test that we access via reflection.

Probably it is better to create/maintain configs for main sources manually, and use the agent for test sources only.

stevenschlansker · 2024-01-24T23:00:38Z

Ok, I have a bit more information on the test failures. It looks like a constructor parameter for a test case @Nullable String s loses its annotation and looks like String s in native-image, which means Jdbi thinks it should be required. Not sure yet if this is something the agent missed, or if it is a deeper bug in constructor parameter annotation handling.

stevenschlansker · 2024-01-26T18:45:55Z

I looked through the reflect-config.json syntax and didn't see anything about including or excluding annotations. So, I guess the agent cannot generate config around this. Therefore this is a Graal bug?

stevenschlansker · 2024-01-26T19:07:17Z

Interesting, I extracted the code in question into a sample project to have a reproducer, and it works there ???

stevenschlansker · 2024-01-26T23:17:43Z

Ok, so I think the problem is somehow introduced from the jdbi parent pom. When I inherit from our Jdbi build pom, the test fails. When I inline the native-image configuration and depend on basepom, skipping jdbi build configuration, the test passes.

stevenschlansker · 2024-01-27T01:54:12Z

I think this is a native-image bug.
I filed graalvm/native-build-tools#562

sonarcloud · 2024-01-29T18:29:34Z

Quality Gate passed

The SonarCloud Quality Gate passed, but some issues were introduced.

1 New issue
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

stevenschlansker · 2024-01-29T18:32:17Z

Ok, I added a workaround to the issue I filed above, which we cannot merge, but should get us moving forward to the next problem for now at least.

And...

Error: Classes that should be initialized at run time got initialized during image building:
 org.junit.jupiter.api.condition.JRE was unintentionally initialized at build time. To see why org.junit.jupiter.api.condition.JRE got initialized use --trace-class-initialization=org.junit.jupiter.api.condition.JRE
To see how the classes got initialized, use --trace-class-initialization=org.junit.jupiter.api.condition.JRE

🤔 I'll have to come back to this later

Eng-Fouad · 2024-01-29T18:36:54Z

Ok, I added a workaround to the issue I filed above, which we cannot merge, but should get us moving forward to the next problem for now at least.

And...
Error: Classes that should be initialized at run time got initialized during image building:

 org.junit.jupiter.api.condition.JRE was unintentionally initialized at build time. To see why org.junit.jupiter.api.condition.JRE got initialized use --trace-class-initialization=org.junit.jupiter.api.condition.JRE

To see how the classes got initialized, use --trace-class-initialization=org.junit.jupiter.api.condition.JRE
🤔 I'll have to come back to this later

Is this relevant? the release notes of JUnit 5.10.0:

Building native images with GraalVM now requires configuring the build arg --initialize-at-build-time=org.junit.platform.launcher.core.LauncherConfig and --initialize-at-build-time=org.junit.jupiter.engine.config.InstantiatingConfigurationParameterConverter.

stevenschlansker · 2024-01-29T18:49:38Z

It could be! I don't get why core module would work OK but testing wouldn't, but I'll give that a try next time I have a moment to look at this.

hgschmie reviewed Aug 23, 2023

View reviewed changes

hgschmie approved these changes Aug 23, 2023

View reviewed changes

stevenschlansker force-pushed the graalvm-ci branch 3 times, most recently from 1e5fc6a to c326930 Compare August 24, 2023 02:31

stevenschlansker mentioned this pull request Aug 24, 2023

First class support of native compilation with GraalVM #2475

Open

hgschmie reviewed Aug 29, 2023

View reviewed changes

stevenschlansker force-pushed the graalvm-ci branch from c326930 to e12373b Compare November 21, 2023 23:45

stevenschlansker force-pushed the graalvm-ci branch from fd48951 to 8d00612 Compare November 22, 2023 00:11

stevenschlansker mentioned this pull request Nov 27, 2023

[native-image] More than one predefined class with the same name mockito/mockito#3183

Open

stevenschlansker force-pushed the graalvm-ci branch 2 times, most recently from b0c7281 to f21d795 Compare December 7, 2023 01:48

stevenschlansker force-pushed the graalvm-ci branch from f21d795 to cf97baf Compare December 20, 2023 00:55

stevenschlansker force-pushed the graalvm-ci branch from cf97baf to f08ad5f Compare January 10, 2024 19:13

stevenschlansker force-pushed the graalvm-ci branch from f08ad5f to 3851383 Compare January 11, 2024 22:35

stevenschlansker force-pushed the graalvm-ci branch 2 times, most recently from b70f674 to 6918e6a Compare January 24, 2024 21:54

stevenschlansker added 9 commits January 29, 2024 10:26

Run CI with GraalVM

04cbc43

Add native plugin and profile to build pom

63e2234

graalvm 21

0749675

native: enable metadata repository

1191002

native-agent: enable experimental predefined classes

e14e9ce

temporarily always enable agent

f91f790

TestPreparedBatchGenerateKeysPostgres: reduce dependency on current time

daf861e

XXX graalvm/native-build-tools#562

02c4799

Disable building native executable since Jdbi doesn't have a main

9ae2ff5

stevenschlansker force-pushed the graalvm-ci branch from 752aa7c to 9ae2ff5 Compare January 29, 2024 18:28

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Run CI with GraalVM #2476

Run CI with GraalVM #2476

stevenschlansker commented Aug 22, 2023

hgschmie Aug 23, 2023

stevenschlansker Aug 24, 2023

sonarcloud bot commented Aug 24, 2023

hgschmie Aug 29, 2023

hgschmie Sep 1, 2023

hgschmie Aug 29, 2023

hgschmie Aug 29, 2023 •

edited

hgschmie commented Sep 1, 2023

stevenschlansker commented Sep 1, 2023

Eng-Fouad commented Nov 20, 2023

stevenschlansker commented Nov 21, 2023

stevenschlansker commented Nov 21, 2023

stevenschlansker commented Nov 22, 2023

stevenschlansker commented Nov 22, 2023

Eng-Fouad commented Nov 22, 2023

stevenschlansker commented Nov 23, 2023

stevenschlansker commented Nov 27, 2023

stevenschlansker commented Jan 10, 2024

stevenschlansker commented Jan 11, 2024 •

edited

stevenschlansker commented Jan 11, 2024

Eng-Fouad commented Jan 11, 2024 •

edited

stevenschlansker commented Jan 12, 2024

stevenschlansker commented Jan 12, 2024

Eng-Fouad commented Jan 13, 2024

stevenschlansker commented Jan 24, 2024

stevenschlansker commented Jan 26, 2024

stevenschlansker commented Jan 26, 2024

stevenschlansker commented Jan 26, 2024

stevenschlansker commented Jan 27, 2024

sonarcloud bot commented Jan 29, 2024

stevenschlansker commented Jan 29, 2024

Eng-Fouad commented Jan 29, 2024

stevenschlansker commented Jan 29, 2024

Run CI with GraalVM #2476

Are you sure you want to change the base?

Run CI with GraalVM #2476

Conversation

stevenschlansker commented Aug 22, 2023

hgschmie Aug 23, 2023

Choose a reason for hiding this comment

stevenschlansker Aug 24, 2023

Choose a reason for hiding this comment

sonarcloud bot commented Aug 24, 2023

hgschmie Aug 29, 2023

Choose a reason for hiding this comment

hgschmie Sep 1, 2023

Choose a reason for hiding this comment

hgschmie Aug 29, 2023

Choose a reason for hiding this comment

hgschmie Aug 29, 2023 • edited

Choose a reason for hiding this comment

hgschmie commented Sep 1, 2023

stevenschlansker commented Sep 1, 2023

Eng-Fouad commented Nov 20, 2023

stevenschlansker commented Nov 21, 2023

stevenschlansker commented Nov 21, 2023

stevenschlansker commented Nov 22, 2023

stevenschlansker commented Nov 22, 2023

Eng-Fouad commented Nov 22, 2023

stevenschlansker commented Nov 23, 2023

stevenschlansker commented Nov 27, 2023

stevenschlansker commented Jan 10, 2024

stevenschlansker commented Jan 11, 2024 • edited

stevenschlansker commented Jan 11, 2024

Eng-Fouad commented Jan 11, 2024 • edited

stevenschlansker commented Jan 12, 2024

stevenschlansker commented Jan 12, 2024

Eng-Fouad commented Jan 13, 2024

stevenschlansker commented Jan 24, 2024

stevenschlansker commented Jan 26, 2024

stevenschlansker commented Jan 26, 2024

stevenschlansker commented Jan 26, 2024

stevenschlansker commented Jan 27, 2024

sonarcloud bot commented Jan 29, 2024

Quality Gate passed

stevenschlansker commented Jan 29, 2024

Eng-Fouad commented Jan 29, 2024

stevenschlansker commented Jan 29, 2024

hgschmie Aug 29, 2023 •

edited

stevenschlansker commented Jan 11, 2024 •

edited

Eng-Fouad commented Jan 11, 2024 •

edited