3 ms·
When running into these runtime errors, it's sometimes not clear what module a missing class came from for complex setups, especially in a part of code you didn
by blauditore 10y ago
When running into these runtime errors, it's sometimes not clear what module a missing class came from for complex setups, especially in a part of code you didn't recently work in. Then, the right version needs to be determined by following removed intermediate modules. It would just be cleaner and more reliable if the original dev had done this when writing the code in question.
But yeah, at least it fails on compile time already.
- lmm 10y ago> When running into these runtime errors, it's sometimes not clear what module a missing class came from for complex setups, especially in a part of code you didn't recently work in. Just go to search.maven.org and do a full class name search, no?
- blauditore 10y agoThe problem is that this doesn't work for modules not published there, i.e. if you have a large in-house code base split into many maven modules.
- lmm 10y agoIDEs can open classes by name, wherever they are on the classpath. I'd normally have all projects open in any case even on quite large codebases - it's very practical with modern hardware.
- blauditore 10y agoIndeed, but it takes some time to get there in case of dozens or hundreds of modules in different git repos (again, depending on the size of your ecosystem).
- lmm 10y agoI just don't see how this is a problem. For any class on your classpath, ctrl-shift-t or whatever will go to it. If removing a dependency lead to missing that class, you can probably just open it, and you can certainly revert the removal and then just open it. Or do a classname search on your internal maven repository.