Hi Brian,

I assume that your module's code has direct dependencies on classes defined in the issues module?

Right now the build enforces that modules don't have dependencies on each other beyond the classes they include in either API or Internal. At runtime all of the classes from all of the modules end up in the same classloader.

Our approach to date for this kind of cross-module dependency is to extract classes and interfaces and add them to API. We've talked about switching to a build that allows each module to expose its own API without needing to have the classes in the API module itself, or adopting OGSI or a similar approach, but this hasn't been prioritized so far.

In practice, your approach will work, but you'll end up with two (hopefully identical) sets of classes in scope to the same classloader from the issues module and your module. I don't know the scope of your dependencies, so it's hard to know what to recommend.

Thanks,
Josh