I'm developing a Spring boot / Batch application.

What I'd like to do is to have a separated module for every job. This is a reasonable decision because different tasks (Spring Batch Job) have different domains.

The first thing I've thought about is to make a maven a module for every job. Then, you only need to add your maven dependency to the main project in order to run it.

The problem with this solution is that, if some project won't compile or has failed unit tests, the whole application is stuck as well.

So ideally, I'd like that the failed module won't be loaded to the application whereas other modules can continue their own CI/CD process.

How can that be achieved? Is Java 9 Modularity can be used for this use case?


1 Answer 1


If your modules have different life-cycles, i.e. they are not released always at the same time, or may have bugfix or features releases separately, then you should consider separate repositories for each. Basically have a CI/CD pipeline for each one separately. This is the only sane way you can avoid individual modules blocking each-other.

So, that would mean you have one "api" module that defines the interfaces needed for a module (whatever that is). This API should be very minimal and should be kept relatively stable. This is because all modules would have to depend on it.

Then you would have the actual application, which would/could depend on all modules. If your "plug-in" requirements are static, i.e. you don't need on the fly reload or multiple versions of the same module at the same time, go with the simple ServiceLoader. Have the application simply instantiate/initiate each module through it. The CI/CD pipeline for this should be triggered when a new version/release from any modules is available.

If you do have dynamic loading requirements, you would have to go with something like OSGi. Note however, that can get pretty complex very quickly, as everything is dynamic, things (like services, classes, etc.) can disappear anytime, which is pretty annoying and hard to code safely. The structure would still stay essentially the same.

Note: If the whole thing is in the hands of a single team, I would try to have a single repository. Since everything is in the same hands, it makes it easy to just fix the (compile) problem if there is one, and not deal with separate repositories CI/CD pipelines and versioning problems.

  • Thank you for the detailed answer! In the end of the day, for the sake of simplicity and because of the fact that the code is managed by one time, I'd go with one repository as was suggested by your footnote. Thanks!
    – IsaacLevon
    Commented Apr 4, 2020 at 15:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.