Replies: 10 comments 2 replies
-
|
Hi @assimbly, Thanks for sharing your experience.
I agree with you, and it has always been one of the biggest problem of JHipster. I'll share you my own experience in real JHipster projects, to help you upgrading your JHipster application.
About JHipster Lite, which is completely different from generator-jhipster. For the moment, I'm the only one from the core team to code on JHipster Lite, as it is still an experimental project. I started it for a lot of reasons -> https://docs.google.com/presentation/d/1i0LOJ0GSWNG2-x0zY220IbQc0PVQ2pndQWEuQKGu8n0 As you mentioned, JHipster Lite helps you to generate step by step, only the code you need. Nothing more.
About JHipster v8. It is still in discussion. Honestly, we don't have a clear roadmap, as we need to discuss about the future of the project generator-jhipster. Our code is too complex, IMO, and we don't have new contributors since months. For me, JHipster Lite and generator-jhipster (JHipster v8) are 2 separated and different projects. |
Beta Was this translation helpful? Give feedback.
-
|
I want to start a fairly big project (Spring Boot/React/MongoDB) and will evaluate On topic, you brought a lot of good points about:
Possibly It's worth to do it like this and then right away upgrade the code when a new release arrives. When Unfortunately, I did exactly the opposite and put my custom code everywhere in between (only avoiding the needles). Probably a separate section with a guide how to develop custom code after This could also be accompanied by a tutorial where these various constructs are explained and can be explored by user in practice. At the end there is much value in upgrading (maybe even more than generating), because I also know Git is used for the upgrade process, I don't know however if there are GIT constructs to do this smarter. For Keep up the good work. |
Beta Was this translation helpful? Give feedback.
-
|
I thought about this discussion a bit more. I think that software, that revolves around evolution, needs a shift in thinking. Currently, like the JHipster project, most things are focused around the birth of an application. JH Lite also includes the first baby steps. But is it possible to consider the complete life cycle? To offer a solution that guides app creators during the complete lifecycle of that application? Mostly people, when starting a project, think about the setup, the functionality and the requirements. They don't think years ahead about refactoring (because there is nothing to refactor yet), upgrading and phasing out stuff. But maybe we can think for them, maybe a bit opinionated, but a framework that will guide developers/creators to make the right decisions that help them later on in the lifecycle. It's a bit like Object-Orientated programming, but then not on a programming level, but on an application level. The modules that make up such an application could be called micromodules. Micromodules An easy birth would generate a minimal application which is lean and mean and has a just enough approach. From there on, the application can be enhanced with a kind of code blocks (just like Lego). These so-called micromodules exist in isolation. For Jhipster this could be for example:
Thus, developers can decide to add the health page, but not the log page. Or added them both, and remove one of those pages later on during its lifecycle. In this sense, all parts are isolated modules that you can be used as Lego blocks to build and rebuild the application. Currently, developers use libraries or frameworks to enhance an application without coding every functionality themselves, but these are technological focused, where most people want to enhance their application more functionally (like adding a tool to their OS, a plugin to their IDE). This has always an approach of low-code platforms (like Outsystems or Mendix), but these are all proprietary and miss the unified and endless flexibility of a (high-)code approach. Lifecycle actions The lifecycle actions of such micromodules can be:
At the end, it is about the lifecycle and modularity of software. Looking at the complete lifecycle, the emphasis shifts much from new/add towards evolving (change/extend/rename/refactor/update/upgrade/remove/phase out). Embracing modularity The path towards a more modular approach and a higher abstraction level has always been part of software engineering. From Assembly language to C, from C to Java (OO) and from Java to Kotlin for example. Where new programming languages and new versions of a language introduce better constructs to build software. There are now several interesting projects (outside Jhipser Lite itself) that embrace modular software development within the Java world:
The evolution of languages brought us new constructs to build applications. However, building web applications made it much more complex, because now we have a stronger separation between backend and frontend. Often backend and frontend are written in totally different languages and need to use all kind of frameworks (like Spring Boot, Quarkus, React, Angular) to make web development really efficient. All of these technologies lead to the situation that there are so many languages/frameworks that must be learned. This is the practice of a full-stack web developer... Most of the time the backend will be something else than JavaScript/TypeScript/CoffeeScript (like Java, PHP, C#, Python, Ruby) when building a large application. In a sense, Kotlin is the most promising as a cross-platform unified language, which also can be used to build full-stack web applications: Then you can have both the backend (language & framework), the frontend (language & framework) and build system (Gradle/Kotlin) @pascalgrimaud You may share this discussion with the dev team (on Google Groups). I am wondering what the other devs think about this subject... Also, this discussion is much broader than the Jhipster Developer Survey can show (as the survey is mostly targeted at technology, not on what the end goals of app creators are). |
Beta Was this translation helpful? Give feedback.
-
|
Though somewhat old, this discussion on Quora also fits here: https://www.quora.com/Is-using-JHipster-in-complex-projects-a-good-idea |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @assimbly for sharing your suggestions. You have a lot of good ideas, but there is a main problem: we (all contributors) are not a company, we work during our freetime, so it will be impossible to go so far, like you suggested. JHipster is still an Open Source project ;-) Some people don't want to use it in complex projects. Ok, I'm fine and I don't care too much about their use. About your lifecycle list:
I plan to manage only the create part in JHipster Lite. |
Beta Was this translation helpful? Give feedback.
-
|
Resources Focusing on the “Create” part is fair, but every step, even during generation, that will make the lifecycle thereafter easier will have a positive effect on the development process. Even small changes putting the projects in the right direction (whether it's JHL or JH8) would make a huge difference. And JHL is already on that path. When the number of resources are limited, one could focus for example only on the top 3 choices. For example backend "Spring Boot/Quarkus/Micronaut", frontend "Angular/React/Vue", databases "SQL/MongoDB/Cassandra" etc. The outcome of the survey will be a good guide for which one. Other options to add can be left to the broader community. Also, we could ask the developers/experts of the frameworks themselves to look at the generated code. They can conclude one of the following:
Whatever it would be, Jhipster would benefit from this. The value of an excellent example implementation should also be of high value for those frameworks as well, considering the high number of usage of JHipster. Less is more For now, and not only for Jhipster Lite, but also for JH8 the key will be "less is more":
With new changes, the question should be: "could this makes it easier for users? Does this make the generated code easier to read? Does it make the generated code easier to upgrade? I think that especially Deepu has an exceptional compass on these matters. In general, you see that projects either emphasize on technical excellence or functionality. This means either they have a wonderful architecture and can outperform other projects, but on the other side they don't offer much value, while other projects focus very much on functionality, making the software usable and valuable. It seems the emphasis was in JH8 too much on the latter. On the dev group you wrote on Jhipster Lite" “- it took me 10sec to launch 1 single command and 3 minutes to write the Tweet, so, it's a total of 3min for a new release
That’s pretty impressive, and I hope some improvements and ideas flow into JH Generator as well. Bringing technology and functionality more in balance. Upgrading Currently, upgrading Jhipster to a higher version feels like this: "Hey, I want to go from Paris to Rome, I know somewhat the direction, so I just start travelling". This is an exciting journey, but I don't know the exact route and distance. When will I arrive? How far is it still? Am I on the right path? Some (more) ideas:
One could put all the project information in a jhipster-project.json file. This file contains all the chosen options (which kind of application, package name, database and so on. This means the exact project could regenerated just based on this file (even when the version is different). When creating an application from CLI or GUI (online) this file could be generated. Later this file can have use for upgrading (come back to this later).
Another thing that could make it easier, is to make the generated code less dependable on the name of the application. That means either:
Though I admit that using these names also have their upsides (it’s clear that it’s Jhipster and may avoid conflicts) in general I would like to avoid it. The code from my generated application should be exactly the same as another vanilla project. An outsider couldn’t even tell if it was generated or not.
The third thing is that parts work in isolation as much as possible (api-driven). Thus, I can replace one module/package with another version without consequences (or at least I would only need to fix any API calls). An upgrade script All in all, for my situation, I will create a json file with various project information. Within this file, I will put all modules/packages and add if they are default Jhipster or customized. For each part, then I can decide to delete/replace/skip/merge a module/package as whole. This is opposite to the more file based approach of upgrading Jhipster and because this is ‘tracked’ by this project file I don’t need to answer those questions every time I upgrade. Then I create a Gradle script that upgrades may project accordingly. Later I may do some fancier stuff with Git. Thanks for this discussion. I will put a link to my upgrade solution when it's finished. |
Beta Was this translation helpful? Give feedback.
-
|
Last update on upgrading: I recently upgraded from Jhipster 6.8 to 7.7. Based on the issues I had before and the above discussion, I created a Gradle/Groovy upgrade script. This script does the following:
While this surely not the most solid way, it gives me fine-grained control over what to do. Because the answer are in the JSON file, it doesn't ask me again with every upgrade. It also generates a small report with files to check. The first upgrade from 6.8 to 6.9 took still a week, but that last one to 7.7 just an hour (while keeping all custom code). This I did eventually like that I upgraded using Jhipster (instead of performing upgrades of dependencies separately), because:
I do run into some issues:
I do think Jhipster and Jhipster Lite could benefit from its own 'linter'. For example, one that checks:
I also think it would benefit to use "generated names" based on the project names, at least as possible. For example Keep it generic. Theoretically with this approach I could take another project and just drop a certain module in my own. Thus, I have two generated apps: Then I would be possible just to use a module from app1 in app2 and vice versa (because the code is exactly the same when it's generated with the same version). Last, but not least, a big benefit will be to make a very clear where a developer can put his custom code as separate from the default generated code. Also, on Jhipster Lite there is not a lot of documentation about this yet, but you may focus first on features first :) A sidenote: Because of the API-Driven way of Jhipster Lite, it could really benefit from a nice user interface (create a mockup in Jhipster online --> jhipster/jhipster-online#343). There will be really no difference between running Jhipster Lite local or online. |
Beta Was this translation helpful? Give feedback.
-
|
Here a short update on the above discussion: One of the technologies that is used a lot for upgrades is OpenRewrite (https://docs.openrewrite.org/). Though there aren't any recipes for Jhipster yet (Only one for a patch https://docs.openrewrite.org/recipes/java/jhipster) , a lot of the submodules (Spring, Quarkus etc) already have support. Because you can combine recipes this is technology that can help in evolving Jhipster generated software in a similar approach without the need of a lot of manual upgrades. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, it's probably doable. @atomfrede : just saw you started to have a look on this -> https://github.com/atomfrede/open-rewrite-for-jhipster-lite-sample |
Beta Was this translation helpful? Give feedback.
-
|
@pascalgrimaud Indeed I setup a sample for using openrwrite within jhipster lite, in particular e.g. for adding gradle dependencies etc. instead of doing it ourselfs. It didn't work out as expected on first try, but I am in contact with the open rewrite team (we met at jcon last week) and hope I'll find a solution for that (still hope I am using it wrong or so as using it inside a simple gradle project does not work either). Will keep you updated when I have some more details. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks a lot :-) |
Beta Was this translation helpful? Give feedback.
-
|
If it works out nice, we could also gradually use it e.g. for manipulating the maven pom, but first the gradle part :D |
Beta Was this translation helpful? Give feedback.
-
Hi devs,
I have a Jhipster based project (https://github.com/assimbly/gateway) and I'm using Jhipster since version 4. Since then, Jhipster became a big and extensive project. I like that Jhipster Lite tries to keep it lean and mean, and its modular approach. Here I like to start a discussing on how JHipster can be used for evolving software.
Evolving software
In many things, like creating an application or a new entity, Jhipster is of great help. Jhipster Lite focus also on adding modules afterwards. In general, I think it's good to focus to make it possible to evolve software.
Evolving software is the most important thing into keep software up-to-date with new dependencies and functionality. This makes it possible to use a code base longer. Evolving software has everything to do with:
For me, this has always been the biggest pain point for JHipster. I generated my application only once, but after it's hard to keep up. Creating happens once, upgrading and refactoring hundreds of times, but it's hard to reconcile with the custom code added after generating the application.
Personal experience
A lot of project teams are scared to perform upgrades. It's hard and takes a lot of time. In my experience, upgrading my Jhipster application during the default way, totally breaks the application. The first time (upgrading to version 5) I did it by fixing all the errors manually. Which were a few thousand. The second time (upgrading to version 6), I just started from scratch and then apply my custom code afterwards.
Every time I was very satisfied afterwards, because the latest JHipster was more stable, looked better, had all the latest dependencies, code was better organized and so. However, the burden of upgrading became too heavy. From version 7, I don't use JHipster at all anymore...
Now, in practice, I moved towards upgrading dependencies manually on my own and migrating manually to a new version of a specific framework. These upgrades happen numerous times of the course of the lifetime of a software project and cost a lot of work.
Because my project is small, and Jhipster has so many dependencies, I would like that it would do it for me. This would make it so much better to evolve the software, keep all the dependencies up-to-date (by following the main branch) and also enjoy security updates, last best practices and other improvements done by the JHipster team.
I already asked/pointed this out in discussion with Julien years ago, and more recently in a StackOverflow:
https://stackoverflow.com/questions/69162416/whats-the-best-strategy-for-updating-an-jhipster-application
I hope that easily upgrading while retaining custom code more easily would be a thing that JHipster takes into account more and more.
Is it possible?
I would like to discuss how evolving a JHipster could be done with Jhipster (instead of using it only for generating code). Some ideas are:
What would you think, and how can Jhipster Lite / Jhipster 8+ improve this?
Beta Was this translation helpful? Give feedback.
All reactions