Description
It seems to come up somewhat often that application developers want to include the contents of src/main/resources into their native image.
Currently we don't provide an easy way of doing that, other making the user add additionalBuildArgs.
This has been discussed before in #388, but I believe that this need is not limited to extension authors only (see for example this discussion, or envision a scenario were a use developing a Kafka application wants to read from Twitter and includes twitter4j.properties).
Implementation ideas
My idea would be to follow the everything configured via application.properties paradigm. We could provide some properties that the user could set which would then be easily processed by by a processor to generate the necessary SubstrateResourceBuildItem.
@geoand Could you give an example on how to add a resource using additionalBuildArgs. Based on #388 and the substratevm documentation, I haven't been able to figure it out.
I'm using Quarkus 0.18.0 with GraalVM ce-1.0.0-rc16.
I added a file called version.txt to the src/main/resources folder (same folder as application.properties). In my code I access this file using File file = new File(getClass().getClassLoader().getResource("version.txt").getFile());. This works as expected. But as soon as I build a native image a NullPointerException is thrown.
My build plugins configuration looks like this:
<plugin>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-maven-plugin</artifactId>
<version>${quarkus.version}</version>
<executions>
<execution>
<goals>
<goal>native-image</goal>
</goals>
<configuration>
<enableHttpUrlHandler>true</enableHttpUrlHandler>
<additionalBuildArgs>-H:Log=registerResource:</additionalBuildArgs>
<additionalBuildArgs>-H:IncludeResources=.*/version.*txt$</additionalBuildArgs>
</configuration>
</execution>
</executions>
</plugin>
(I also tried .*/version.txt$ for the regex.)
Can you spot what I am doing wrong? Do you have a complete example I can have a look at?
Hello @ChristianHuff-DEV,
I would advise you to take a look at my comment here.
Simply adding <additionalBuildArgs>-H:IncludeResources=version.txt</additionalBuildArgs> (where version.txt should be located in src/main/resources) should be enough to get it loadable using getClass().getResourceAsStream("/version.txt") (an example of which you can see here).
Also keep in mind that for Quarkus 0.18.0 you need GraalVM 19.0.2
Thank you @geoand,
adjusting the regex and loading method fixed the issue!
Glad to hear it!
The principle of least surprise says that all of src/main/resources/ should be included in the native image by default. If you did not want to use a resource, why did you create it to begin with? Developers should not have to go down a Google/stackoverflow.com rabbit hole to find a hard-to-remember POM addition just so that what works out of the box in JVM mode also works in native mode.
Quarkus: 0.21.1
Graal: 19.2.0
Using smallrye-jwt extension.
I found that resources inside src/main/resources/META-INF/resources are added by default to the native image (no pom config required). However, placing them in the src/main/resources and using
<additionalBuildArgs>-H:IncludeResources='.*/*.p8$'</additionalBuildArgs>
does not.
I noticed this message [INFO] [io.quarkus.smallrye.jwt.deployment.SmallRyeJwtProcessor] Adding META-INF/resources/jwt-public.pem to native image but no additional arguments are added to the compilation command. So I assume that quarkus does something under the hood to modify with included resources.
Also, if I use the same build arguments directly in a small app and compile it directly, it does work.
Now, I will place my files in META-INF/resources but I am curious to know if this is some side effect or is expected.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you!
We are doing this automatically to ensure out-of-date issues does not stay around indefinitely.
If you believe this issue is still relevant please put a comment on it on why and if it truly needs to stay request or add 'pinned' label.
In Camel Quarkus, we let the user choose resources to be embedded in the native executable via configuration. We basically specify include/exclude patterns in application.properties, and embed matching resources in the native executable at build time.
I could have a try contributing this feature to quarkus if it makes sense ? Or perhaps contribute only include-patterns to avoid confusion with other extensions embedding native resources ?
This is actually already part of a discussion on the quarkus mailing list so hiding this note to avoid confusion.
Most helpful comment
The principle of least surprise says that all of
src/main/resources/should be included in the native image by default. If you did not want to use a resource, why did you create it to begin with? Developers should not have to go down a Google/stackoverflow.com rabbit hole to find a hard-to-remember POM addition just so that what works out of the box in JVM mode also works in native mode.