JHipster v8 release.

[Marcelo Shima]

Hello team.

Happy new year to all.

With the new year I think it’s time to release v8.

If there is not objections, I will be working on v8 in the following weeks.

My plan continue to be the same.

My initial plan was:

- Implement https://github.com/jhipster/generator-jhipster/pull/17131 for better understanding the workflow and api documentation (jsdoc)

- Implement https://github.com/jhipster/generator-jhipster/issues/15490#issuecomment-907788727 so we don’t need a entity-foo for each foo generator.

- Implement https://github.com/jhipster/generator-jhipster/issues/15869, the generated blueprint would be esm and would have the specification of the first 2 steps.

- Start v8 cycle with breaking changes (splitting generators (modularization), reworking file tree, esm migration, properties reworking, and so one).

So as a schedule I propose:

v7.6 in less than 2 weeks

- spring-boot 2.6.

- create entity integration base implementation.

- integrated blueprint generator.

v8 in 6 weeks or so:

- export only esm, so we can migrate to esm during v8 cycle

- requires node 16

- modularize and integrate modular generators

Regards.

Marcelo

[Deepu K Sasidharan]

Hi Marcelo,

I think we should do a team meeting first as we also need to discuss a few other things that have been discussed for a while and prioritize things. Since the changes you proposed are all internal it probably won't make a lot of difference to people who use the generator to create projects and that would make v8 less attractive for them so we also need to think of what user-facing stuff can be in it and what are the things we need to deprecate. 

I personally would also like to discuss the Yeoman situation, since Yeoman is technically being maintained just by you would it make sense to drop it and use the underlying libs directly (prompt etc?) and use inheritance more effectively and get rid of the yeoman lifecycle and stuff? Again you know yeoman much better than any of us so would love to hear your thoughts on this. We might be able to make blueprints easier to use and may even have a different workflow altogether. Ideally, it would be nice to keep breaking changes to a minimum so that current blueprints and modules can update without too much effort.

Thanks & Regards,

Deepu

--
You received this message because you are subscribed to the Google Groups "JHipster dev team" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jhipster-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/1F201161-FB99-40B4-8C61-69323EBB9283%40gmail.com.

[Deepu K Sasidharan]

Btw I agree for your proposal for v7.6

Thanks & Regards,

Deepu

[Pascal GRIMAUD]

Agree with you Deepu.

I'm waiting the result of the survey, so we can decide the direction of the project

No problem for the v7.6, just ping me when the (very hard) migration to Spring Boot 2.6 is ready

Pascal

To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/CAFXry56JCzGVG-oUpdyN9aE%3DS3%3DPthc-Jbc8E6naoGPm4ot0vA%40mail.gmail.com.

[Marcelo Shima]

v7.6 can be released today then. Spring Boot 2.6 should be ready (excluding the mongodb + reactive problem).

v8 will just consolidate all the work we've done to support esm, and modularization.

It doesn’t make sense to implement `create entity integration base implementation` without the v8 plan.

You can see the details at:

https://github.com/jhipster/generator-jhipster/pull/17499

I personally would also like to discuss the Yeoman situation, since Yeoman is technically being maintained just by you would it make sense to drop it and use the underlying libs directly (prompt etc?) and use inheritance more effectively and get rid of the yeoman lifecycle and stuff? 

I am wondering why do you think we need to drop yeoman-generator.

Yes, I am maintaining it. And like many others projects, there are very few contributors.

But its a well stablished project and its use is increasing (700k downloads/week before the holidays)

https://www.npmjs.com/package/yeoman-generator

Just received today from npm:

Hi, mshima!

We recently announced that we are enrolling all maintainers of the top-100 packages by dependents in enforced 2FA on the npm platform. As you are currently a maintainer of yeoman-generator, your account will be required to enroll in 2FA for authentication.

So it’s not a deprecated project.

Regards.

Marcelo.

[MathieuAA]

Hello,

The issue with a project having few contributors is that issues tend not to be solved (or solved after a long time) and be closed (or forgotten). That's why it's something to look when using a new lib or project.
I'd normally say it's great that you Marcelo are the main contributor to yeoman AND one of the main if not the main (I haven't checked) to JHipster, but that's unfortunately a weakness, not a strength because of the "truck/bus/motored-vehicle factor". That, and the possibility that the two projects could be too coupled, which they actually are.

IMO, Yeoman is a huuuuuuge SPOF for JHipster for these very reasons.

As far as the v8 is concerned, a major (breaking change to the API, lots of features, etc.) should be implemented so as to bump to JhV8.
Confusing the user isn't a good idea, especially because we have never bumped to a major version without significant changes.

My 3 cents :)

---

MAA

