janscheible/pocketsaw

Compile time sub-module system, aimed at package group dependency organization within a Maven project resp. Java 9 module (and even more, see the Angular example).

pocketsaw's Issues

weighted code edges in dependency graph

Currently code dependencies are binary. Either there or not.
To show if an dependency is rather weak or strong it would be good to add the number of dependency relations in the code to the dependency graph.

Java 7 compatibility for api

Language level (and JDK APIs) of Java 7 should be enough.

Spring Boot JAR dependency source

support of esbuild build metadata

esbuild can emit a metadata file that contains information about all imports: https://esbuild.github.io/api/#metafile
This can be used in a PackageDependencySource for all projects that use esbuild for bundling (similar to pocketsaw-dependecy-cruiser).

explicit root sub-module for ES6 JavaScript analysis

Maven plugin with requiresProject=false in addition to CLI

In addition to the CLI a Maven plugin with a Mojo that has requiresProject=false could be added.
That would allow and invocation like

mvn com.scheible.pocketsaw:pocketsaw-maven-plugin:run -DsubModules=sub-module.json -Ddependencies=dependencies.json -Dsource=dependency-cruiser -Doutput=pocketsaw-dependency-graph.html

even without having a surrounding Maven project.

parameter support for dependency sources

native support of es6 modules

Currently JavaScript (and TypeScript) support is available via Dependency cruiser. Disadvantage is that Dependency cruiser requires nodejs. For native support it should be enough for a beginning to extract all static and dynamic import statements and resolve them.

integration with jQAssistant

Identifying code level dependencies and scanning for all @SubModule and @ExternalFunctionalities annotated classes is a perfect fit with jQAssistant.

The main question is how the integration should look like. Perhaps Pocketsaw can be called in a jQAssistant plugin.

layered representation of code dependencies

The current dependency graph with a physic based layout gets rather confusing as the number of sub-modules increases.
For graph drawing there are algorithms for Layered graph drawing.
To deal with cycles one approach would be to remove edges with lowest number of code dependencies (introduced in #16) until there are no cycles left.
That would leave us with all allowed dependencies going from top to bottom. Only the illegal ones will go from bottom to top.

object-oriented metrics for package groups

For example the ones of Robert C. Martin would fit pretty good.

analysis fails if jdeps is not on OS search path

System.getenv("JAVA_HOME") and System.getProperty("java.home") have to be used to find the jdeps executable.

improve support for multi module projects

Some investigations are needed:

• How to share external functionality definitions?
• How to create a unified dependency graph for all modules?
  • Hierarchical drill down in the visualization would be great. :-)

dependency graph could contain self-dependencies

The expected behavior is that this is not the case.
Self-dependencies are simply not interesting at all from package group structuring view.

1.1.0 release modifies com.scheible.pocketsaw.api:pocketsaw-api:1.0.1 without increasing version

The parent version was updated to 1.1.0. This is not valid.
Parent will be removed and a fix release 1.1.1 (with API in version 1.0.2) is needed.

descriptor dependency with no corresponding code dependencies causes NullPointerException

integration with Dependency Cruiser

With dependency-cruise -T json Dependency Cruiser can output all its informations into a JSON file that can easily be parsed. Together with the support for generic third-party dependency information sources (#11) this output can be used in Pocketsaw.

support for generic third-party dependency information

Some Java interface like:

interface PackageDependencySource {
  PackageDependencies read(File file);
}

It can then be implemented for any third-party dependency information source and be passed to Pocketsaw invocation. Third-party dependency information source selection must later also be available for the CLI (see #12).

identification of sub-module used types

extraction of pocketsaw-api

In order to clearly see the exposes API surface all classes visible to the outside (mainly unit tests but also classes implementing PackageDependencySource) should go to that artifact. The annotations should go to something like pocketsaw-annotations.

wrong cycles are reported

For a graph with nodes a, b, c and edges a -> b, b -> c, c -> b an incorrect cycle of a -> b -> c -> a is reported. Reason for that is that the cycle is correctly detected but the access route starting from a is treated as part of the cycle.

bump up javascript-es2020-parser to 0.5.1

Build of javascript-es2020-parser 0.5.0 failed under linux: janScheible/javascript-es2020-parser#7

support of ClassGraph as ClasspathScanner

ClassGraph support would be good.

allow filtering of external functionalities in dependency graph html

To allow easier analysis of the sub module structure it would be good to filter out the external functionalities.

improve CycleDetector class

For now the cycle detector in com.scheible.pocketsaw.impl.dependency.CycleDetector is very basic. It finds any cycle in a non deterministic way. That also means it is not always the shortest cycle.

Perhaps Highwheel can be used or at least an inspiration.

multiple match packages for external functionalities

external functionalities support in sub-module.json

command line support

Something like: pocketsaw <sub-module.json> <dependencies.file> {<first-deps-source>|<second-deps-source>} <pocketsaw-dependency-graph.html>.
In order to support a workflow similar to Workflow for using Pocketsaw in a project there must also be a way to skip the check for illegal code dependencies (e.g. --ignore-illegal-code-dependencies).
Also meaningfull error codes will make integration into some scripts easier.

unmatched package when generating code

When for example using openapi-generator-maven-plugin to generate an API client in a package outside of the base package this works with Pocketsaw.analizeClasspath(...) but not with Pocketsaw.analizeCurrentProject(). The reason is that ClassgraphClasspathScanner (currently the only DependencyAwareClasspathScanner implementation) respects the base package but the otherwise used JdepsWrapper not.

display package match patterns of package groups in the dependency graph html

For example as tooltip.

Jdeps wrong path on Arch Linux

Unit test fails on an Arch Linux system:

java.io.UncheckedIOException: java.io.IOException: Cannot run program "/usr/lib/jvm/java-11-openjdk/../bin/jdeps": error=2, No such file or directory

The correct path on my system is:

$ which jdeps
/usr/lib/jvm/default/bin/jdeps

(This is a symlink, on Arch Linux you can easily change the Java version using a script)

Or the direct path:

$ /usr/lib/jvm/java-11-openjdk/bin/jdeps -version
11.0.4

JAVA_HOME is not set

jshell> System.getProperty("java.home");
$1 ==> "/usr/lib/jvm/java-11-openjdk"

It seems like the system property does not include the bin directory while the environment variable does.

duplicate key exception in DependencyGraphFactory

Happens since 1.2.0 and was observed in several different projects:

java.lang.IllegalStateException: Duplicate key 1
	at java.util.stream.Collectors.lambda$throwingMerger$0(Collectors.java:133)
	at java.util.HashMap.merge(HashMap.java:1254)
	at java.util.stream.Collectors.lambda$toMap$58(Collectors.java:1320)
	at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169)
	at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1553)
	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
	at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
	at com.scheible.pocketsaw.impl.dependency.DependencyGraphFactory.lambda$create$4(DependencyGraphFactory.java:34)
	at java.lang.Iterable.forEach(Iterable.java:75)
	at com.scheible.pocketsaw.impl.dependency.DependencyGraphFactory.create(DependencyGraphFactory.java:31)

missing fat Jar for CLI

Currently no fat Jar for CLI is produced by Maven build.

descriptor auto matching

Sub-module and external functionality descriptors should be generated automatically if they are not explicitly defined.

configurable classpath and working directory for jdeps invocation