I keep on telling people that using the master/submodule relationship, which you are using, will just cause headaches. Instead do this. Define three separate projects - you two existing submodules are two of the projects, the master module becomes its own project with no submodules (instead reference the artifacts created by the submodules as dependencies). Then in Jenkins (or whatever continuous integration manager you use) define the build jobs such that once either "submodule" job is finished that the "master" job should be run.
Of course, if your master POM doesn't build any artifact, then it is even easier - you don't need to define the third project!
I used this very successfully at work for one of our products. There are about a dozen projects, many of which are rolled up into a zip file by another project. That zip project is a separate project that defines the other dozen project's artifacts as dependencies. (One of my coworkers, again my recommendation, went with a master/submodule scheme for one of the projects he migrated to Maven and that team is still struggling with the build process; one of their issues bu=eing that each time they do a build they need to compile the whole world, even submodules that haven't changed.)
Anyway, with completely separate projects you can give different profiles to each project's build.