-------- Message d'origine --------

To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/2D6AEE46-7080-4FBF-8819-B0D29A741238%40gmail.com.

[Charlie Mordant]

Hi committers!

Regarding this roadmap, I agree with the two points of view:

- On one side, consolidating modularization and a 'good framework' basis for Jhipster is also a must have to me: the framework has been harder and harder to maintain due to that lack of brainstorming on sane basis. Also it will pave the way to your commands line jhipster Pascal ;-)

- On the other side, user need a killer feature on each version ;-). Could be native support for most of the combinations no? Or a good native support (we don't have many to many support, clunky one to X, ...). Or a custom vs generated code merge support: side by side, or DDD, or hexagonal... Whatever small feature that will reinsure our users regarding one of their biggest painpoint.

For Yeoman: why changing it? it's really simple piece of stuff: basically a workflow processed by a queue... So to me it's not worth bothering about it, apart if you have a marvelous idea of replacement :-).

If my vote for v8 can : I would move the generator to a strongly typed language in order to get strong contracts on method inputs. We may catch more an more contributors with a well-shaped, extensible, understandable code ;-).

Best regards,

Charlie

To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/HXKs9kbQIePzvnlhsad7CywVsNZ_62BHypESZDf4WpfZiJ6ikCdhxUvaYJ5ay9YvCBPJo2ONUlnpUBQ14izwudU7ArKY0L1-7ou9F0SnEFw%3D%40pm.me.

--

Charlie Mordant

[Pascal GRIMAUD]

Hello,

Sorry but I disagree about 'killer feature' :-)

Why should we add new features instead of taking care of our current options ?

Just have a look at https://github.com/jhipster/generator-jhipster/issues?q=label%3A%22area%3A+stale%22+is%3Aclosed

So much closed tickets without 1 single answer, and that's the problem by adding option which is not used enough.

I wonder if we should remove the auto close on these tickets

Pascal

[Deepu K Sasidharan]

Ya I think autoclose is actually making it look like we don't have many issues when in fact we have a lot without any resolution, so it's just hiding away the problem

To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/CALUG8VtM7SjV-DhdGQ6H8DmqeZE7jpN6w9G7em5Pe2rUf2qF8A%40mail.gmail.com.

[Charlie Mordant]

Agree with you Pascal, The best killer feature would be to have all supported options working without any issue, but this is waaaay too hard to achieve. Your approach for v8 and the according solution brought by Marcello (componentization/modularization) will help: we could then provide a 'degree of integration robustness', or list what's and what's not supported.

And +1 to remove autoclose, it sucks!

--

Charlie Mordant

[Matt Raible]

I'm a little hesitant to say "go for it" with v8, but that's mostly because I plan to start updating the JHipster Mini-Book for v7 in February. :) 

I do like the idea of a cool new feature for v8 and I think Spring Native is a worthwhile goal. However, that should be possible as soon as we're upgraded to Spring Boot 2.6, so I'm not sure we need to wait for v8. Also, there's a good chance native support is built-in by default with Spring Boot 3.0. I've been told there's a milestone release of Spring Boot 3.0 that will be available in the next few weeks.

Related: there's open issues for native support in our Micronaut and Quarkus blueprints that've been unresolved for months. I might try to fix these in the near future.

To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/CANHkoGxjeA07AxJ%2Bv_G3LRwXLEgjuVd0AFPeAGPq%2BzqpkPbvDA%40mail.gmail.com.

[Pascal GRIMAUD]

Ok, I'll remove auto close workflow and reopen all related tickets which didn't have answers

[Pascal GRIMAUD]

So I reopened all tickets, which were tagged with 'area: stale'.

We have a lot of tickets now, which probably needs some triage

Pascal

[Deepu K Sasidharan]

I'll go through some and close what is reasonable

Thanks & Regards,

Deepu

To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/CALUG8VtU0GwpcORPCAfzOKi7vcRskBcPZ-74qK-t1jttJvp0Ww%40mail.gmail.com.

[Deepu K Sasidharan]

I'm removing stale and triage labels from tickets that I looked at so if any of you are triaging just go through open tickets with triage/stale labels

Thanks & Regards,

Deepu

[Frederik Hahne]

Sorry for getting this back from the dead :D Do we have a roadmap for v8 somewhere? Do we plan to have team meeting on this? I was just asked if there is something by Andreas from devoteam.

[Deepu K Sasidharan]

