Create multiple module Maven project

[cthiebault]

In case of big projects, it would be nice if the generated Maven project was splitted in multiple module project. Something like:

• -core
• -rest
• -angularjs-client

[jdubois]

I am not sure this would ease development:

• Multi-module Maven projects are always cumbersome to work with
• Technical layers (core/rest/angularJS) are already separated in the project (they are in separate directories)

[yesnault]

It allows incremental compilation with Jenkins for example. Admittedly, this can be a little cumbersome at first, but in development teams with dozens of developers and millions of lines of code, it is almost essential.

[jmirc]

The only issue I can see is related to jhipster-reloaded and how it will be able to find the type of the class to reload. This is a point for improvement.

[NicolasGeraud]

It could be a nice option if you want to share your core application with some spring batch.

[jdubois]

Our build is getting so complex, with so many options, that I doubt we can do it.

[cthiebault]

I started my application from JHipster and split it in several modules. It works well but I don't use the hot reload stuff...

[puskai]

+1

[ivan4github]

A suggestion to simplify the problem for you, the jhipster team: Once build with with the magic "yo jhipster", a project is generally splitted afterwards by hand in several modules.

The issue is to continue to benefit from the wonderful "yo jhipster:entity myNewEntity", despite the new module organization.

Could not it be a matter of saying somewhere in the src/main/resources/config/application-dev.yml, where to put the generated java (rest side) and where to put the generated web stuff (angular side) ?

I know that we will loose the ability to update jhipster blind eye on an existing project, but we are so happy with the creation template that we cannot have everything.

[jdubois]

We are going to merge the Gradle support soon... I'm new to Gradle, but I think it will make this even more complicated. Anyway, I don't see a solution for "hot reload" if we have a multi-module project, and that's really a blocking issue. I see your points, and I know a lot of people like multi-projects (even if I don't personally), but I really doubt this is do-able.

[jdubois]

This can't be done if we want to keep the "hot reload" and "Gradle" options, which are more important to me.

[eallais]

Because Gradle and "Hot reload" are not recommended anymore since 1.9.0. It would be possible to reconsider to have a multi-module JHipster project? The update of JHipster version is very difficult and the ability to have a maven module with all the specific code should be a sensible option.

[gzsombor]

+1

[jesus-mata]

+1

[hmpatel]

+1. It definitely makes sense now to re-instate the direction of having multi-module JHipster projects since Gradle and Hot reload (which were the root causes earlier) are no longer recommended. Multi-Module projects are the de-facto standard across enterprises when using Maven.

[francescou]

+1

[ghost]

+1

[abreu-dev]

+1

[wzomer]

+1

[phstudy]

+1

[mspasiano]

+1

[imilic1]

+1

[abreu-dev]

I think that https://github.com/spring-io/sagan is good example of a multi module project

[svennela]

Multiproject and multiservers. just like below repo..:) +10

https://github.com/dsyer/spring-security-angular/tree/master/double

[DavidMCook]

+1

[jdubois]

