Yeah, the problem I think is at least in part due to the architecture - we’ve got modules done more as segregating functionality rather than truly being self-contained.
So, taking a step back, we’ve got two distinct Coldbox applications: a central core and the main webapp.
There’s a single core database plus individual databases for each instance of the main webapp.
Aside from what I’m trying to do at the moment, there are no shared modules - the two apps are mostly independent (they communicate over an API and share some plugins, global layout, and so on, but are generally doing separate things).
So, what I’ve now got is two modules that currently work on the main webapp, and the task is to get them working on core.
The pair of modules are almost entirely self-contained (between themselves) - they are each called by other code, but only reference themselves and each other in all but one case - a single entity has a single FK column reference to an entity in the main webapp (basically a user), and to make it work in the core app I need to reference the equivalent user entity in the core app model.
So yeah, if I could remove that single property, and inject it dynamically based on which application the module is being used by, I could have a single copy of the code and all would be fine - but if that’s possible I don’t know how to do it. (Of course, if this wasn’t all Hibernate-based it would be trivial, but I wont get into a rant about that.)
My compromise to avoid copying the entire code for the two modules is to copy just the model (with relevant tweaks) and setup ModuleConfig to to refer to the existing handlers/etc - this only works with the code change to ModuleService.cfc as described earlier.
Setting CFCLocation to point at the location of the original modules would result in Hibernate either not being able to find the user FK entity, or (if that location was also added) dumping a whole bunch of tables into the core database.
So… that’s hopefully a sufficiently clear explanation? Even though this isn’t an ideal/intended architecture, it does seem that updating handlersLocation to work with mappings is a simple solution that would not get in the way of people doing things the standard way?
Of course if there are other solutions that mean avoiding having to maintain duplicate code then that’d be great too.