I am using a third-party library in my quarkus project. This third-party library has a transitive dependency which includes some inner resources.
These resources are loaded at runtime, and seem to work when executing my quarkus project in dev mode, however, when running the built native image, these resources are not found.
Is there a way to include this transitive dependency resources in the built native image? I tried to specifically include the library in my gradle dependency but that did not work.
Thanks.
By default, the resources are not included in the native image.
You need to include them yourself.
See our extensive documentation about the various issues you can have with GraalVM native executable and how to solve them here: https://quarkus.io/guides/writing-native-applications-tips#including-resources (the link points to your specific issue but better read the whole doc for a global understanding).
Related
I've got this dependency in my pom.xml
<dependency>
<groupId>com.itextpdf</groupId>
<artifactId>itext7-core</artifactId>
<version>7.1.18</version>
<type>pom</type>
</dependency>
And in my module-info.java file I have the following
requires transitive kernel;
which produces the following warning, "Name of automatic module 'kernel' is unstable, it is derived from the module's file name."
What can I do to get rid of this warning?
I tried changing it to
requires transitive com.itextpdf.kernel;
but then I get the following error, "com.itextpdf.kernel cannot be resolved to a module"
I tried a bunch of other similar lines of code but nothing worked. What can I change the code to in order to remove the error/warning?
itext7 currently isn't modular.
You can contact the developers and ask them to make it modular.
In the meantime, complex, non-modular systems like this are difficult to use from a modular project. Even if you get that to work via the automatic module system or hacking in module info via something like moditect, it pretty much destroys any potential benefit of the project being modular, and it runs the software in a way it was never designed to work.
So, make your project non-modular:
remove the module-info.java from your project.
source the javafx modules using either:
VM arguments pointing adding them to the module path OR
from a JRE/JDK distribution that includes them, e.g. BellSoft Liberica "Full JDK" or Azul Zulu "JDK FX".
For further instructions on working with non-modular JavaFX projects, see the getting started documentation at: openjfx.io.
I am not sure what "not modular" means but how can that be true if the itext7 website gives maven dependencies to incorporate into your pom.xml?
Non-modular means that you don't define a module-info.java in your project.
Read understanding modules and the documentation I linked at openjfx.io to understand the basics of the JavaFX module system and how it can be used in a JavaFX application.
Maven modules and Java Platform modules are different things, they have the same name "module" but one is a build-time definition and the other is a runtime definition. Also, a maven dependency is just a dependency, it is not a Maven module or a Java Platform module. Though you can depend on artifacts built by a maven module and you can execute those artifacts through the Java Platform module system (if they are compatible with it).
itext7 is not built as a Java Platform module. The software has no module-info.java and it does not define an automatic module name for itself either. Given that your software is depending on non-modular software, your software should not be modular either (in my opinion).
I am new to the Quarkus, Is it possible to pick up any library from the Maven repository and use into Quarkus app.
or i can only use these Code.
Is there any impact on performance?
If you plan on building a Java app deployed on the JVM, you should be able to use any library.
Things are a bit different if you plan to build a native executable. In this case, a library might need some additional metadata for GraalVM. That's one of the things we do in our Quarkus extensions.
we are getting really frustrated both financially and also in our project level. The root problem is that we have build an android library project, which uses another aar as a dependency. The clients which integrate our library have to manually include the aar and it does not work in all cases..
I can't understand why does https://bintray.com/ does not allow to publish library with added aar file inside of it? We have tried to create a same maven and even publish additional library, but client still need to include both libraries and not a single one..
Android team endorses multi module approach, so why there are no tools to easily integrate library, which has another library as a dependency?
Maybe someone had solved this issue or knows how to do what I have done?
I'm currently experimenting with golang's plugin system. A problem which I experienced in my testings is that the file size of the plugins is relativly big.
The application loading the plugin will be referenced as "host".
The host application itself is ~50MiB big since it is a web application and should be extended with plugin functionality.
I've implemented a small plugin loader to start the plugins up.
The plugins may use the already existing APIs in the application for example to access the database.
I've prepared a example plugin for this question. The plugin .so file size is ~39MiB. This gives me the reasonable suspicion that the plugin also contains source code from the host application.
Command used to create main.so:
go build -ldflags="-s -w" --buildmode=plugin main.go
Is it possible to "remove" the duplicated source code from the application to reduce file size since it is already loaded on runtime when the plugin gets loaded?
Plugin loader: https://github.com/jonasfranz/gitea/blob/feature/plugin/modules/plugins/loader.go
Example plugin: https://git.jonasfranz.software/JonasFranzDEV/giteaplugin
Source code is not included in plugins. But what is included in them is their dependencies, recursively. This is so because there is no guarantee that the main app that loads the plugin also contains the dependencies, so to ensure the viability of the plugin, its dependencies must be self-contained.
This does not cause problems if the main app also include the same dependencies (with the same version), they will only be "instantiated" once in the go runtime, for details, see How do Go plugin dependencies work?
What to do in order to reduce plugins' sizes? Besides removing the debug information (what you did), you should minimize the dependencies.
This may require redesign and major changes both in the plugin or in the app you wish to create the plugin for. For example, plugins should not refer to "implementation" packages, plugins should only refer to "interface" packages. If interfaces and implementations are not separated, this may not be possible (hence may it be required to change the main app too).
You may also try utilities that try to compress binaries, for details see: Shrink your Go binaries with this one weird trick
I'd like to create my own gradle library, that can be compiled into other projects using gradle compile statement.
Example from Picasso's README:
Download the latest JAR or grab via Gradle:
compile 'com.squareup.picasso:picasso:2.5.2'
I'm developing few applications that share common source: fragments, views, some logic... Sometimes I extend these sources while I'm developing app A, sometimes while I'm developing app B,... And I feel that copy-paste of packages/classes in Android Library Module is not an proper solution.
So I would like to setup my own library, that:
it could be easily deployed to as gradle library that could be used by compile.
I can easily develop/extend it together with currently developed application
Disclaimer: I had been googling it a lot, but without luck.
If you want to reuse a library across completely separate projects then you'll want to publish your library to repository. Assuming this is open source and you don't mind sharing, you could use JCenter, which is already added as a repository to Android projects by default.
https://www.virag.si/2015/01/publishing-gradle-android-library-to-jcenter/