Define a module value object?

[DamnClin]

Following #1760 and to prepare #1666 and #1565 I think a Module domain object can be a good idea.

A module holds all information for a specific... module in JHipster Lite (example: init, cache, ...). The idea would be to enforce modules invariants, ease modules creation / maintenance and avoid the big ApplicationService (which is a very bad smell).

I gave a try to a build API, ended up with something like that:

Module.forProject(TestUtils.tmpProject())
  .filesFrom("server/springboot/core").to("src/main/java")
    .add("application.properties.mustache")
    .add("IntegrationTest.java.mustache")
    .add("MainApp.java.mustache", "MyApp.java")
  .and().filesFrom("server/javatool/base").to("src/main/java/com/company/myapp")
    .add("Assert.java.mustache")
    .add(""
  .and().javaDependencies()
    //...

The idea will then be to create a domain service using the current ProjectRepository to create a module (this is a first step, the next one would be to move that in a dedicated repository and to delete ProjectRepository)

What do you think of this idea? I give it a try to create a very simple new module (ex: one with a git cheat sheet)?

[pascalgrimaud]

as discussed together with @hdurix @matthieulapatate : we're in a good direction here, as it will simplify a lot all the code in DomainService
So yes let's do it

[DamnClin]

After some iterations the API now looks like this:

moduleForProject(new JHipsterProjectFolder(FileUtils.tmpDirForTest()))
  .context()
    .put("packageName", "com.test.myapp")
    .and()
  .files()
    .add(from("init/gitignore"), to(".gitignore"))
    .batch(from("server/javatool/base"), to("src/main/java/com/company/myapp/errors"))
      .add("Assert.java.mustache")
      .add("AssertionException.java.mustache")
      .and()
    .add(from("server/springboot/core/MainApp.java.mustache"), to("src/main/java/com/company/myapp/MyApp.java"))
    .and()
  .build();

Still not perfect but looks like ti's the best version we got so far :)

[DamnClin]

So a part of it done and starts to be used. Next step seems to be #1787 and we'll then need lots of other thinks (npm dependencies, replacements, etc...). Dunno how you want to handle this particular issue lifecycle

[pascalgrimaud]

@DamnClin : I have some question about the module system here.

I'm working on refactoring the Init context:

• for adding new files, it's OK and it works well
• but I need to launch git init -> https://github.com/jhipster/jhipster-lite/blob/main/src/main/java/tech/jhipster/lite/generator/init/domain/InitDomainService.java#L40

How should I do this?

1st solution:

• improve the module system, so the git init will be launch when calling apply

2nd solution:

• adding a new method gitInit here https://github.com/jhipster/jhipster-lite/blob/main/src/main/java/tech/jhipster/lite/generator/module/domain/JHipsterModulesRepository.java
• calling it from applicationService, as it is used to orchestrate. It could look like:

Any advices?

[DamnClin]

I'll say 3rd solution :) wait for #1787 since I'll have to refactor this part to handle this kind of action and you'll then be able to make a git init. Hopefully I'll work on this tomorrow (unless the weather's too good to stay inside...)

[DamnClin]

cc @pascalgrimaud how do you want to handle this issue lifecycle?

[pascalgrimaud]

increasing the bounty for all the huge work
closing this as it's done

[DamnClin]

Claim https://opencollective.com/generator-jhipster/expenses/84348

[pascalgrimaud]

@DamnClin : approved :)