Jarviz v0.3.0 has just been released! This version includes plenty of improvements: additional inputs supported by all commands, multiple inputs per command, new commands, and more!
Repeatable Command Inputs
Jarviz original goal is to inspect JAR files. Its first 2 releases let you define the target JAR to be analyzed by setting a value for one of these flags:
--file. This is OK as long as you're analyzing a single file, but what if you want to analyze a set of files? One option would be to invoke Jarviz multiple times which is OK for trivial cases. Once you add reports into the mix then things get a bit more complicated otherwise report output could inadvertently get overwritten.
For this reason Jarviz now lets you define as many entries as possible using a combination of
--file as needed, for example
$ jarviz module name --gav org.jreleaser:jreleaser:1.5.0 \ --url https://repo1.maven.org/maven2/junit/junit/4.13.2/junit-4.13.2.jar
Additional Command Inputs
While the 3 previously mentioned inputs are sufficient for many cases there may be times where you'd simply ant to run Jarviz on a set of existing JARs residing on a directory. Well, the
--directory input can take care of that. Other times you may encounter a set of JARs whose local paths can be described as a "classpath" that is, paths separated by a platform specific character (
: for Unix,
; for Windows). You may use
--classpath for this kind of inputs.
And of course you can mix and repeat these 2 new inputs with the previous 3.
Jarviz defaults to printing colorized text reports for all of its commands. You have the option to write additional reports in
XML formats to a given file. With the new
--output-format feature you may tell Jarviz to use a different format other than text, useful for piping the result into other commands.
There are 5 new commands available in this release:
1. entries extract
Extract a JAR entry by name or matching a given pattern. You have the option to copy the entry with its whole path or just the plain entry name if
--flatten is used. Examples
Obtain the GAV file created by Maven Archiver
$ jarviz entries extract --gav org.jreleaser:jreleaser:1.5.0 --entry-name META-INF/maven/org.jreleaser/jreleaser/pom.properties --flatten $ jarviz entries extract --gav org.jreleaser:jreleaser:1.5.0 --entry-pattern **/pom.properties --flatten
Both of these commands produce the following
$ tree jreleaser-1.5.0/ jreleaser-1.5.0/ └── pom.properties 0 directories, 1 file
2. entries find
Find a given JAR entry by name or by matching a given pattern. Useful for checking if a JAR contains a given entry or not. Examples:
$ jarviz entries find --gav org.jreleaser:jreleaser:1.5.0 --entry-name META-INF/MANIFEST.MF subject: jreleaser-1.5.0.jar entry name: META-INF/MANIFEST.MF META-INF/MANIFEST.MF
Junit 3.7 does not contain metadata created by Maven Archiver
$ jarviz entries find --gav junit:junit:3.7 --entry-pattern **/pom.properties
Verify local checksums against published checksums available from Maven Central. This feature currently relies on discovering GAV coordinates located in the
pom.properties file created by the Maven Archiver. Not all JARs published at Maven Central have this file and thus prefer the use of
--gav to specify inputs. Example:
$ jarviz checksum --gav org.jreleaser:jreleaser:1.5.0 --gav junit:junit:3.8.2 subject: jreleaser-1.5.0.jar jreleaser-1.5.0.jar.md5 SUCCESS jreleaser-1.5.0.jar.sha1 SUCCESS jreleaser-1.5.0.jar.sha256 SUCCESS jreleaser-1.5.0.jar.sha512 SUCCESS subject: junit-3.8.2.jar junit-3.8.2.jar.md5 SUCCESS junit-3.8.2.jar.sha1 SUCCESS junit-3.8.2.jar.sha256 UNAVAILABLE junit-3.8.2.jar.sha512 UNAVAILABLE
JARs published via Gradle tend to have 4 checksum files while Maven usually publishes 2 by default.
4. packages split
Checks a set of JARs for the existence of split packages. Really useful if you want to migrate to Java Modules as the 1st step is to ensure there are no split packages across your [Maven|Gradle] modules and their dependencies. Example:
$ jarviz packages split --gav org.apache.maven:maven-compat:3.9.0 --gav org.apache.maven:maven-core:3.9.0 subject: maven-compat-3.9.0.jar total: 10 org.apache.maven.artifact org.apache.maven.artifact.repository org.apache.maven.artifact.repository.layout org.apache.maven.artifact.repository.metadata org.apache.maven.artifact.resolver org.apache.maven.artifact.resolver.filter org.apache.maven.execution org.apache.maven.project org.apache.maven.project.path org.apache.maven.repository subject: maven-core-3.9.0.jar total: 10 org.apache.maven.artifact org.apache.maven.artifact.repository org.apache.maven.artifact.repository.layout org.apache.maven.artifact.repository.metadata org.apache.maven.artifact.resolver org.apache.maven.artifact.resolver.filter org.apache.maven.execution org.apache.maven.project org.apache.maven.project.path org.apache.maven.repository
5. packages validate
Checks that package names are valid. Sometimes shading or jarjaring dependencies leads to invalid package names such as
shadow.META-INF.versions.9, or an old project uses a word that was later converted to a kyeword such as it's the case of
enum in Apache commons-lang. Example:
$ jarviz packages validate --gav commons-lang:commons-lang:2.6 subject: commons-lang-2.6.jar total: 1 org.apache.commons.lang.enum commons-lang-2.6.jar has invalid package names: [org.apache.commons.lang.enum]
While not necessarily an end user facing feature, the whole codebase has been fully modularized with explicit Java module descriptors.
As always, feedback is welcomed, feel free to file a ticket or start a discussion topic.
Keep on coding!
Image by Frank Winkler from Pixabay