Add API support for multi-modules project creation

[dvsingh9]

Spring.io provided initialiser and thats really time saver and helpful, but if anyone wish to create multi-module spring application its still little bit of work. Multi-module project from spring initialiser will add up next level of ease.

[snicoll]

I am not disagreeing with that but I am not sure how we can make that happen while keeping the straightforward use of the UI we have now. Please share a more complete analysis with a concrete use case.

[wilkinsona]

I am not sure how we can make that happen while keeping the straightforward use of the UI we have now

That's my concern with trying to support multi-module projects too. Providing all of the information about the modules and their dependencies would add quite a lot of complexity. There's also the question of what should go in each module. Presumably only one would contain a @SpringBootApplication, but which one? What would the others contain?

I'd really like to be proven wrong, but my current feeling is that there's unlikely to be a common way to initialise a multi-module project and that providing all of the customisation that people would need would add too much complexity.

[snicoll]

Brainstorming but something where a multi-modules setup with a single project is added (the requested project) could be a good middle-ground. We're still limited to one project, with a well defined set of dependencies but the project initialises the proper structure to easily add new modules in the future.

The step of adding a new module in that project can be quite minimal as using the parent gives dependency management and all nice defaults. If we go in that direction we should probably be parent-less by default, as we want to make sure the spring-boot-maven-plugin does not kick in for any other modules by default.

[snicoll]

@rajeshja please do not comment on an issue with an unrelated feature request. I've already mentioned earlier today that I don't think this project should be used to explain how users should configure their build to use the module path.

[JacksonZhangHuaQuan]

I am also very concerned about the creation of multi-module skeleton, I hope to have an example for reference.

[sagacity]

To give a bit of background why we would like this feature as well: My company's services typically have a multi-module structure. This does not necessarily mean initialzr needs to create multiple modules from the get-go, but it would be nice if it could provide a single module that contains the application class and the relevant dependencies, with perhaps some dependency/plugin management in the parent.

This setup would make it a bit simpler for our developers to add modules since they don't need to migrate the initialzr-generated non-multimodule project to a multimodule project (which they'll inevitably have to do at some point).

We are currently using some custom contributors for this, which during generation move some files around in a ProjectContributor, use a subclassed MavenBuildWriter to write the modules section, etc. It would be nice if there was 'native' support for this in Initialzr itself, since we are now heavily dependent on the ordering of the contributors, which feels a bit flaky.

Btw, I'm not necessarily saying this should be an integral feature of Initialzr, but perhaps a few extension points could be introduced to make it easier for people to customize Initialzr to be able to define a multimodule project?

[snicoll]

Thanks for sharing your thoughts, that's very interesting. I've experienced those issues myself so it's nice to have a summary from someone else.

Having the notion of modules in our core abstraction could be interesting indeed. I am convinced we could implement this feature with the current API but it would probably require inelegant code to tie things together. It looks like anyway that's what you might have in your current proposal. Would you mind sharing the code somewhere (doesn't have to a clean PR, just enough so that I can figure out the amount of code required).

since we are now heavily dependent on the ordering of the contributors, which feels a bit flaky.

That was my concern and a concern in general for those having a lot of customizations. Feel free to join us on Gitter if you want to discuss this any further. If you have concrete ideas or problem to report in this area, I'd appreciate if you take the time to create a separate issue.