[ https://issues.redhat.com/browse/WFLY-11442?page=com.atlassian.jira.plugi... ] Yeray Borges Santana commented on WFLY-11442: --------------------------------------------- Yes, your right. it is a bit tricky and with some subtleties. I should have discussed the methodology with Ranabir before moving on with this issue and advise about this. We didn't talked about it. The process I follow is a bit complex, though. I use [https://docs.oracle.com/javase/9/tools/jdeps.htm|jdeps] to find out code dependencies together with a custom Java application that gives me a report based on module names, it is an orientative report, still manual process is needed to verify the uses. I'm not sure if it makes sense to make it available and count on it to find out dependencies, if so, I have to work on it to make it a bit more useful. The resources root of the affected JBoss module must be reviewed to find out any class loading by using a String or other mechanism, service loader patterns should be also reviewed. In general they should have been covered by the previous step, because a class loading would require at minimum an interface, and if that interface exists, it will be found by jdeps. The implementations could be in a different module. Even though, I think we have to look for those patterns. A general knowledge of the module is also necessary, the component lead should know these details, but sometimes they are so hide that the removal is difficult to perform, even more when the component is big. This step usually is done at PR review. Having say that, if we are not 100% sure the dependency is no longer used or we do not have a strong reason to remove it with a benefit, the best option is to not remove it. -- This message was sent by Atlassian Jira (v7.13.8#713008)