hideSuperClass
Description
With the help of this configuration parameter it is possible to show the method call as part of the child class instead of the super class if the call starts from the child class.
Example
In the following example there are three dependencies in the maven dependency hierarchy which build the classpath for all further generation:
<dependencies>
<dependency>
<groupId>de.elnarion.util</groupId>
<artifactId>plantuml-generator-util</artifactId>
<version>@project.version@</version>
<classifier>tests</classifier>
<type>test-jar</type>
</dependency>
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>2.16.1</version>
</dependency>
<dependency>
<groupId>javax.persistence</groupId>
<artifactId>javax.persistence-api</artifactId>
<version>2.2</version>
</dependency>
</dependencies>
From this classpath the sequence diagram is generated, but all super classes are hidden if they belong to a known child class, instead the child class is used for the call sequence. This is similar to the JUnit-tests of the PlantUML generator utility:
<plugin>
<artifactId>plantuml-generator-maven-plugin</artifactId>
<groupId>de.elnarion.maven</groupId>
<version>@project.version@</version>
<executions>
<execution>
<id>generate-simple-diagram</id>
<goals>
<goal>generateSequenceDiagram</goal>
</goals>
<phase>generate-test-sources</phase>
<configuration>
<outputFilename>testsequencediagram1.txt</outputFilename>
<startClass>de.elnarion.test.sequence.t0002.CallerClassA</startClass>
<startMethod>testSomething</startMethod>
<hideSuperClass>true</hideSuperClass>
</configuration>
</execution>
</executions>
</plugin>
which is rendered this way:
and produces this PlantUML diagram text:
@startuml
participant CallerClassA
participant SuperClassB
activate CallerClassA
CallerClassA -> CallerClassA : testSuperClassSomething
activate CallerClassA
CallerClassA -> SuperClassB : testSuperClassBSomething
activate SuperClassB
SuperClassB -> SuperClassB : testProtectedSomething
activate SuperClassB
SuperClassB --> SuperClassB
deactivate SuperClassB
SuperClassB --> CallerClassA
deactivate SuperClassB
CallerClassA --> CallerClassA
deactivate CallerClassA
deactivate CallerClassA
@enduml
Without the parameter the diagram would look like this: