I am trying out a sample GRPC project and am using Java 8 with gradle 7. I seem to have the right dependencies and configs for proto generation to generate Java sources. However, the task step for generateProto simply succeeeds and I see this:
generateProto NO-SOURCE
My project skeleton is here and pretty straightforward https://github.com/sellmart/cfs. Appreciate any input on why the sources aren't being generated
The proto plugin did not find any proto source files.
Your proto is in the src/proto directory. The proto folder structure mirrors that of the java folder structure; you should use folders like src/main/proto and src/test/proto.
Related
I know you can solve this by adding
--module-path "pathToLib" --add-modules javafx.controls,javafx.fxml,javafx.graphics when running the jar file in command line.
But my question is, Is there no permanent solution to solve this error in system settings or configurations and be able to run a jar file as normal as java -jar myfile.jar rather than every time I am suppose to add the module java --module-path "C:\Users\..\Downloads\javafx-sdk-17.0.2\lib" --add-modules javafx.controls,javafx.fxml,javafx.graphics -jar myfile.jar
Also I know you can make a script for this operation for every jar file, but I was thinking of something like system settings or configuration that will be applicable for all jar file with javafx, and be able to run the jar file as normal as java -jar myFile.jar
I am using Ant as a build tool.
Recommended Alternatives
See the packaging resources of the JavaFX tag for recommended alternate solutions to a jar distribution: jlink, jpackage, or native image.
Using JRE's that include JavaFX
Pre-installed JREs that include JavaFX, such as some Bellsoft, Zulu, and Corretto distributions, will execute JavaFX apps without additional module specifiers because they include the JavaFX modules in the base module setup for their distributions.
Note, you must use the correct versions of the JDKs if you want a JDK which includes JavaFX (not all JDKs include JavaFX):
for BellSoft, download and install the "Full JDK", not the "Standard JDK".
for Zulu, download and install the package type "JDK FX", not "JDK".
You can also create your own JRE distribution that includes JavaFX modules using jlink (which is actually simpler to do than it may sound).
Using ant to build a single JAR containing App and JavaFX components
But I still hope that there might be a solution for the above while working with ANT as building tool for JavaFX.
There is some info on building modular JavaFX apps with ant in this answer:
bad name in value for --add-modules when trying to compile through ant
It probably isn’t everything you are looking for though.
To create a single executable jar using ant, you could try emulating the output of this maven JavaFX shade on classpath answer:
Maven Shade JavaFX runtime components are missing
But use ant tasks to build the massive shaded jar instead of maven. I don’t have explicit instructions for that, you would need to work out to accomplish that non-trivial task yourself.
The created jar will include a launcher class, your application code, dependent library code, JavaFX java, and native code. The jar will run on any modern JRE as long as you have included the native code for the relevant platform. The jar will run in the unsupported classpath configuration.
Zip Distributions
Or (better) create a zip distribution:
only put your own code in your app jar.
place the dependent libraries and JavaFX modules in a lib directory.
Create a script that invokes Java with your jar file running with the modules in the lib directory added.
Make your app modular if possible:
Define a module-info.java.
This step isn’t strictly necessary or reasonably possible for some apps.
Use ant to place everything in a zip file for distribution.
Include a jlink generated JRE in the zip if you want.
Note: the maven JavaFX plugin, once properly configured, can accomplish most of these tasks with a single command:
mvn javafx:jlink
Additional info
See the eden guide for resolving JavaFX runtime components.
Add a module-info.java file under your java/ folder and populate it with the following content:
module module_name {
requires javafx.controls;
requires javafx.fxml;
requires javafx.graphics;
requires java.base;
requires java.desktop;
opens com.example.matformater to javafx.graphics;
opens com.example.matformater.controller to javafx.fxml;}
I have some Clojurescript source files that output messages to the browser console on a timer. Eventually I would like to make a Clojars library from these files. So far I have created an uberjar using lein. All the user of this library would need to do is :require a namespace from the library, and messages should be emitted to the browser console. Seeing these messages is the "all working fine" test I want to perform.
In other words how do I check that the jar file I have created works? Can I start off with a fresh lein project and just put the jar file in some special 'un-managed' directory and :require the namespace? Actually I don't think you can do such a thing with lein, hence the question.
Assuming you have a project.clj file already with the line
(defproject bigco/biglib "0.1.0-SNAPSHOT”
...
run
lein install
This will build the JAR and install it in your local Maven repo.
Then in your new project, add that dependency and run it.
If your jar (definition of jar includes uberjar of course) does not come neatly from a lein project then an alternative is to use Maven 2 directly:
mvn install:install-file -Dfile=./my-deps.jar -DgroupId=my-deps -DartifactId=my-deps -Dversion=1.0.0 -Dpackaging=jar
Here mvn will store the jar in your local .m2 maven repository. Once stored you can use this jar in any lein project on your machine by referring to it in the dependencies section:
[my-deps "1.0.0"]
Maven documentation for this.
In one of my programs I use QWebView to load and print reports made from HTML documents. So while deployment I copy these libraries, in additional to all other relevant Qt libraries:
Qt5WebKit.dll
Qt5WebKitWidgets.dll
Qt5PrintSupport.dll
plugins/printsupport/windowsprintersupport.dll
After testing on destination machine I've found that printing doesn't work. Thanks for Dependency Walker I've get all the missed libraries. Here is the list:
Qt5Multimedia.dll
Qt5Positioning.dll
Qt5MultimediaWidgets.dll
Qt5Qml.dll
Qt5Quick.dll
Qt5Sensors.dll
Qt5OpenGL.dll
Ok, I can understand why it wants Qt5Multimedia.dll. Browser can play sound etc. But QML! Why I need all these libraries related to QML?? I don't use neither OpenGL nor sensors or positioning. So it's just unnecessary in my case.
And so my question - is there way to deploy only libraries I need in actual fact? And get the program work of course.
I would suggest you to use windeployqt.exe.
From the docs:
The Windows deployment tool can be found in QTDIR/bin/windeployqt. It
is designed to automate the process of creating a deployable folder
that contains all libraries, QML imports, plugins, translations that
are required to run the application from that folder. This is used to
create the sandbox for Windows Runtime or an installation tree for
Windows desktop applications that can be easily bundled by an
installer.
This is how I do:
cd [my program dir]
mkdir RELEASE
cd RELEASE
copy ..\"progname.exe" .
set QTDIR=C:\Qt\Qt5.4.1\5.4\mingw491_32\bin
call %QTDIR%\qtenv2.bat
windeployqt --force "progname.exe"
You could adapt that for your need by changing [my program dir] to your application's folder (containing the .exe file), QTDIR to your Qt MinGW folder (that's what I use) and progname.exe with the name of your executable file.
It will create a release directory with your executable and the needed Qt libraries (.dll's, etc).
I'm interested in building an RPM package for sbt 0.12.3 that meets the Fedora packaging guidelines. In order to do this, I'll need to be able to build sbt itself against libraries that were built from source and installed via RPM packages.
Java packages in Fedora that use Ivy are able to resolve RPM-installed artifacts by disabling network resolvers and resolving all packages from /usr/share/java/[artifact].[ext] -- see here for an example.
I think I understand how to override default resolvers in sbt using a boot properties file, but this is where I run in to a problem: if I set the Ivy directory to /usr/share/java, sbt expects to be able to publish artifacts to this directory (not merely to look for existing artifacts there), which I don't want it to do (both in general and for this specific case of RPM building). If I specify file:///usr/share/java as a proxy location (following Mark's instructions below), sbt will fail (citing the absence of ivy.xml in that location).
I am able to find locally-installed dependencies by modifying project/p.sbt to point to explicit URLs (e.g. "org.jsoup" % "jsoup" % "1.7.1" from "file:///usr/share/java/jsoup.jar"), but this doesn't work for scala and the scala library (and is obviously not the right thing to do in general).
How can I build sbt against (and only against) locally-installed, RPM-managed system Scala and libraries?
I am writing c++ program using poco c++ library and execute in PC environment successfully. But how to cross compile into ARM-Linux .
I am following from the poco GMakeBuildNotes, but I do not know where I made mistakes. Can anybody help me how to cross compile step by step. Here are the steps I am currently following:
./configure --config=ARM-Linux --no-samples --no-tests
make
cross compile in QT framework
Any suggestions to improve these steps, please?
This post is old and you didn't really stated what's the problem, but still I'll share. I'm getting started with poco for our embedded systems and this is how I compiled it for ARM linux:
If you download and unpack the poco package, you'll find a directory: build/config
Here you can find various preset configs for poco builds. I made a copy of 'ARM-linux' and edited it to suit my needs (these are only the changes):
LINKMODE ?= STATIC # since we are statically linking poco...
...
TOOL = arm-none-linux-gnueabi # this is the compiler we use
The rest was okay for me!
Then I compile poco like this:
$ ./configure --config=MY_OWN_CONFIG --prefix=/absolute/path/to/target/dir --no-samples --no-tests
$ make (compiles without a problem for me)
$ make install
after 'make install' (if everything is fine) the compiled libs will be in the directory specified by the '--prefix' option, and they are ready to be linked to your ARM applications.
I hope it helps!