Question

I am currently defining the project structure for a project that I am working on. The project is a simple SOA implementation and as such has a grails app and a number of different services.

I wanted to package these services into separate modules (jars) so that they can easily be deployed separately and there is no risk of cost-contamination of classes.

The project structure and dependancies could be visualised as:

Grails App (war)
|__ Service Gateway (jar)
    |__Service A (jar)
    |__Service B (jar)

Whilst these services will eventually be deployed seperately, for ease of local development I want to package them into a single grails app until such time as it is necessary to break them apart.

My ultimate goal was to be able to develop these services in the same way I would a simple grails app in that I would be able to change any class (within any of the modules) on the fly and have it picked up.

I am struggling though to see the best way in IntelliJ to represent this structure.

I had created seperate modules for each of the above and added the dependancies between them, but obviously grails has no idea of this at runtime.

I have read about and found the following possible solutions, all of which currently feel a bit unsatisfactory as would require a jar to be built meaning that classes cannot be reloaded on the fly.

1. Install the modules into the local maven repository and reference this in the grails build dependancies.
2. Drop the built jars into the lib directory.
3. Add them as grails plugins (seems a little heavy handed as they won’t require grails functionality).
4. Find some other way of including the output directories for these modules on the grails classpath (not sure of the cleanest way to do this).

Thanks!

Answer 1

In the end, I went with a multi module Maven build. The key to the on the fly code deployment is using JRebel to monitor the output directories and reload the classes when they change.