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: --gav, --url, or --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 --gav, --url, and --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.

Output Format

Jarviz defaults to printing colorized text reports for all of its commands. You have the option to write additional reports in YAML, JSON, and 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.

New 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

3. checksum

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]

Java Modules

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