How to set TypeDisplay.NONE?

[kno10]

The auto-generated diagrams in my (complex) project tend to become a bit cluttered.
Hence I am looking at ways to reduce contents.

V1 had -umlIncludeMethodParamTypes false, and it seems this functionality may be implemented via TypeDisplay.NONE, but not available via parameters? This should shorten the method signatures in the diagrams, and hence make them more concise.

Is it possible to somehow set local options (per package, per class)? E.g. local remove statements and other plantuml options.

[sjoerdtalsma]

sorry for the late reply

The --show-members option from the Standard doclet should work also for the members rendered in the UML diagrams.

Currently there is not yet a more fine-grained way to configure the inclusion or exclusion of members in the diagrams, other than using --uml-custom-directive. There is an open issue about this to provide a way through java annotations or javadoc tags: #125
Unfortunately both have their own disadvantages.

[kno10]

The members themselves are fine (and I certainly don't want to completely hide them from the javadoc), but I'd like to hide the method parameters (and their types) from the UML diagrams, which is too verbose for larger projects. I could not find a custom-directive that would have this effect.

[sjoerdtalsma]

@kno10 Do you have suggestions on how this could be configured, without falling back to the old huge options list while still allowing some flexibility to set this on per-project, per-package or even per-class level?
(feel free to add suggestions to #125 as well if you like)

[kno10]

For my particular use case, a global command line option would be sufficient here, but in other cases, I'd like to be able to hide inner classes on a per-package or per-class configuration level.
IMHO, javadoc tags would be the most consistent approach, but will often not be updated automatically on refactoring. Java code annotations have much better refactoring and API support (because they have an actual syntax, Javadoc tags are a largely undefined mess), but would clutter the resulting class files, unless RetentionPolicy.SOURCE is used, but its not clear whether these are accessible at Javadoc generation time via introspection, or only when parsing the source manually).

Either way, I am convinced that some kind of annotation mechanism will be necessary for certain features. I believe UML Composition vs. Aggregation are semantic properties that cannot be automatically inferred from the class signature, nor will the quantities of 1:n relationships.

[sjoerdtalsma]

@kno10 I agree with everything you say, this is also the reason that this has not yet been attempted to be solved.
First of all, I can try to figure out the answer to

unless RetentionPolicy.SOURCE is used, but its not clear whether these are accessible at Javadoc generation time via introspection

Furthermore, annotations could be used as a non-tranistive dependency (provided or optional in maven terms), that way you wouldn't have to propagate them with the resulting artifact. Java will just ignore annotations for which it cannot find the definition on the classpath without throwing exceptions.

I'll look into RetentionPolicy SOURCE; it may be the best solution with the most flexibility if possible.

[sjoerdtalsma]

I'm sorry this has been left inactive as long as it has.