We Keep Coding

Eclipse cannot find module even the module path is explicitly provided

I have created a module com.company.ep that is located in the source folder com.company.ep. (Yes, I have removed src from the build path and deleted it!) Inside the source folder, I have a couple of packages as the following:
com.company.ep <--- root source folder
com.company.ep.main <--- package 1
com.company.ep.model <--- package 2
com.company.ep.view <--- package 3
// ... more packages
module-info.java
The main class is located in the package com.company.ep.main.Main. In my module-info.java, I have configured the dependencies:
module com.company.ep {
exports com.company.ep.main;
exports com.company.ep.model;
exports com.company.ep.view;
// ... more exports
requires javafx.controls;
requires javafx.graphics;
}
When I tried to launch my program, eclipse told me that:
Error occurred during initialization of boot layer
java.lang.module.FindException: Module javafx.controls not found, required by com.company.ep
So, I tried to run it on the command prompt:
java -p d:\Applications\openjfx-sdk-11\lib;bin -m com.company.ep/com.company.ep.main.Main
bin is the output folder of eclipse, and it worked.
So, I went to Properties → Run/Debug Settings → Main → Show Command Line, it showed:
D:\Applications\openjdk-11.0.1\bin\javaw.exe -Dfile.encoding=UTF-8 -p "D:\Development\Eclipse-Workspace\MyProject\bin" -classpath "D:\Applications\openjfx-sdk-11\lib\javafx.base.jar;D:\Applications\openjfx-sdk-11\lib\javafx.controls.jar;D:\Applications\openjfx-sdk-11\lib\javafx.fxml.jar;D:\Applications\openjfx-sdk-11\lib\javafx.graphics.jar;D:\Applications\openjfx-sdk-11\lib\javafx.media.jar;D:\Applications\openjfx-sdk-11\lib\javafx.swing.jar;D:\Applications\openjfx-sdk-11\lib\javafx.web.jar;D:\Applications\openjfx-sdk-11\lib\javafx-swt.jar" -m com.company.ep/com.company.ep.main.Main
I have created a user library with all JARs added, and the library is added to the project's Modulepath.
Then I have tried to set the module path explicitly in VM arguments in Run/Debug Settings: -p D:\Applications\openjfx-sdk-11\lib, I'd still no luck.
My questions are:
Why javaw.exe?
Why classpath? As my library is added as a module-path entry.
How to configure the module dependencies in eclipse.
I am not sure if I have configured eclipse correctly, or whether it is probably a problem of OpenJDK as it worked when I worked on another computer with Oracle Java SE installed.
Thank you!

The explanation of why Eclipse fails on running your modular project can be found in the OpenJFX docs for Eclipse (modular from IDE section).
As it was already mentioned:
Being a modular project, and since we already added the JavaFX SDK library to the module-path, there is no need to add any VM arguments.
But if you run on Eclipse you will get the mentioned error:
Error occurred during initialization of boot layer
java.lang.module.FindException: Module javafx.graphics not found, required by hellofx
So why is it failing??
As explained in the docs:
This exception happens because the Eclipse ant task overrides the module-path
How does this happen??
Checking the command line applied (Show Command Line from Run Configurations...), you can find out why:
$JAVA_HOME/bin/java -Dfile.encoding=UTF-8 \
-p bin/hellofx \
-classpath $PATH_TO_FX \
-m hellofx/org.openjfx.MainApp
If you copy it and paste it and run it in a terminal, it will fail of course with the same message. The reason is that Eclipse doesn't add the JavaFX library to the module path.
If the task generates the wrong arguments, let's try to fix it by adding our own VM arguments by editing Run configurations... and adding -p $PATH_TO_FX:bin/hellofx.
But if you run it, it will fail again.
Let's check why, with Show Command Line from Run Configurations...
$JAVA_HOME/bin/java -Dfile.encoding=UTF-8 \
-p $PATH_TO_FX:bin/hellofx \
-p bin/hellofx \
-classpath $PATH_TO_FX \
-m hellofx/org.openjfx.MainApp
As you can see, the user's VM arguments are added before the default ant task arguments, so there are two -p (--module-path) options, and the first one (the user's one with the JavaFX jars) is overridden by the second one (only the project's module), so, again, the JavaFX jars are not added to the module path, and hence you get the error.
So how can we fix it??
As mentioned in the linked documentation, the possible fix is:
To prevent this issue click on Run -> Run Configurations... -> Java Application -> Dependencies, select Override Dependencies... and add -p /path-to/javafx-sdk-11/lib:bin/hellofx, and press Override.
With this solution, you can see it works, and you can check the command line:
$JAVA_HOME/bin/java -Dfile.encoding=UTF-8 \
-p $PATH_TO_FX:bin/hellofx \
-p bin/hellofx \
-classpath $PATH_TO_FX \
-p /path-to/javafx-sdk-11/lib:bin/hellofx \
-m hellofx/org.openjfx.MainApp
Basically we are adding again the "right" module path option, after all the failed ones.
While now the project runs, the solution is obviously not nice.
Here you can find a sample referred from the OpenJFX documentation.
EDIT
Based on #kleopatra comments, another workaround to make it work is the following:
For some reason, the library JavaFX11 (that contains modular jars) is not scanned and Eclipse doesn't include those jars into its -p option, but into the classpath:
$JAVA_HOME/bin/java -Dfile.encoding=UTF-8 \
-p bin/hellofx \
-classpath $PATH_TO_FX \
...
But, if you add those jars directly to the module path, it will do add them, and this will run fine:
$JAVA_HOME/bin/java -Dfile.encoding=UTF-8 \
-p bin/hellofx:$PATH_TO_FX/javafx.base.jar:...:$PATH_TO_FX/javafx.controls \
...
Then with this there is no more need to override the dependencies.
EDIT 2
As #mipa points out in a comment, there was a bug filed on this issue, and it has already been solved. I've tested it with Eclipse 2018-12 M2 (4.10.0M2) Build id: 20181108-1653, and it works with the JavaFX11 library only (as it should):
$JAVA_HOME/bin/java -Dfile.encoding=UTF-8 \
-p bin/hellofx:$PATH_TO_FX/javafx.base.jar:... \
-m hellofx/org.openjfx.MainApp

How do I execute a shell command path after creating a new directory in Makefile?

I'm trying to get an updated path of my variable service_SOURCES, after I have generated some files from jaxb with my makefile:
service.jar$(EXEEXT): $(service_SOURCES)
mkdir -p bin
xjc -d src -p gen.files ./src/resources/info.xsd
javac -cp service_SOURCES
service_SOURCES := $(shell find ./src -name "*.java")
I am trying to compile my existing java code with my generated java code Currently, my service_SOURCES variable finds my folder containing my java files, and compiles them all together. I need it to update to include the newly generated java folder, so it compiles my new java files along with my old java files.
I've tried linking the above commands together using && but the shell command still doesn't update. If I run the above commands in terminal it works, but when I run it in my Makefile the path won't update properly.

(moving to answer as this doesn't fit in comment)
You should understand that Make runs in two phases -- The dependency tree is built in the first phase, and the rules are run in the second. This means that the dependency tree cannot be updated by a shell command run after files are generated by a recipe. If you want to do something like this (and I agree with #JohnBollinger, this might not be the best idea), you might need to split your logic between two makefiles, or have a self-recursive makefile. Either way you need to generate the files, then call the second makefile, which can then build a new dependency tree based on a timely shell command.
Alternative:
service.jar$(EXEEXT): _target_to_generate_java_files_
mkdir -p bin
xjc -d src -p gen.files ./src/resources/info.xsd
javac -cp $$(find ./src -name "*.java")

$ is not recognized as an internal or external command

I am trying to develop my own app using Android Studio and Google Calendar API.
The Google page says this:
In your working directory, run the following commands:
$ gradle init --type basic
$ mkdir -p src/main/java src/main/resources
When I try to put that into the command line, it comes back with:
'$' is not recognized as an internal or external command,
operable program or batch file.
Am I putting this in the wrong place?
I didn't even realize they were assuming that people are using Linux. I have a Windows machine. I have tried all the suggestions and am not getting anywhere so far, so I'm not sure where to go from here.

Not a problem at all! The $ means the following command needs to be run in the terminal (in this case, a Bash terminal). So try opening one on your machine and cd'ing into the project. Then run this:
gradle init --type basic && mkdir -p src/main/java src/main/resources
EDIT: Changed it to make use of the && operator

$ is shorthand in documentation for your command prompt and the lines mean you've got two things to enter at subsequent prompts:
gradle init --type basic and
mkdir -p src/main/java src/main/resources

Adding multiple dependent Jars using Javafxpackager

I'm having issues adding multiple packages in the command line.
javafxpackager -createjar -outfile outjar -srcdir /dest/to/src -classPath
libs/library1.jar:libs/library2.jar -appClass pathto.MainClass -v
I've tried with spaces and multiple -classPath flags and obviously I've tried the colons as well. I'm working in Ubuntu and the program works great in Eclipse, but when I package it, it works until I try to do something that requires an external library. If I use only one I can do that function fine, but need multiples to work fully.
If anyone can shine some light on this I would greatly appreciate it.

Instead of:
-classPath libs/library1.jar:libs/library2.jar
use:
-classpath "libs/library1.jar;libs/library2.jar"
Whatever it is that parses the JavaFX-ClassPath that is created in the manifest by the packager doesn't like you having : to separate the libraries. When you use a ; instead in the -classpath argument, the generated JavaFX-ClassPath will use a space to separate the libraries and the runtime will then be able to use both libraries.
Here is a sample manifest I generated using the JavaFX packager on OS X (which worked for me).
$ jar xf HelloWorld.jar
$ cat META-INF/MANIFEST.MF
Manifest-Version: 1.0
JavaFX-Application-Class: HelloWorld
JavaFX-Class-Path: lib/phrases.jar lib/friend.jar
JavaFX-Version: 2.2
Created-By: JavaFX Packager
Main-Class: com/javafx/main/Main
Jar containing the manifest was generated using the command on OS X 10.8 Java 1.8.0-ea-b113:
/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/javafxpackager -createjar -classpath "lib/phrases.jar;lib/friend.jar" -srcdir . -outfile HelloWorld -appclass HelloWorld

java Makefile issue

For a homework assignment I have to make a makefile (physically and in software) for a series of .java files that I have written.
I have written up a make file:
JFLAGS = -d -g bin/
JC = javac
.SUFFXES: .java .class
CLASSES = \
cdn\communications\CommandReader.java \
cdn\communications\CommandReaderFactory.java \
cdn\communications\CommandReaderThread.java \
cdn\communications\DiscoveryCommandReader.java \
cdn\communications\Link.java \
cdn\communications\RefreshThread.java \
cdn\communications\RouterCommandReader.java \
cdn\node\Discovery.java \
cdn\node\Node.java \
cdn\node\Router.java \
cdn\utility\Utility.java \
cdn\wireformats\DeRegisterRequest.java \
cdn\wireformats\DeRegisterResponse.java \
cdn\wireformats\LinkInfo.java \
cdn\wireformats\LinkWeightUpdate.java \
cdn\wireformats\MessageType.java \
cdn\wireformats\PeerRouterList.java \
cdn\wireformats\RegisterRequest.java \
cdn\wireformats\RegisterResponse.java \
cdn\wireformats\RouterInfo.java \
cdn\wireformats\WireFormatFactory.java \
all : $(CLASSES)
clean : $(CLASSES:.java=.class)
But when I run it I get the message "make: Nothing to be done for `all'." and none of my files are made.
Is there something I'm missing here? I'm running the file from the directory that holds the "cdn" directory hierarchy?
Any thoughts would be appreciated.

You have not specified how to build the java classes in your Makefile. Essentially something like below...
.java.class:
$(JC) $(JFLAGS) $*.java
Refer to this link which has a good example.

Fix your all target to depend on .class files instead of .java files (that are already exist and thus " Nothing to be done").
all : $(CLASSES:.java=.class)
Also, you have to a add a rule to compile .java files into .class files:
%.class : %.java
$(JC) $(JFLAGS) $<
In case of using the rule above (so-called pattern rule), .SUFFXES: isn't needed anymore, you can remove it at all.

As outlined by others above, you can easily do something like this:
%.class : %.java
javac flags_go_here
... but there's a few problems with this:
If there are any dependencies between classes -- and there will be -- you'll have to get the order right. There aren't any tools or command-line options like what GCC provides for generating dependencies for you
Java allows circular dependencies between classes. It isn't possible to compile two classes that depend on each-other unless you compile them together, eg:
${JAVAC} ${FLAGS} class1.java class2.java
javac has a long start-up time. For small projects you won't notice it, but for any project where there's enough classes it'll add up fast, and your build times go downhill fast.
The best solution I've come up with is something like the following (using GNU-make style syntax):
all: my.jar
my.jar : c1.java c2.java ... cN.java
${JAVAC} ${JAVAC_FLAGS} ${^}
${JAR} cf ${JAR_FLAGS} ${#} -C src ${^:%.java=%.class}
# As a bonus, here's how you could do JNI stuff based on individual class files.
# This is necessary because nothing in the build actually depends directly on
# the .class files; if they don't exist and the .jar does, then you need some
# way to get the .class files without rebuilding the jar.
# It's written this way so it's re-usable.
# I'm using 'unzip' instead of 'jar' because it has the -j option so it won't
# dump some/irritating/path/to/work/with/when/all/I/need/is/the/.class/file
define CANNED_JAVAH_TARGET =
$(if $(filter %.java,${^}),,\
$(error When building ${#}: No jar dependency provided))
unzip -j -d /somewhere/to/put/temp/class/file \
$(filter %.jar,${^}) ${PKG_PATH}/${#F:%.h=%.class}
${JAVAH} ${JAVAH_FLAGS} <whatever flags are needed to make the header>
endef
${JNI_HEADER_TARGETS} : my.jar
${CANNED_JAVAH_TARGET}
There is a problem with the javah portion: for the JAVAH thing, if someone makes it depend on more than one jar, it'll break. There may be a few minor mistakes or things to work around in the above (going from memory here), but all in all it has worked for me without much hassle.