Open szczebel opened 2 years ago
updates:
jpro.conf
, added to /resources, all OK.Thank you for the Bugreport!
JPro supports Java17, so that shouldn't be the issue. We don't properly support the gradle kotlin dsl - which is something we should focus on now. But because you got it running, it shouldn't be the problem.
It looks like a resource is missing for some reason.
Having a multi-module project as you've described should be fine, and is also our usual setup. Which Gradle version are you using? The same GradleVersion works fine with the HelloWorld project, right? Are you maybe using Scala in your project? JPro is internally using Scala, so maybe it confuses the dependency resolution of JPro.
If these questions don't give us a hint, I would have to ask you to minify your project until you find the trigger of the problem. What happens if you remove all dependencies of the JPro project?
Hey @FlorianKirmaier ,
I nailed down the issue, here's what happened:
webjars-locator-core-0.37.jar
, as can be seen in build\distributions\HelloJPro-jpro.zip\jprolibs after running jproRelease
webjars-locator-core
will be of version 0.48
webjars-locator-core
(neither directly nor transitively), but:0.48
and puts it in \jprolibs instead of 0.37
; jproRun
also uses this versiongetFullPathIndex()
method was removed or changed signature?), so JPro runtime cannot do its job and breaksWorkaround for my particular issue is quite simple, I just needed to add extra["webjars-locator-core.version"] = "0.37"
to my gradle.build.kts, as my app doesn't use webjars, so I don't have to care.
This is not a proper fix in general though - I guess you'll be seeing similar issues whenever an app will be using dependency management that will conflict with any of 138 jars that you have in \jprolibs - which is quite likely I suppose?
I'm guessing a proper fix would need to be done somewhere in jpro gradle plugin:
And JPro runtime should be using separate classloaders:
In case it's useful, reproducer repo (based on HelloJPro) is here, breaking change in this commit And the fix is on FIX branch, here
Hope this helps, Adam
Oh, thank you for working out the details! Yes, your first steps describe what must be done. The JPro Plugin should ignore the dependency defined with the BOM. I think it's limited to when a BOM is used.
The JProRuntime already does the classloader separation which you have suggested. A very early of JPro didn't have separated classloaders, and it was indeed a jar-hell. ;) The WebServer runs in its own Classloader, and the Application runs in the same Classloader, as it would do as a Desktop application.
Hey,
So here's what I'm seeing in the logs after visiting localhost:8080, same when running from jproRun or jproRelease -> start.bat
System information:
Any idea what's wrong? Maybe Java 17 is not supported yet - in such case what's the ETA?
Side questions:
jpro.conf
file? tried under root and frontend, to no avail.jpro{}
configuration is not recognized (.kts does not compile, 'Unresolved reference: jpro'). Any hints?Thanks, Adam