Configuration properties to specify additional module-path's #97
Comments
|
Hi @commi! Why don't you install 3rd party Jars to the Maven local repo? What do you refer with "third-party automatic modules"? Is it possible to add more than one $ jdeps --help
Usage: jdeps <options> <path ...>]
<path> can be a pathname to a .class file, a directory, a JAR file.
Possible options include:
-h -? --help Print this help message
-dotoutput <dir>
--dot-output <dir> Destination directory for DOT file output
-s -summary Print dependency summary only.
-v -verbose Print all class level dependences
Equivalent to -verbose:class -filter:none.
-verbose:package Print package-level dependences excluding
dependences within the same package by default
-verbose:class Print class-level dependences excluding
dependences within the same package by default
-apionly
--api-only Restrict analysis to APIs i.e. dependences
from the signature of public and protected
members of public classes including field
type, method parameter types, returned type,
checked exception types etc.
-jdkinternals
--jdk-internals Finds class-level dependences on JDK internal
APIs. By default, it analyzes all classes
on --class-path and input files unless -include
option is specified. This option cannot be
used with -p, -e and -s options.
WARNING: JDK internal APIs are inaccessible.
-cp <path>
-classpath <path>
--class-path <path> Specify where to find class files
--module-path <module path> Specify module path
--upgrade-module-path <module path> Specify upgrade module path
--system <java-home> Specify an alternate system module path
--add-modules <module-name>[,<module-name>...]
Adds modules to the root set for analysis
--multi-release <version> Specifies the version when processing
multi-release jar files. <version> should
be integer >= 9 or base.
-q -quiet Suppress warning messages
-version --version Version information
Module dependence analysis options:
-m <module-name>
--module <module-name> Specify the root module for analysis
--generate-module-info <dir> Generate module-info.java under the specified
directory. The specified JAR files will be
analyzed. This option cannot be used with
--dot-output or --class-path. Use
--generate-open-module option for open modules.
--generate-open-module <dir> Generate module-info.java for the specified
JAR files under the specified directory as
open modules. This option cannot be used with
--dot-output or --class-path.
--check <module-name>[,<module-name>...
Analyze the dependence of the specified modules
It prints the module descriptor, the resulting
module dependences after analysis and the
graph after transition reduction. It also
identifies any unused qualified exports.
--list-deps Lists the module dependences. It also prints
any internal API packages if referenced.
This option transitively analyzes libraries on
class path and module path if referenced.
Use --no-recursive option for non-transitive
dependency analysis.
--list-reduced-deps Same as --list-deps with not listing
the implied reads edges from the module graph.
If module M1 reads M2, and M2 requires
transitive on M3, then M1 reading M3 is implied
and is not shown in the graph.
--print-module-deps Same as --list-reduced-deps with printing
a comma-separated list of module dependences.
This output can be used by jlink --add-modules
in order to create a custom image containing
those modules and their transitive dependences.
--ignore-missing-deps Ignore missing dependences.
Options to filter dependences:
-p <pkg>
-package <pkg>
--package <pkg> Finds dependences matching the given package
name (may be given multiple times).
-e <regex>
-regex <regex>
--regex <regex> Finds dependences matching the given pattern.
--require <module-name> Finds dependences matching the given module
name (may be given multiple times). --package,
--regex, --require are mutual exclusive.
-f <regex> -filter <regex> Filter dependences matching the given
pattern. If given multiple times, the last
one will be used.
-filter:package Filter dependences within the same package.
This is the default.
-filter:archive Filter dependences within the same archive.
-filter:module Filter dependences within the same module.
-filter:none No -filter:package and -filter:archive
filtering. Filtering specified via the
-filter option still applies.
--missing-deps Finds missing dependences. This option
cannot be used with -p, -e and -s options.
Options to filter classes to be analyzed:
-include <regex> Restrict analysis to classes matching pattern
This option filters the list of classes to
be analyzed. It can be used together with
-p and -e which apply pattern to the dependences
-P -profile Show profile containing a package
-R
--recursive Recursively traverse all run-time dependences.
The -R option implies -filter:none. If -p,
-e, -f option is specified, only the matching
dependences are analyzed.
--no-recursive Do not recursively traverse dependences.
-I
--inverse Analyzes the dependences per other given options
and then find all artifacts that directly
and indirectly depend on the matching nodes.
This is equivalent to the inverse of
compile-time view analysis and print
dependency summary. This option must use
with --require, --package or --regex option.
--compile-time Compile-time view of transitive dependences
i.e. compile-time view of -R option.
Analyzes the dependences per other given options
If a dependence is found from a directory,
a JAR file or a module, all classes in that
containing archive are analyzed.How would you translate this possible option of the plugin into a call to <additionalModulePaths>
<additionalModulePath>path1</additionalModulePath>
<additionalModulePath>path2</additionalModulePath>
<additionalModulePath>path3</additionalModulePath>
</additionalModulePaths>
What other issues do you have in mind? Thanks! |
After some Googling 😅 : "You can use your library as an automatic module. An automatic module is a module that doesn't have a module descriptor (i.e. module-info.class)." |
Javapacker copies all maven dependencies to <repository>
<id>repo</id>
<name>local static repository for jars not in maven</name>
<url>file://${project.basedir}/repo</url>
<releases>
<enabled>true</enabled>
<checksumPolicy>ignore</checksumPolicy>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>that contained all the needed jars. Maven is fine with this, but the jdeps call inside Javapackager still fails, even tho the correct jars are copied to jdeps -q --multi-release 11 --list-deps target\signoteclizenzgenerator-1.0-runnable.jar target\signoteclizenzgenerator\libs\*.jar
Exception in thread "main" java.lang.module.FindException: Module stlic.lib not found, required by signoteclizenzgeneratorSo i would assume it would also not work with any kind of maven repo, because jeps does not know about the repo. If copy the call and edit it (add just the folder jdeps -q --multi-release 11 --module-path .\lib --list-deps target\signoteclizenzgenerator-1.0-runnable.jar target\signoteclizenzgenerator\libs\*.jar
java.base
java.datatransfer
java.desktop
java.logging
java.management
java.naming
java.prefs
java.sql
java.xml
javafx.base
javafx.controls
javafx.fxml
javafx.graphics
You can specify it multiple times:
When i set That looks to me as if the Zulu JDK has a 64bit module in it, no? Cheers! PS: in the meantime we successfully migrated two projects from the javafx-maven-plugin to yours, which enabled a lot more customization for us, and got rid of the old exe-launcher the JDK8 provided. So thank you a a lot:) |
fvarrui
added
enhancement
|
Ok, I think it's easy to implement this feature just as you propose ... but I still don't understand why, if all the libraries have been copied to the What's in your For example: jdeps -q --multi-release 11 --module-path target\signoteclizenzgenerator\libs --list-deps target\signoteclizenzgenerator-1.0-runnable.jar Sorry for asking so many questions! PS: Thanks for giving JavaPackager a try! I tried to create a plugin that would do all this dirty work with minimal configuration and yet could be customized as much as possible (or at least, that incorporating changes to support more customization was simple and that anyone could incorporate any needed improvement without affecting the previous functionality). |
|
Hi @commi! This feature is available in issue-97 branch, so, you can try the new <additionalModulePaths>
<additionalModulePath>path1</additionalModulePath>
<additionalModulePath>path2</additionalModulePath>
<additionalModulePath>path3</additionalModulePath>
</additionalModulePaths>You have to install JavaPackager manually to your local repo. If it works fine for you, I'll release it to Maven Central asap. |
|
@commi, feedback please! |
|
I switched to the snapshot-version and it works great: <additionalModulePaths>
<additionalModulePath>./lib</additionalModulePath>
</additionalModulePaths>
<additionalModules>
<module>java.scripting</module>
<module>jdk.unsupported</module>
<module>java.logging</module>
</additionalModules>[INFO] Bundling JRE ... with C:\Users\tst\.jdks\azul-11.0.10
[INFO] Creating customized JRE ...
[INFO] Getting required modules ...
[INFO] Executing command: cmd.exe /s /c "C:\Users\tst\.jdks\azul-11.0.10\bin\jdeps -q --multi-release 11 --list-deps --module-path C:\Users\tst\IdeaProjects\signotec-lizenzgenerator\lib C:\Users\tst\IdeaProjects\signotec-lizenzgenerator\target\signoteclizenzgenerator\libs\*.jar C:\Users\tst\IdeaProjects\signotec-lizenzgenerator\target\signoteclizenzgenerator-1.0-runnable.jar"
[INFO] java.base
[INFO] java.datatransfer
[INFO] java.desktop
[INFO] java.logging
[INFO] java.management
[INFO] java.naming
[INFO] java.prefs
[INFO] java.sql
[INFO] java.xml
[INFO] javafx.base
[INFO] javafx.controls
[INFO] javafx.fxml
[INFO] javafx.graphics
[INFO] Required modules found: [java.base, java.datatransfer, java.desktop, java.logging, java.management, java.naming, java.prefs, java.sql, java.xml, javafx.base, javafx.controls, javafx.fxml, javafx.graphics, java.scripting, jdk.unsupported, java.logging]
[INFO]
[INFO] Creating JRE with next modules included: java.base,java.datatransfer,java.desktop,java.logging,java.management,java.naming,java.prefs,java.sql,java.xml,javafx.base,javafx.controls,javafx.fxml,javafx.graphics,java.scripting,jdk.unsupported,java.loggingThanks for the update! |
|
Great! I'll release JavaPackager 1.6.0 to Maven Central asap |
I'm submitting a…
To add Automatic & non-Maven Modules from Third-Party vendors we just put then in separate folder. At runtime they found just fine, but jdeps fail when searching for dependencies.
What is the expected behavior?
The current behavior not incorrect but i prevents the use of the module-search feature, if there are third-party automatic modules present.
What is the current behavior?
There could be a configuration property to specify one or more paths, that will be added as
--module-pathto the jdeps call.What is the motivation / use case for changing the behavior?
to automate more build configurations.
Other information (e.g. related issues, suggestions how to fix, links for us to have context)
The workaround right now is to call jdeps manually with the required
module-paths's an then set those modules explicitly in the<module>property. That is a good workaround, but more automation is always better:)Another workaround is to disable
customizedJre, but this did not work in our case, because the Zulu JDK 32bit, which we use, contains modules that break bundling. Another issue, but one which probably cannot be solved by this tool.The text was updated successfully, but these errors were encountered: