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

Allow configuring additional entries for native image classpath #129

Closed
dmurat opened this issue Aug 27, 2021 · 0 comments · Fixed by #138
Closed

Allow configuring additional entries for native image classpath #129

dmurat opened this issue Aug 27, 2021 · 0 comments · Fixed by #138
Labels
enhancement New feature or request gradle-plugin Related to Gradle plugin

Comments

@dmurat
Copy link

dmurat commented Aug 27, 2021

I'm not using this plugin at the moment. However, I was kindly asked by Cedric Champeau to replicate this issue here.

The original report was for the Micronaut Gradle plugin and can be found here: micronaut-projects/micronaut-gradle-plugin#93. For convenience, here is a quote:

It would be great to have the ability to configure additional entries for the native-image --class-path option.

For some reasons I ended up writing [programmatic registration] (https://www.graalvm.org/reference-manual/native-image/Reflection/) for Graal runtime reflection via org.graalvm.nativeimage.hosted.Feature interface, where implementation needs to use external dependency.

In this situation, I will like to have the ability to configure that dependency as compileOnly, but still be able to provide it as part of the classpath for the native-image tool. I guess something like an additional Gradle configuration like graalNativeImageDependencies would solve the problem if the plugin takes it into account during the generation of the native-image classpath.

The current workaround is to use the implementation configuration for that external dependency, which is not ideal, I think.

Tnx

@lazar-mitrovic lazar-mitrovic added enhancement New feature or request gradle-plugin Related to Gradle plugin labels Aug 28, 2021
melix added a commit that referenced this issue Sep 28, 2021
Previously to this commit, the classpath used by native image was
hardcoded to include the project artifact and its runtime classpath.
With this change, the plugin now introduces a couple of configurations:

- `nativeImageCompileOnly` which _can_ be used to declare dependencies
(or artifacts) which are required at image build time, but not by the
main application (JVM mode)
- `nativeImageClasspath`, which extends from the same configurations
as the `runtimeClasspath` configuration, but also from the new
`nativeImageCompileOnly` configuration. This is the configuration which
is now used to configure the plugin classpath.

This will allow other plugins to contribute more artifacts or dependencies
at image build time without having to tweak manually the image classpath,
which could before imply loosing some user configuration code.

This also makes it cleaner to contribute GraalVM native image features,
without leaking into the main application runtime classpath.

Eventually, the same mirror configurations are defines for the test
image building.

Closes #129
melix added a commit that referenced this issue Sep 28, 2021
Previously to this commit, the classpath used by native image was
hardcoded to include the project artifact and its runtime classpath.
With this change, the plugin now introduces a couple of configurations:

- `nativeImageCompileOnly` which _can_ be used to declare dependencies
(or artifacts) which are required at image build time, but not by the
main application (JVM mode)
- `nativeImageClasspath`, which extends from the same configurations
as the `runtimeClasspath` configuration, but also from the new
`nativeImageCompileOnly` configuration. This is the configuration which
is now used to configure the plugin classpath.

This will allow other plugins to contribute more artifacts or dependencies
at image build time without having to tweak manually the image classpath,
which could before imply loosing some user configuration code.

This also makes it cleaner to contribute GraalVM native image features,
without leaking into the main application runtime classpath.

Eventually, the same mirror configurations are defines for the test
image building.

Closes #129
melix added a commit that referenced this issue Sep 28, 2021
Previously to this commit, the classpath used by native image was
hardcoded to include the project artifact and its runtime classpath.
With this change, the plugin now introduces a couple of configurations:

- `nativeImageCompileOnly` which _can_ be used to declare dependencies
(or artifacts) which are required at image build time, but not by the
main application (JVM mode)
- `nativeImageClasspath`, which extends from the same configurations
as the `runtimeClasspath` configuration, but also from the new
`nativeImageCompileOnly` configuration. This is the configuration which
is now used to configure the plugin classpath.

This will allow other plugins to contribute more artifacts or dependencies
at image build time without having to tweak manually the image classpath,
which could before imply loosing some user configuration code.

This also makes it cleaner to contribute GraalVM native image features,
without leaking into the main application runtime classpath.

Eventually, the same mirror configurations are defines for the test
image building.

Closes #129
melix added a commit that referenced this issue Sep 28, 2021
Previously to this commit, the classpath used by native image was
hardcoded to include the project artifact and its runtime classpath.
With this change, the plugin now introduces a couple of configurations:

- `nativeImageCompileOnly` which _can_ be used to declare dependencies
(or artifacts) which are required at image build time, but not by the
main application (JVM mode)
- `nativeImageClasspath`, which extends from the same configurations
as the `runtimeClasspath` configuration, but also from the new
`nativeImageCompileOnly` configuration. This is the configuration which
is now used to configure the plugin classpath.

This will allow other plugins to contribute more artifacts or dependencies
at image build time without having to tweak manually the image classpath,
which could before imply loosing some user configuration code.

This also makes it cleaner to contribute GraalVM native image features,
without leaking into the main application runtime classpath.

Eventually, the same mirror configurations are defines for the test
image building.

Closes #129
melix added a commit that referenced this issue Sep 29, 2021
Previously to this commit, the classpath used by native image was
hardcoded to include the project artifact and its runtime classpath.
With this change, the plugin now introduces a couple of configurations:

- `nativeImageCompileOnly` which _can_ be used to declare dependencies
(or artifacts) which are required at image build time, but not by the
main application (JVM mode)
- `nativeImageClasspath`, which extends from the same configurations
as the `runtimeClasspath` configuration, but also from the new
`nativeImageCompileOnly` configuration. This is the configuration which
is now used to configure the plugin classpath.

This will allow other plugins to contribute more artifacts or dependencies
at image build time without having to tweak manually the image classpath,
which could before imply loosing some user configuration code.

This also makes it cleaner to contribute GraalVM native image features,
without leaking into the main application runtime classpath.

Eventually, the same mirror configurations are defines for the test
image building.

Closes #129
melix added a commit that referenced this issue Sep 29, 2021
Previously to this commit, the classpath used by native image was
hardcoded to include the project artifact and its runtime classpath.
With this change, the plugin now introduces a couple of configurations:

- `nativeImageCompileOnly` which _can_ be used to declare dependencies
(or artifacts) which are required at image build time, but not by the
main application (JVM mode)
- `nativeImageClasspath`, which extends from the same configurations
as the `runtimeClasspath` configuration, but also from the new
`nativeImageCompileOnly` configuration. This is the configuration which
is now used to configure the plugin classpath.

This will allow other plugins to contribute more artifacts or dependencies
at image build time without having to tweak manually the image classpath,
which could before imply loosing some user configuration code.

This also makes it cleaner to contribute GraalVM native image features,
without leaking into the main application runtime classpath.

Eventually, the same mirror configurations are defines for the test
image building.

Closes #129
melix added a commit that referenced this issue Sep 29, 2021
Previously to this commit, the classpath used by native image was
hardcoded to include the project artifact and its runtime classpath.
With this change, the plugin now introduces a couple of configurations:

- `nativeImageCompileOnly` which _can_ be used to declare dependencies
(or artifacts) which are required at image build time, but not by the
main application (JVM mode)
- `nativeImageClasspath`, which extends from the same configurations
as the `runtimeClasspath` configuration, but also from the new
`nativeImageCompileOnly` configuration. This is the configuration which
is now used to configure the plugin classpath.

This will allow other plugins to contribute more artifacts or dependencies
at image build time without having to tweak manually the image classpath,
which could before imply loosing some user configuration code.

This also makes it cleaner to contribute GraalVM native image features,
without leaking into the main application runtime classpath.

Eventually, the same mirror configurations are defines for the test
image building.

Closes #129
melix added a commit that referenced this issue Sep 29, 2021
Previously to this commit, the classpath used by native image was
hardcoded to include the project artifact and its runtime classpath.
With this change, the plugin now introduces a couple of configurations:

- `nativeImageCompileOnly` which _can_ be used to declare dependencies
(or artifacts) which are required at image build time, but not by the
main application (JVM mode)
- `nativeImageClasspath`, which extends from the same configurations
as the `runtimeClasspath` configuration, but also from the new
`nativeImageCompileOnly` configuration. This is the configuration which
is now used to configure the plugin classpath.

This will allow other plugins to contribute more artifacts or dependencies
at image build time without having to tweak manually the image classpath,
which could before imply loosing some user configuration code.

This also makes it cleaner to contribute GraalVM native image features,
without leaking into the main application runtime classpath.

Eventually, the same mirror configurations are defines for the test
image building.

Closes #129
melix added a commit that referenced this issue Sep 29, 2021
Previously to this commit, the classpath used by native image was
hardcoded to include the project artifact and its runtime classpath.
With this change, the plugin now introduces a couple of configurations:

- `nativeImageCompileOnly` which _can_ be used to declare dependencies
(or artifacts) which are required at image build time, but not by the
main application (JVM mode)
- `nativeImageClasspath`, which extends from the same configurations
as the `runtimeClasspath` configuration, but also from the new
`nativeImageCompileOnly` configuration. This is the configuration which
is now used to configure the plugin classpath.

This will allow other plugins to contribute more artifacts or dependencies
at image build time without having to tweak manually the image classpath,
which could before imply loosing some user configuration code.

This also makes it cleaner to contribute GraalVM native image features,
without leaking into the main application runtime classpath.

Eventually, the same mirror configurations are defines for the test
image building.

Closes #129
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request gradle-plugin Related to Gradle plugin
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants