Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Usage of includes and excludes in custom resource-config.json fails native image build #4622

Closed
dmurat opened this issue Nov 27, 2020 · 4 comments
Milestone

Comments

@dmurat
Copy link

dmurat commented Nov 27, 2020

According to Graal documentation, the syntax of resource-config.json looks like the following:

{
  "bundles": [
    {"name":"your.pkg.Bundle"},
    {"name":"another.pkg.Resource"},
    {"name":"etc.Bundle"}
  ],
  "resources": {
    "includes": [
      {"pattern": "<Java regexp that matches resource(s) to be included in the image>"},
      {"pattern": "<another regexp>"},
      ...
    ],
    "excludes": [
      {"pattern": "<Java regexp that matches resource(s) to be excluded from the image>"},
      {"pattern": "<another regexp>"},
      ...
    ]
  } 
}

However, when using this syntax with Micronaut, the native image task fails with a compilation error. The workaround is to use the alternative syntax which allows only includes:

{
  "bundles": [
    {"name":"your.pkg.Bundle"},
    {"name":"another.pkg.Resource"},
    {"name":"etc.Bundle"}
  ],
  "resources": [
    {"pattern": "<Java regexp that matches resource(s) to be included in the image>"},
    {"pattern": "<another regexp>"},
    ...
  ],
}

I don't mind too much unavailability of the excludes clause, but I didn't found in Micronaut documentation anything about supported syntax.

Tnx

@graemerocher
Copy link
Contributor

This config files don't have much to do with Micronaut, you should report the issue to the GraalVM issue tracker

@dmurat
Copy link
Author

dmurat commented Dec 2, 2020

I don't think GraalVM is the problem, but I realized that my report was not clear.

The problem occurs when the user configures its own src/main/graal/resource-config.json which Micronaut's Gradle task tries to merge with the generated one. It is very likely that the user will follow GraalVM documentation related to the format of the file, and he will find that "resources" is not a list, but rather a map.

When parsing user-specified resource-config.json, Micronaut Gradle task uses io.micronaut.graal.reflect.GraalTypeElementVisitor class, and it fails the task at line 325, where it is assumed that "resources" is a List.

As a consequence, Micronaut Gradle nativeImage task fails, and in the output following error is displayed among other things:

error: There was an error generating resource-config.json: class java.util.LinkedHashMap cannot be cast to class java.util.List (java.util.LinkedHashMap and java.util.List are in module java.base of loader 'bootstrap')

GraalVM supports both formats (I checked by running GraalVM's native-image tool), so I guess, Micronaut should too.
If there is some problem with fixing a bug, I'll suggest including a supported format of resource-config.json in Micronaut documentation.

To reproduce, one can include the following content in src/main/graal/resource-config.json:

{
  "resources": {
    "includes": [
      { "pattern": "\\Qsome.properties\\E" }
    ],
    "excludes": []
  },
  "bundles": []
}

Tnx

@graemerocher
Copy link
Contributor

Ah I see, understood. In general I think we need to move away from static resource generation with io.micronaut.graal.reflect.GraalTypeElementVisitor so this is part of that

@graemerocher graemerocher added this to the 2.3.0 milestone Dec 2, 2020
@jameskleeh jameskleeh modified the milestones: 2.3.0, 2.4.0 Jan 21, 2021
@jameskleeh jameskleeh modified the milestones: 2.4.0, 2.5.0 Mar 9, 2021
@jameskleeh jameskleeh modified the milestones: 2.5.0, 3.0.0 Jun 9, 2021
@graemerocher
Copy link
Contributor

this functionality have been moved to the build plugins for 3.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants