Next steps for JHipsterModule

[DamnClin]

The whole module thing was started around this idea #1666, another very important goal was to have a better contributor experience.

We now have a module mechanism doing some stuff and most of JHLite features are now modules. Time to think a little bit about that!

Do we really have a better contributor experience? I can't tell, I'm too much biased on that... @pascalgrimaud @SoniaLahi @Bolo89 @sstan001 @wmarques @antarus @DanielFran @fdelbrayelle @qmonmert you did some contribution using the new module mechanism. How was the experience? Does it feel any better?

Now for the hierarchy part. There seems to be 2 important notion:

• Dependencies (like in any dependency management, modules will have dependencies to other module or feature) ;
• Feature: a feature is a functional scope, ex: client. The idea is to avoid adding Angular and React in the same app (or maven and gradle), that doesn't make any sense.

Knowing that, we will probably be able to build a graph and, from that, a landscape screen, a wizard mode screen, automated tests generation to go through the whole graph, etc...

Another important thing that we are asked is the possibility to add external modules (so a module description API and to be able to apply them in JHLite).

So, that's the plan if we stick to the module thing but there is (at least) another plan: drop the modules. The plan here is not to drop the module concept but to drop modules as they are (or tend to be) now: a description of what should change. In that plan, we go back to a more sequential definition of the modules (closer to the one we had before). The main goal would be to remove some "magic" from the module mechanism and to ease understanding for new contributors.

We can also drop half of the current mechanism: we drop JHipsterModule but keep JHipsterModuleResource to get the screen for free (but a lot of "magic" comes from that...).

There are probably lots of other plan for the next step for JHlite, don't hesitate to write them down here

[wmarques]

The Dev experience on my side was really good. In a few minutes I was able to migrate some code.
The modularity is a very good point but I think the "dependency tree" feature will be mandatory :)

I definitely vote to keep it !

[antarus]

it seems simpler to me than before although I had not yet contributed on jhipster-lite.

I think that for the rest it also depends on the purpose of jhipster-lite...

Currently it's modular, you can apply the modules in the order you want and it works (at the delta that some modules remain mandatory and their order of application too)

Personally, I always initiate my new projects with the generator-jhipster and I refactor... but, now, if I want to do hexagonal and ddd this solution seems complicated to me.

What I particularly like in the generator-jhipster is the JDL but it is not ultra adapted to the DDD and the generator-jhipster does not generate hexagonal architecture.

So I wonder
Is the long-term objective to generate from a DSL a complete application and the entities?
Shouldn't Jhipster-lite remain modular and another "application" manage the orchestration (dependency between modules, dsl,..)?
Other ?

[DamnClin]

Is the long-term objective to generate from a DSL a complete application and the entities?

Depends who you ask I guess :D. It's not mine but perhaps somebody gonna want to do it. (I know there are expectations for that #2446)

Shouldn't Jhipster-lite remain modular and another "application" manage the orchestration (dependency between modules, dsl,..)?

I don't know, I think having the possibility to built a module graph and to add external modules can be really great since companies would then be able to host there own JHLite instance with there custom modules. Allowing that is a really good way to get cool contributions on the "mains" generator

[pascalgrimaud]

Adding a feature, using the module system is easier than at the beginning of JHLite, thanks for the hard work @DamnClin.

Adding a feature in JHLite: doable
Adding a feature in generator-jhipster: impossible for me today. As I already said several times, I didn't understand the yeoman generator anymore, that's my pain point and that's the reason I started to code this project last summer.

To answer to you @antarus, about the entities generator: as you already said, it's not really adapted, because if you start to think about entities first, it's the opposite of DDD
An simple idea would be to:

• create a JDL
• use it with JHipster Lite
• it will generate the entities + jpa repository
• you'll need to code yourself the domain

[antarus]

yes an entity generator is not suitable for DDD but we can perhaps model the domain to be generated

Application myApp {
     config {
          package com.test
    }
    Module routing {
        ValueObject MyObject {
            Description description 
            String property
            List<String> list
        }
        ValueObject Description {
           String description
       }
       Entity MyEntity {
            'Name of my entity'
            String name 
            MyObject myObject

            Repository MyEntityRepository {
                findAll;
                findByName;
            }
        }
        Service MyEntity {
            findAll => MyEntityRepository.findAll;
        }
}

We may not be able to generate everything, but maybe we can reduce the classes

But your wokflow is simpler than mine... and it is certainly more realistic ;D

[sophie-stan]

I remember I did not have too much trouble understanding how to use the modules, and how to contribute. Overall, it has been a pleasing contribution.

[pascalgrimaud]

Thanks for sharing your dev experience @sstan001
It's really important :-)