Thanks for all the feedback: I'm not a big fan of multi modules in Maven, and I'm afraid it's going to be annoying for Eclipse users (which I am not, but I still care for them!!), so this is clearly not in the top of my todo list. Still, I don't think we have anything blocking this anymore (excepting that it's a lot of work!), so this could be an option at start up.

[andrezimmermann]

I use multi modules in Maven in Eclipse, I find it easy to use as a single module project. I get the benefit of using multiple threads to compile the projects, so that's :+1: for me.

[yarix]

:+1: +1 i think that for projects that are more than simple POC, working in multi project is nearly a must. in my example i would need to have multiple REST (micro)servers and just single "back-offilce" GUI. with jhipster I'll have to deploy and run the full solution in every server. i would like to have the following projects

1. Domain module - Jpa, repositories, liquibase etc.
2. Rest WebApp module - this module should be able to run as standalon boot application.
3. Admin WebApp GUI - the front end. this module should be able to run as standalon boot application
4. common services module - optional module
5. All in One module - optional module that will pack the REST and Admin web apps to single boot application (in different servlets or different ports). this is ideal for development, testing and POC.

[PeterEltgroth]

I inherited numerous multi-module builds for some reasonable large projects, but have converted most back to single module builds as they were not complex enough to justify a multi module build. Consequently, I am dubious a multi module build would be beneficial to the majority of users, but I will bow out of the discussion as I'm using gradle.

[jdubois]

@PeterEltgroth I have the same experience as you, and I find multi-module projects are a bad idea. Then, if people want them, and that's just an option in the generator, that's fine with me. My issue here is that it looks like a big refactoring, so that might be too complex to be done, but I haven't tried it yet, so this needs to be tested first.

[danielwinter83]

Hi, I'm just beginning to explore jhipster but it looks really very promising to me. But for me I immediatly think that frontend and backend should be optionally splittet in different modules/projects. Basically I want to host the frontend on other servers than the backend APIs...that's in general why I would like the ability to split it into multiple modules.

[soffoalbert]

I agree with you Daniel.

On Wed, Jun 3, 2015 at 5:59 AM, Daniel notifications@github.com wrote:

Hi, I'm just beginning to explore jhipster but it looks really very promising to me. But for me I immediatly think that frontend and backend should be optionally splittet in different modules/projects. Basically I want to host the frontend on other servers than the backend APIs...that's in general why I would like the ability to split it into multiple modules.

— Reply to this email directly or view it on GitHub https://github.com/jhipster/generator-jhipster/issues/204#issuecomment-108183000 .

[gzsombor]

It seems that everybody wants to split the project differently - which would be nearly impossible to support :wink: Anyway, you can easily put your frontend code - the html and javascript into one apache server, or on a cdn, and have the backend served from other servers.

[jdubois]

@gzsombor yes a lot of people want this, yet I don't understand why! For me multi-modules have always been annoying to use, didn't really split the project in "modules" (this is just for building), and people never understood how to use those effectively (most people don't understand how they work).

Besides, it goes against the idea of doing "micro services" with JHipster -> my current goal would be to add something like the Netflix OSS stack to JHipster, so we could have several smaller JHipster apps talking together. That would be a much cleaner way of splitting a big JHipster app.

So, as I've said earlier, this is at the very bottom of my todo list.

[deepu105]

I agree with @jdubois to an extend. In my initial days as a developer i have worked on some huge enterprise applications with multiple modules for an airline client and personally it was annoying as it made my work more complex, the goal was to use same business logic layer for webservice, web and batch. Build was ant though which would package everything into an ear. Then i guess in the end its almost similar to what you want achieve in maven. But nowadays with spring boot and lot of javaconfig the complexity of integrating all these together has reduced and personally i would also prefer a single module than having all those config repeated

[jmirc]

I agreed with you. I did a presentation last month on Netflix OSS using JHipster with micro-services and each service had his own module including JHipster. I don't really understand why JHipster should be split in two different modules. I would like to understand the cases and the motivation for this.

[danielwinter83]

maybe I'm missing the point here. I was thinking for load balancing reasons. The API could run on multiple instances with a load balancer in front. The UI would reside maybe an another instance(s) and access the API-load balancer. I just thought decoupling the client from the API would make sense.

[gzsombor]

I've also saw enterprise multi module system, which was so wrong, that it even had circular references, so the first, clean build failed always :wink: But otherwise the modularization could help enormously :

• so you can be sure, that if you change something in one module, it doesn't affect anything to an unrelated module.
• Or you don't accidentally write a code in web layer, which rely on some implementation detail from the service layer.
• you can reuse part of the application in a safe way, imagine a 'jhipster' application, it has services, hibernate entities, rest interfaces. If you have an API module for the DTO-s, an implementation-module for the entities, and for the services, and a web module for the spring REST interfaces, you can easily create :
  • Android client, or a command line admin tool - you just use DTO-s from the API module - with apache HttpClient and a jackson, and you are done. This will be a small jar, as it wont include every spring/web dependencies
  • Batch processing / background application: with the API and the impl module you can access the full database directly, and can use some other dependencies (for example a reporting engine, or a pdf generator tool) which you would want to add to your web frontend.
  • etc
• Of course, there could not only horizontal, but vertical modularizations as well - so for example you have 'product management app' and a 'customer management app', which shares some code, but you dont want to deploy both to the same server.

I can accept, that if you are working on a one-men project, then most of time, you wouldn't need modularization at all, but after you have more than a couple of hundreds classes in your project, it could easily become messy and confusing.

[raehalme]

@gzsombor +1 I think the (previously mentioned) movement towards microservices even more emphasizes on these points!