Unfortunately nothing yet. I guess we could revive what we missed for v7 to v8. There are few things on my wishlist (was in v7 as well but there wasn't much interest)

1. I would love to shed some weight on JHipster (I mean remove features that are not widely used) it would make it easier to maintain at the very least

2. Simply templates by moving any logic to js files

3. Remove multiple config files and use JDL as single source of truth for app, blueprints and entities. This IMO would simplify our codebase and make it easier for blueprints and stuff. We might have to maintain backward compatibility until v9 to see benefits though

4. Enhance JDL from blueprints

I would also love to hear from others about their wishlist

To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/2bbdb895-10e7-4655-a6c3-46af7ebc8772n%40googlegroups.com.

[Charlie Mordant]

Hi buddies!

Not sure we can do everything that I have in mind, but still, here's my wishlist.

How about creating a whishboard on github (a "project") and discus each one there?

** Customer facing**

- Client side:

1. Adding sort on each framework - TOP3

2. add filters on the form's list headers when the relative option is selected (useful for 70% of all the projects I know ^^)

- Server side

1. finish the testcontainer thing :-)

** DSL**

- JDL

1. Remove the skip* option in favor of the inclusive variables and reasonable default (according to RFC)=> BREAKING - TOP3

2. Add CRUD choice on each entity to activate or deactivate each option: I noticed that many entities do not need full CRUD all the time

3. Add conditional option at each layer, for each entity (createForm, listForm, deleteForm, FrontService, ITests, UnitTest, RestController, repository, liquibase)

4. Add messaging-oriented entity option that can complete list: 'consumer X with kafka', 'provider Y with rabbit'.

5. Allow multiple entities to have the same name but used in different microservice

6. Removing the 'microservice B with secondMS' in favor of using the entities that are specified in an application (the 'entities' section): this one is quite confusing. Entity should also be automatically included if there's only one gateway.

7. 'Side by side' option...

 - Options

1. Use incremental-changelog by default

2. May: Use the liquibase-maven-plugin instead of specific generation for compliant application configuration (more bullet proof)

3. May: use swagger to generate the controller and the DTOs instead of our custom templates

** Generator architecture **

1. For sure, pursuing the 'blueprintization' of the main generator by splitting everything into their dedicated modules/packages

2. Respecting SOLID, DDD principles for all methods and splitting them into dedicating files: I propose to have a dedicated folder in each subgen as well as at the root that will contain 'java-like architecture, with single responsibility classes' for business logic: I'm pretty pissed off having business logic in 'generator-base-private.js' that mixes up git operations, sql jdbc helper, webpack things, ... Ok to keep this file as a facade, but every method should call one or more classes/files.  - TOP3

3. Typescript may help for 2.

I hope that you'll all agree that these suggestion are going in the right way.

Best regards,

To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/CAFXry561rSJjvXqg5rX7GkjQ%3DmkH2DWN0TMJWDRoiVOGx%3Dqgzg%40mail.gmail.com.

--

Charlie Mordant

[Daniel Franco]

Hello,

I started to review the issues (looking from the old first) and tagged some of them as v8, so it will be easier to list what was postponed from v7.

Then we can define if they are still valuable to v8 and discuss new requests.

Do we have any news from the Tech board?

Thanks

Regards,

Daniel Franco

To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/CANHkoGzTOyjWKUvxet04m-AP5GggEbaaao1%2BzCKc2Qv%2Beb0fPw%40mail.gmail.com.

[Julien Dubois]

Hello,

Yes, maybe it’s time to do another tech board gathering (but this should be opened to more people so we get as many ideas and opinions as possible). Many of the ideas from the survey were taken into consideration for JHipster Lite, but then where are we going with JHipster v8? That’s a huge concern.

On my side, and to be fully transparent, I believe we should evolve JHipster Online, so that the CRUD part (with the JDL Studio) could work both for JHipster and JHipster Lite - and even any Spring Boot application that uses Web + JPA! I think this is our main selling point, and it could be much more generic than what we currently have, and become even more popular.

I’ll try to find a date in June, I guess that’s good for everyone? For people in Europe, we could even do something physical in Paris.

Julien

To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/CADVdDoa7Xeaup5BSkcW9r%2BcZUbsJNj7kQZ498DOz%3DNLmr_EhOg%40mail.gmail.com.

[Matt Raible]

Please let me know if there’s anything I can do to help with planning v8. My biggest desires for v8 are microfrontends (mostly done already) and GraphQL (can likely be done as a blueprint). Since both aren’t tied to v8, I can support with reviews and manual testing.

I’m also trying to get a new version of my JHipster Mini-Book finished. It will target v7.

I'll be on vacation from June 17 - July 24, but happy to travel to Paris outside of that. ;)

Cheers,

Matt

To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/BE46AE5F-16A2-4327-84B0-04C2F518D0A4%40gmail.com.

[Julien Dubois]

We could do end of June or beginning of July?

I will have a look next week, once DevoxxUK is done.