I am not using the spring-plugin project. At the start my application was partitioned by stereotype of object. I had packages such as com.example.web,com.example.persistence,com.exmaple.service ... etc but as the application grew and some features were stable and other new features were being rapidly added the organization of the code would not scale.
So I have since partitioned my application into 5 utility modules and 20 separate feature modules that produce jars, and 1 web module that produces a war. The web module only contains static resources, js files, and few traditional MVC controller rather than rest controllers.
By doing the split into feature modules working on the application became a lot easier. It is much easier to find all the code for a feature, git history is easier to deal with to see the evolution of a specific feature, there are feature modules that I have not looked at in months because they just work and when refactoring they don't get touched.
Building on top of component scanning, Spring Java Config, and flywaydb organizing into feature modules is a better solution and more practical solution, for integration testing you can easily start up subsets of the whole application just run the tests for those parts of the system. So if I am working on feature module #7 I can use the Spring MVC Test to just test my controller, services, repositories all the way down to the database simply from the the IDE. I have integration testng tests that launch an embedded tomcat and through the magic of component scanning end up launching a subset of the application which is great for isolating where problems and keep the application rest backend partitioned into services that can be split into into separate servers when the time is right.
I don't know if my use case is the most common use case but I believe that it is the better programming model for working with spring based applications. I think that projects such as Spring Boot with its emphasis on an just having a main method to launch things from will make decomposition into feature modules more desirable and practical. So I hope that you create a design and implementation that can accommodate the feature module use case for Spring 4.0.