Separation of configurations about schemaspy HOT 1 OPEN

The organisation isn't 100% percent regarding the command line arguments. So let's create a guideline.

CommandLineArguments should only contain "arguments" that are handle during an early exit.
Examples would be -help, -dbhelp, -license.

SchemaSpy has org.schemaspy.output.dot DotConfigexists in that package/module and is used by the package/module.

As for passing configuration to Graphviz or Vizjs, they live in another package/module and Graphviz has it's own GraphvizConfig.

So there should be a config per package/module I would say.

As for the stretching, I'm having somewhat of a problem debating it. We have our own Connection interface for abstracting connection to a database which is more or less what the java.sql.Connection abstraction is for, so there would be sort of the same confusion. Dot executable from graphviz or Dot language, we could go even further as dot layout engine or dot render engine.

To make all this work we must set the context as SchemaSpy, so Dot in SchemaSpy is the language/syntax/module/package and not the renderer/layout/executable. The same way a Connection is our Connection and not java.sql.Connection.

Increasingly important is that "dot" the executable is not the only way to render a diagram from dot language/syntax. Hence we should talk about Graphviz and GraphvizConfig and Vizjs and VizjsConfig.

As for passing this type of grouped configuration all the way down to the leafs of the object graph that is bad and should be avoided, they should be deconstructed early in a module aggregate.

from schemaspy.