[help] Problems building module-based app #1265
Comments
|
Yes, it sounds like java.desktop is needed. Could you confirm? |
|
I checked the module definition here https://github.com/bytedeco/javacv/blob/master/src/main/java9/module-info.java, first, it seems like the only place where this definition exists (which makes me think that better modularity is a lot like appreciated), there's no |
|
I've updated the module-info.java file with that entry. |
|
Can confirm, 1.5.2-SNAPSHOT works, can build modules successfully: thanks! |
|
The classes work with Java SE 7, no need for JDK 11.
|
|
There's one more thing. mvn clean package dependency:copy-dependencies \
-DincludeScope=runtime \
-DskipTests=true \
-Dmdep.prependGroupId=true \
-DoutputDirectory=target \
--fail-never \
-Djavacpp.platform=macosx-x86_64so, my target folder tree looks like: the module-info of a module that uses javacv looks like: module api.facedetect.com {
// core
requires java.base;
requires java.desktop;
// 3rd-party
requires org.bytedeco.opencv.platform;
requires org.bytedeco.javacv.platform;
// local modules
requires api.gif.com;
exports api.facedetect.com;
}My dependency definition looks like: I can compile and build JARs for my own code with no problem, but when it goes to code execution it more feels like a hell on earth. Assuming that all necessary javacv/opencv plugins I'm attempting to run my code with the following command: java -p target/ --module main.app/main.app.Mainunfortunately, it doesn't work (once again I might be missing something). It keeps throwing tons of errors like: moreover, since I use platform flag to identify which JAR's I prefer to obtain, not all javacv dependent modules were resolved successfully because there's there are no Windows, Android, and iOS jars. So, eventually, I am not able to build to get my application up and running. Therefore I can't build a custom image with jlink because I still not able to figure out what is the minimum set of javacv (and whatever is under its hood) modules packaged as JARs I need to run my app and include them into a custom JRE build. Unfortunately, as for now, I had to fall back to the use of classpath: java -cp $(echo main.app/target/*.jar | tr ' ' ':') main.app.MainIf I'm missing something, please give me an advice. |
|
That's right, we can't modify modules at build time, unless we create
another module like an uber JAR, or we hack them with --patch-module
options. They were not designed with "optional" modules in mind.
@HGuillemet Any recommendations?
|
|
We can't modify modules, but when I want to build an app for the particular platform I eventually get modules dependencies for other platforms. There are few (or more) modules that depend on Windows, Linux, Android, and iOS at the same time. Maybe better decoupling could make things easier. Also, I bet there aren't many folks using java modules rather than maven modules, so, in order to showcase how to use javacv in a context of java modules, would be great to create a hello-world sample project that is based on java modules. |
|
To run your application when only the jar of a specific platform is available, do not use the platform jar, but directly the java jar a the native jar for your platform. In the module-info: In the pom: A sample project exists: https://github.com/bytedeco/sample-projects/tree/master/opencv-stitching-jlink |
|
@HGuillemet thanks for the reply. Well, your suggestion is very appreciated. But I fell like taking this path (a recommendation regarding platform-specific modules) is what would make my code un-testable (not just JUnit but an actual attempts to run an app on my laptop) on the non-target platform, so, I'd have to get docker involved (which is fine). wish there was a simpler and easier way to get things done faster, but still, that you so much for our help. |
repositories configured normally, the rest of packages of javacpp, opencv were resolved normally, except a jar of the |
|
It seems like the definition for |
|
He probably meant |
Okay, next showstopper: I run applications in docker or serverless where's basically, no desktop thing available, so javafx or (openjfx) is not available and doesn't seem like needed at all. What should I do with that? Or is there any path i can take to finally get jlink-ed version of my app? |
|
That comes with JavaFX, and it's already a dependency here: |
|
If javafx dependency is there, then why it's not picked up? Sorry, first time facing with javafx. |
|
Okay, here's what I think. I looked over my code and figured out that the only thing i use from javacv is: So, as I've noticed javacv is just an entrypoint to tons of libs (from javacpp presets) which is good, really, but it feels like it's kinda problematic to rely on the whole lib like javacv just for the sake of few interfaces and implementations which is just one I'd like to propose two things (both of those are alternatives to each other):
Any of the following approaches are fine for me and the whole benefit there would in the number of problems I've been facing with and the number of unnecessary dependencies that eventually will go away. Thoughts? |
|
Where would you put the interfaces? |
Let's say a library: |
|
No, I mean, for example, |
|
So, according to source code here's what you need: 5 files only (maybe some tests as well) Here's what i get when i (unfortunately) copied those 5 classes: boom, jlink worked. moreover, like you know, javacv brings 20+ jars along with it, but without it the number of actual dependencies went down to 4 jars (openblas, javacpp, opencv, opencv-macosx) Isn't that great? oh, yeah, javafx problem disappeared. |
Honestly, based on its imports - javacpp, idiomatically - |
|
If you're only interested in jlink, I would just create an uber JAR and call it day. IMO, there's nothing else useful about JPMS anyway.
So, you want OpenCV to depend on JavaCV and everything that it imports? You're not making any sense. |
Um, no. |
Ok, I'll assume you're talking about modules here and not packages. There's obviously a way to separate everything into many more very small modules to work around the limitations of JPMS, but I don't feel it's worth the added complexity or the loss in backward compatibility, since we can already work around the limitations of JPMS in the case of jlink via uber JARs. If you can come up with a simpler solution though, that would be great. |
|
I do understand your concerns, really,
Actually, talking about packages, sorry. I had to admit that your words make a lot of sense, but here I am with my own problems and I really want to build things with javacv (as i've used to with GoCV and Py opencv). So, the blocker, for now, is a huge problem of jlink-ing modules altogether, because of the obvious dependencies problem like javafx that for some reason doesn't link and so on. So, ideally, I'd like to see a separate maven-consumable jar (package, lib, module - call it as you like) with 5 classes that can be called - |
|
Since the only thing you're interested in is jlink, I would just use an
uber JAR. Or could you explain why this doesn't work for you? BTW, if you
must vent your frustration somewhere, please redirect it to OpenJDK. :)
|
|
I noticed the poster's error says Edit: Confirmed that one entry ...
exports org.bytedeco.tesseract.global;
exports org.bytedeco.tesseract;1.5.1 onwards: ...
exports org.bytedeco.tesseract.global;
exports org.bytedeco.teeseract.presets;
exports org.bytedeco.tesseract;Edit 2: Just noticed this seems to be fixed on commit: bytedeco/javacpp-presets@8c5ca2b probably, likely nvm, but |
First, my use cases are driven by serverless development, I have pretty strict constraints on the size of the final runtime image where JDK + uber jar doesn't fit. So, I refactored my code into a set of modules that would eventually make it to jlink-ed runtime.
In serverless, we pay for the size and for the execution time (that includes the time for obtaining a docker image with an application's code). So, that's why I want to get better granularity from the dependencies I have, as I stated before, my code depends on javacv (and all of its dependencies) only because of 1 class (subsequently, pluf 4 more classes) that doesn't really have to be part of javacv because it does all the work for opencv Frame/BufferedImage/Mat conversion, meaning that it might become a separate distribution unit that I can consume through maven without involving javacv and all of its dependencies. |
|
We can still use jlink with an uber JAR, get the same end result, with the exact same size. I still don't understand the problem. It just sounds like you want to transfer to me your work. You'll need to make a better case. :) |
I'm really sorry to say this but that's not true, tested, when I bring back javacv as a dependency I end up having tons of platform-specific jars that I would never use in my application.
No, I really don't. What I don't understand is for what reason in any programming language and a library I need to pull tons of redundant things just because of few classes. At this moment, the code coupling is just unacceptable. In almost all cases, it would be better to make a project more granular because that makes things more flexible and less problematic. You have all libs being separate while JavaCV is a glue-code that makes things friendlier. |
|
I guess Samuel suggests to use some kind of minimization of the uber-jar (using option minimizeJar from maven shade plugin, or proguard , or maybe other tools). The Uber jar needs then to be modularized (with moditect or whatever). Maybe there |
|
@denismakogon Tell you what: Fork JavaCV, maintain it however you want, maybe others will start using it, and if in a year or two you're still there, then we can discuss merging your changes and you can start maintaining them here. Until then, I have better things to do than to add unnecessary complexity. |
|
@HGuillemet We don't even need to modularize the uber JAR, here's an example of that: |
|
@saudet graalvm is a separate thing, the idea and a task to use native java tools and jlink for shrinking the size of the runtime.
Thank you for such a detailed answer, however, I'd rather not. If you don't see any value and not willing to play fair OSS where you have a user that asks for better modularity and you answer "i don't want to do your work". Thank you for your time. |
Now you're starting to get it. That's what open source is all about! You're the only user that has ever asked for this. I do not want to spend my free time working on something that will be useful to only a single person (that is not me). What is so hard to understand about this? If more users come along and ask for it (here for example, so let's keep this issue open), then it makes sense for me to spend time on this. Until then, if you really really really want it, then you do it, or hire someone to do it for you. There is nothing that prevents you! |
|
Actually, let's just consider this as a duplicate of #1071. |
|
BTW, I do understand the value of splitting everything in modules, but there are also drawbacks. Ever since I've created the "-platform" artifacts, you have no idea how many users are unable to use "javacv-platform" instead of "javacv". And this is just one extra module. Imagine if we have ten of those! Who is going to support them users? I don't personally want to spend all my free time telling people which modules they should be using! If someone else other than me wants to do that job, that's a different question though, but you don't seem like that kind of person @denismakogon. |
|
@denismakogon Hey, it looks like you were working on this for a blog post? |
|
@saudet Yeah. Both me and Chad were working on that. |
Hi, I'm kinda unsure where to go.
I have an application that I can safely build and run, see https://github.com/denismakogon/gif-tracker/tree/master.
However, when I switched to modules, I'm facing the compilation problem.
But before that, there are 3 modules, 2 of those have a dependency on
java.awt.image.BufferedImageclass, one package compiles normally, but the second one that has javacv dependency is not building at all with the following problem:this is where it fails:
my module info looks like:
could that be possible that
java.desktopmodule wasn't included somewhere in a lib?Module-based application you may find here: https://github.com/denismakogon/gif-tracker/tree/java-modules
Any recommendation appreciated.
The text was updated successfully, but these errors were encountered: