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

Josh,

Thanks for the info. When i say an "extension" i really mean "class workflow extends issues". I don't really care that it's a separate module, but i thought it keep my work isolated. I'm beginning to think i can create a new namespace in org.labkey.issue. But if i do this, will i be able to eventually add a new "workflow" item on a web page. I started by looking at the model, but i haven't looked into views yet.

I agree having two issues.jar in scope is bad.

thanks,
Brian

Hi Brian,

Yes, that should work. You can either create a new controller which gets registered inside of IssueModule.init() (just like IssuesController), or create a new View subclass which gets registered inside of IssuesController in the constructor to DefaultActionResolver. The former will create a new controller namespace on the URL and might be a good choice if you anticipate needing to add multiple pages, and the latter will use the existing /issues/ URL mapping.

Thanks,
Josh