Generate an application with only a few words

[anderskristian]

I'm a huge fan of jHipster. Especially making CRUD applications
I see that jHipster is difficult to maintain and therefore will probably be less maintained.
I see jHipster Lite. Really a great step forward.
I also see that ambitions with jLite seems not to match that classic is running low.

Therefore I have written a little paper on what I like, my concerns and my suggestions.
jLite.pdf

[pascalgrimaud]

Thanks for sharing this @anderskristian
It's a huge work and analysis!

I shared it here: https://groups.google.com/g/jhipster-dev/c/TbxB9A1z3D4

I'll find time to comment some part and give you some of my experience too.

[pascalgrimaud]

@anderskristian : I didn't finish to review all your doc, but here some first feedbacks / comments. Thanks for your analysis.

---

I have added SLUG Neo4j. Now I want to remove it?
◦ In general all SLUG should be reversable.
◦ Excluding init I assume. Init is not reversable.
◦ That means a test can be: Given a SLUG was added. When removed again. Then it must
be gone.

The question is simple:

• What would you do in a real project?
• You need to understand what to remove, then, manually do it (src, test, config, dependencies, etc)
• So here, you have 2 solutions:
  • Do it manually
  • As you used JHLite, you could try to use git and revert the commit

---

I’m upgrading from jLite version V1 to V2
◦ This means that Spring upgrades from X1 to X2
▪ We must make sure that X1 Spring artifacts and generated code is replaced with
what ever X2 has come up with
◦ That also means that SLUG salando-problems has been deleted.
▪ We must make sure that everything from that one will be removed

Same answer:

• What would you do in a real project?
• You can use JHLite to get the git diff and apply the change manually, JHLite can’t guess everything
• You could use OpenRewrite, which is a wonderful tool: https://docs.openrewrite.org/

---

It turns out that V3 has a different view on SLUG consul.
◦ SLUG consul is no longer there
▪ Customers must expect jLite to signal to the developer that consul is unknown and
the developer must read the migration instructions.
• In jLite consult might still be in SLUG list and marked as obsolete?

Not really concerned by this for now, as we are still in a v0.x.x
Then later, we’ll try to not having breaking changes like this, but I would say: as it’s open source, the developers can come and help to write documentation and migration instructions :)

---

Later I applied the SLUG postgresql again.
Result spring.datasource.password was set back to nothing.
I conclude that jLite removes my custom fitting.
I find that that behaviour is not 100 being in control

In your project, you should do a branch, then a merge request, check every diff, and change what you don’t want. So here, you’ll have to update again the spring.datasource.password
It’s not really the goal of JHLite to manage everything like this, it’s the job of the developer

You said it later in your doc:
jLite patching of customers source code must be superviced by developers and owned by
developers. jLite offers superiour tooling for patching.

---

application.properties
We know will be a mix of jLite generated settings and customers own setup.

I know, it can be annoying. A solution would be to have your own application-xxx.properties, with your own customer profile. Thanks for Spring
Working on a genlog / custom fitting + three way merge feature directly in JHLite would be overkill for something a developer can do it easily manually.
So about genlog, it needs to be discussed with other developers in a dedicated issue.

---

I get the concern that JHipster classic will no longer be maintained

I don’t know what to say. It’s open source so it could be maintained by every developer. About me, I stopped contributing simply because I don’t understand the code anymore, so it’s not because I don’t want to, it’s because I didn’t manage to.

---

jLite development process

I discussed it with Julien Dubois, and I’ll create a ticket for that, to try to have something similar to JHipster Online.
Then, my personal opinion would be to not use this kind of process you suggest.
Because, you start to think about technologies, instead of business.
Same answer about JDL. You start to think about modeling the database instead of business. So you’ll build a project which is data centric, which is not good.

---

It is a question of building a “bom” Bill of Material

When I started coding JHLite, I wanted to avoid using a BOM, as it requires too much sync, too much dependency between generator-jhipster and jhipster-bom
If you want to use a BOM, you could code your own maven-java module, in your jhlite-custom project.

---