Directly detect intercomponent dependencies from Java code

[Z13NDELS]

This is easy, provided we know how to parse components : just read imports from components source code using JavaParser, and detect if these dependencies are non static and go from one component to one another

[Riduidel]

This is (partially) implemented in sequence-diagram-generator maven module, but could be improved (and module name could be changed.

[Riduidel]

ok, let's explain dev strategy : the architecture-documentation maven module invokes the sequence-diagram-generator module as a dependency, triggeing the sequence diagrams generation in target/structurizr. I see multiple deffects that I'll try to handle separatly by creating sub-issues (which to my mind mostly come from my inhability to correctly parse modern java code).

[Riduidel]

So first bug is easily viewed.

Here is the /architecture-documentation/target/structurizr/diagrams/Aadarchi/base/ArchitectureDocumentationBuilder/ArchitectureDocumentationBuilder_run.plantuml diagram. It exposes the ArchitectureDocumentationBuilder#run method.

But look ! here is the ArchitectureEnhancer#enhance method code ...

		classloader = Thread.currentThread().getContextClassLoader();
		logger.info(() -> String.format("Enhancers applied to this architecture are\n%s",  
			enhancers.stream()
				.sorted(Comparator.comparingInt(e -> e.priority()))
				.map(e -> String.format("%s => %d", e.getClass().getName(), e.priority()))
				.collect(Collectors.joining("\n"))));
		withStopWatch("Running all enhancements took %s", () -> enhancers.stream()
			.sorted(Comparator.comparingInt(e -> e.priority()))
			.forEach(enhancer -> enhancerVisitWorkspace(enhancer, workspace)));
	}

You see what is wrong ?
Yup, there are enhancers.stream() calls. And the mix between iteration through keywords and iteration through method calls is not nice.
Furthermore, the #enhancerVisitWorkspace method, which is private, prevent us from understanding the full visit. This is unfortunate, and should be fixed.

[Riduidel]

Regarding the streams, and closures from java 8, the first log line is quite clear

[ERROR] (org.ndx.aadarchi.sequence.generator.javaparser.visitor.JavaParserVisitorForBuildingCallGraph) Unable to resolve method call String.format("Enhancers applied to this architecture are\n%s", enhancers.stream().sorted(Comparator.comparingInt(e -> e.priority())).map(e -> String.format("%s => %d", e.getClass().getName(), e.priority())).collect(Collectors.joining("\n"))) due to exception "Unable to calculate the type of a parameter of a method call. Method call: String.format("Enhancers applied to this architecture are\n%s", enhancers.stream().sorted(Comparator.comparingInt(e -> e.priority())).map(e -> String.format("%s => %d", e.getClass().getName(), e.priority())).collect(Collectors.joining("\n"))), Parameter: enhancers.stream().sorted(Comparator.comparingInt(e -> e.priority())).map(e -> String.format("%s => %d", e.getClass().getName(), e.priority())).collect(Collectors.joining("\n"))". We give up on that one.

So I never wrote the code to understand what a closure is ... Let's start with that very precise problem.

[Riduidel]

Regarding the initial subject, it seems like letting the visitor handling the navigation in the containers may not be the smartest idea.
Indeed, the aadarchi.sequence.generator.with define a list of containers used to render diagram.
As a consequence, those containers should be scanned before the current one. Which screams Direct acyclic graph to my ears. A notion which is very interesting, but which is not yet supported by our model visitor system.