heowc / heo Goto Github PK

Users may want to view visualized reports in different formats

The current dependency direction is reversed.
The referenced module should show an arrow pointing toward the module it references.

(X)

If the Gradle plugin is introduced, it will be more useful. (Even in a CI environment?)

ex)

plugins {
  id "heo"
}

heo {
  package = "com.heowc" // What if we take the `group` as the default?
  destination = "${buildDir}/reports/heo/index.png" // It would be nice if you could configure a new directory under `reports`.
}

The applications we build can be simple, but they are usually complex. So visualizing all the modules may not be very helpful. It may be helpful to see only a part of it.

Users may want to write relative paths more simply and easily rather than absolute paths

$ java -jar heo-cli-0.0.2.jar -d /Users/heowc/Projects/heo -p dev.heowc.heo

# $ java -jar heo-cli-0.0.2.jar -d ./heo -p dev.heowc.heo  # <--

It has a structure other than java.
If it can support languages ​​such as javascript, php, etc., more users will be able to use it.

Sometimes users may want to see detailed logs for the heoReport task.

We can take the following strategies:

1. Provide the ability to change the log level, and run it by changing the log level of a limited package.
2. Run it by changing the desired package and log level, similar to spring.
   • https://docs.spring.io/spring-boot/reference/features/logging.html#features.logging.log-levels

One of the features of heo is that it shows the points where a cycle occurs between modules. If gradle didn't just show this but failed the task, it would be recognized more quickly.

For reference, checkstyle has a verification task and a report task, each of which has its own task.

Currently, heo analyzes the structure of the package structure for a single Java project.

As the project size grows,

there are many cases where it goes from a single module to multiple modules and even multiple package structures.

It would be good to provide it so that it can be used for such projects as well.

product-service
ㄴ com.example.product
order-service
ㄴ com.example.order

In the multi-module above, you may want to analyze the following packages between the product and order modules.

• com.example sub-
• or com.example.product sub- and com.example.order sub- (assuming there are multiple packages)

product-service
ㄴ com.example.product
product-model
ㄴ com.example.productmodel

In the multi-module above, you may want to analyze the following packages between the service and model modules. - subclasses of com.example.product and com.example.productmodel (assuming there are multiple packages)

Currently we are providing cli tools utilizing Java. This somewhat increases the barrier to entry when using the tool.

We would like to provide binary files using native-image.
However, there are still unresolved issues to provide this.

See oracle/graal#8273