Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: Don't shorten the names of plugins on the diagram #16

Closed
mqware opened this issue Dec 6, 2023 · 2 comments
Closed

Suggestion: Don't shorten the names of plugins on the diagram #16

mqware opened this issue Dec 6, 2023 · 2 comments

Comments

@mqware
Copy link

mqware commented Dec 6, 2023

I would suggest removing the code in PluginApplicationOrderAnalysis.kt that shortens the names of the plugins, for the following reasons:

  1. I refactored this project and changed "org.example" to the actual domain name that I am using, and coincidentally the shortened name became "c.a", which is the same as for com.autonomousapps. This was not only confusing, but it caused the two dependency-analysis plugins to be merged on the diagram, so it was actually incorrect.
  2. For someone who is less familiar with the structure of this project, seeing names like 'o.o', 'o.g', 'd.j', etc. might look confusing.
  3. I commented out the code, and the generated diagram renders nicely with the full names, so I don't really see the need to use abbreviations when we can also avoid any of the potential issues mentioned above.
    Thanks,
    Peter
@jjohannes
Copy link
Owner

Thank you @mqware for the feedback and the suggestion. I think this is a good change. I will consider this with the next update of the project.

@jjohannes
Copy link
Owner

This is done now.

However, I did a larger change in how to cut the convention plugins as experience from several projects has shown me that introducing too much of a "hiearchy" in the plugins make it really hard to follow and understand.

Instead, I now try to do one "convention plugin" per "build feature". And then combine these all to one "component plugin" in a flat way (see updated project and Readme).

In this setup, I find this diagram is not very useful anymore, because it becomes rather unreadable. Instead, maybe it is better to have some tests that checks the plugins that you follow a certain structure in general. (I now have a few tests for the plugins showing how that can be done).

But there is probably still much room to improve all of this further 😄.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants