Release v6.9.0 / start v7 ?

419 views
Skip to first unread message

Pascal GRIMAUD

unread,
Apr 17, 2020, 1:09:10 PM4/17/20
to JHipster dev team
Hi team,

What do you think about a new release of generator-jhipster v6.9.0 ?
It will contain:
- Reactive support, which has been improved a lot
- Test Containers for SQL database (PR in progress)
- CircleCI support back
- tons of bug fix

Maybe I forgot some items ? Don't hesitate to tell me, it will be used in the patch note.

Do you think it should be the last release of v6 ?
Should we start the v7 in master, and create a v6.x_maintenance ?

Pascal

Matt Raible

unread,
Apr 17, 2020, 1:35:43 PM4/17/20
to Pascal GRIMAUD, JHipster dev team
Huge +1!

I’m not sure it makes sense to say it’s the last v6 release. I think there’s still a lot to do for v7 and that could take a while.

--
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/CALUG8VuLC0FeYKPNrNJr14nhCQX581k7pXuecUMP5mhS0xdqzA%40mail.gmail.com.

Daniel Franco

unread,
Apr 17, 2020, 3:45:58 PM4/17/20
to Matt Raible, Pascal GRIMAUD, JHipster dev team
+1 for me too.
Maybe wait for April 26th for last update spring-boot 2.2.7

For v7 we could have spring-boot 2.3

Deepu K Sasidharan

unread,
Apr 17, 2020, 4:14:11 PM4/17/20
to Daniel Franco, Matt Raible, Pascal GRIMAUD, JHipster dev team
+1 for v7, we can still do release from maintenance branch for spring update IMO

Pierre Besson

unread,
Apr 17, 2020, 5:29:15 PM4/17/20
to Deepu K Sasidharan, Daniel Franco, Matt Raible, Pascal GRIMAUD, JHipster dev team
+1 to start the work on v7 !

Aurélien Mino

unread,
Apr 18, 2020, 5:45:29 AM4/18/20
to Matt Raible, Pascal GRIMAUD, JHipster dev team
I agree with Matt.

For example Spring Boot 2.3 is due next month, and will e.g. include non-experimental support for Spring Data R2DBC.
It might be interesting to be able to release a new v6 release with SB 2.3 if its ready, and not have to wait for all the v7 work to be finished.

mathi...@free.fr

unread,
Apr 19, 2020, 6:15:49 AM4/19/20
to Aurélien Mino, Matt Raible, Pascal GRIMAUD, JHipster dev team

Julien Dubois

unread,
Apr 19, 2020, 8:36:24 AM4/19/20
to Mathieu Abou-Aichi, Aurélien Mino, Matt Raible, Pascal GRIMAUD, JHipster dev team
Hi everyone!

I think we should indeed continue a bit with v6.x, at least to have Spring Boot 2.3. But we could start v7 in parallel, and to be honest it's time to start building something new.

Again, I believe this new version should be the occasion to simplify everything that we generate *from a user perspective* -> people complain a lot that what we generate is too complex, and that it's hard to upgrade. If we simplify what is being generated (for example, thanks to using our Java and Typescript libraries), we will have the same result as of today, but it will appear a lot easier and simpler to new users. I see this as Spring Boot or Quarkus: they are extremely complex under the hood, but most people don't look under the hood, so they have the impression of something simple.
This is also part of our move from a generator to a platform.

BTW, last month was the first time our BOM was downloaded more than 100,000 from Maven Central, which shows how popular this approach is. I was the first one doubting about this, but the data proves me wrong: we have a ton of users and 0 complaints!!

Julien Dubois



--
Julien Dubois

Twitter: @juliendubois

Deepu K Sasidharan

unread,
Apr 20, 2020, 10:53:46 AM4/20/20
to Julien Dubois, Mathieu Abou-Aichi, Aurélien Mino, Matt Raible, Pascal GRIMAUD, JHipster dev team
Yes, no one has complained so far about this approach, for v7, let's identify and move more stuff into the front end and backend libs, we should have already done that, better late than never

Thanks & Regards,
Deepu


Pierre Besson

unread,
Apr 20, 2020, 11:40:49 AM4/20/20
to Deepu K Sasidharan, Julien Dubois, Mathieu Abou-Aichi, Aurélien Mino, Matt Raible, Pascal GRIMAUD, JHipster dev team
Yes we know exactly in which direction we need to go but I'm afraid that we have too few resources for big changes. Right now, few people on the core team can dedicate more than a couple of hours of work to JHipster every week. And It's not just my feeling, this is validated by our Github Code Frequency graph (https://github.com/jhipster/generator-jhipster/graphs/code-frequency). On the graph, almost every year, we have had periods of "burst" of activity. This is no longer happening from the end of 2019, beginning of 2020 (I'm talking about generator-jhipster).

So I think we need to be more realistic about the "roadmap" and maybe we need financial investment in developer time through the association or more sponsoring by companies (which have people without work to do right now !). We are in a global crisis and some developers are desperate to find work, they won't come naturally to JHipster if we don't make the effort to bring them to the project. I think the Association has a role to play here to coordinate resources, maybe open larger bounties/grants that can motivate companies to invest time in JHipster's development.

Best regards,
Pierre

Matt Raible

unread,
Apr 20, 2020, 2:22:48 PM4/20/20
to Pierre Besson, Deepu K Sasidharan, Julien Dubois, Mathieu Abou-Aichi, Aurélien Mino, Pascal GRIMAUD, JHipster dev team
I agree with Pierre. In the past, when we’ve had major releases, 1-2 folks have stepped up and done a tremendous amount of work. In fact, those same folks don’t contribute as much now — I suspect because of burnout and because they have other responsibilities now. 

Maybe we should specify an MVP for JHipster 7 and start there? Looking at https://github.com/jhipster/generator-jhipster/issues/10958, there seems to be a lot of technical debt, and only a few new features.

New features are:

1. Vue.js in main generator
2. Side-by-side sub-generator
3. Change default db to PostgreSQL
4. Format Java code with Prettier

Merging Vue doesn’t seem terribly difficult. However, the issue seems to be bogged down with a desire to restructure everything. That doesn’t seem necessary for an MVP since refactoring can happen between minor releases as long as it doesn’t affect the generated output.

I’m not sure a side-by-side sub-generator has been started. It sounds like a lot of work and I don’t know that we’ve had much demand for it. People seem to like the pattern, but I’m not sure how widely used it is.

Changing to PostgreSQL is easy, I believe.

Formatting Java with Prettier is already done, I think.

There’s another new feature that’s not listed here: reactive support. I tried creating a microservices architecture this weekend and was disappointed to find that using MongoDB and Couchbase are really the only database options. The entity generator doesn’t work for Neo4j or r2dbc. And Cassandra doesn’t have pagination support. 

I spoke with Josh Long about how excited I was for JHipster reactive and he yawned. His take: it took us two years from when WebFlux was released to implement it. This made me realize why the Spring folks aren’t that enthused about JHipster: we’re too slow to implement the stuff that they’re exited about. The natural response is they should help us, but I think we all know they have plenty to do without helping us.

Let’s look at the rest of the breaking changes listed:

* Remove dirty keys - seems like more of a bug fix than a breaking change.
* JHipster sidecar app - this could require significant work. I’m not sure it’s necessary, especially since it replaces JHipster Registry and will likely cause a lot of problems and confusion. It’ll likely break all the existing microservice tutorials and videos out there. It might be better if it was simply created, but it didn’t replace JHipster Registry.
* Remove .yo-rc and .jhipster and use JDL - seems like a lot of unnecessary work since we’ll have to retrain all our users to post their JDL instead of their `.yo-rc.json`. Changing CI to use JDL doesn’t seem that hard.
* Standardize JDL options to use `none` rather than `no` or `false`. Seems easy to do, but could cause a lot of support and maintenance for existing tutorials or sample JDLs that use the old options.
* Deprecate applicationType option. Seems major. Whoever wants to do this should step up, take ownership of it, and write the code for it. Otherwise, let’s drop it.
* Make front-end apps first-class citizens. I’m not sure why we need this since a JHipster frontend can’t exist without a JHipster backend. I’d rather see microfrontend support and I’m willing to do the work for that.
* Make serviceDiscovery=eureka non default for microservices. Why? Would consul become the default? If there’s no Eureka, how do apps talk do each other? I don’t think we want to get into the business of writing our own service discovery. AFAIK, Eureka is not deprecated by Spring Cloud. This change will also break all existing microservice tutorials, books, and videos.
* Modulith support. Who wants this? Are you willing to step up and do the work to make it happen? We should drop it if no one wants to invest the time.
* Server-side package by feature. This is a good idea IMO, but I’m not sure it’s necessary since it’s a 5-minute refactor in your IDE. Anyone want to take this on?
* Zuul to Spring Cloud Gateway - this work is done, but both options exist. I’m not sure we should remove Zuul. At the very least, we should ask our community. And not just on Twitter because I think that only represents 10% of our developers. Maybe we should leverage the emails in JHipster Online and send out a survey?
* Ribbon to Spring Cloud Loadbalancer. Why is this needed? Is someone willing to do the work?
* Hystrix to Resilience4J: same as above.
* Rename package to tech.jhipster. I’m not sure this is needed, but it doesn’t seem hard, just tedious. 
* Remove Java 8 support. I don’t think this is necessary, especially since we’re not even leveraging Java 11 in any code.
* Migrate from Springfox to Springdoc. I like Springdoc, but Swagger 3 seems to work with its snapshot versions. Maybe we should offer some $$ to the Springfox project to get it released?
* Remove getAllJhipsterConfig - seems easy enough, but I think it’s break our mobile modules, and possibly others. Jon Ruddell and I can probably fix the mobile modules if/when it is removed.
* Improve client/server generators workflow. This seems like it can be done behind the scenes, as long as it doesn’t change the outputted code. Anyone willing to do this work?
* Remove or change audits. Audits have caused issues in my 21-Points app, but I don’t think removing them will make my problem go away. It happens when generating primary keys for other entities too. I’ve changed all entities to use UUIDs instead  but I’m hesitant to merge the code. I’d be willing to add UUID support to JHipster as this seems like a better alternative. 
* Remove and deprecate the JHipster Console. Seems easy enough. What should folks use instead? Is there a similar app you can run locally to show people pretty graphs in demos?
* Remove Dropwizard metrics dependency. I believe we’re using Micrometer so this shouldn’t take long. I could be wrong.

If I search for “jhipster opencollective”, the second result is “How JHipster’s Bounty System saved the project”. This is telling. Can it continue to save the project? I believe it can.

We have ~12K in our bank account today. I’d like to propose we spend 10K on making JHipster 7 happen.

Of the issues above, who is passionate about making them happen? If you’re not willing to do it for free, what’s the $$ amount that would make you motivated?

Thanks,

Matt

Frederik Hahne

unread,
Apr 20, 2020, 2:56:58 PM4/20/20
to jhipst...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Regarding the 6.x and start of 7 series, let's have sb 2.3 in normal 6.x
release cycle. I think it makes it easier to maintain that branch in
the long run.

See some of my thoughts regarding Matt's points underneath.
In general there should be a clear goal what we do for 7 with a more
clear roadmap, so Matt's idea of a mvp sounds quite good to me.

On 4/20/20 8:22 PM, Matt Raible wrote:
> I agree with Pierre. In the past, when we’ve had major releases,
> 1-2 folks have stepped up and done a tremendous amount of work. In
> fact, those same folks don’t contribute as much now — I suspect
> because of burnout and because they have other responsibilities
> now.
>
> Maybe we should specify an MVP for JHipster 7 and start there?
> Looking at
> https://github.com/jhipster/generator-jhipster/issues/10958, there
> seems to be a lot of technical debt, and only a few new features.
MVP sounds really nice. At least it would help me a lot to know where
to invest my time.
>
> New features are:
>
> 1. Vue.js in main generator 2. Side-by-side sub-generator 3. Change
> default db to PostgreSQL 4. Format Java code with Prettier
>
> Merging Vue doesn’t seem terribly difficult. However, the issue
> seems to be bogged down with a desire to restructure everything.
> That doesn’t seem necessary for an MVP since refactoring can happen
> between minor releases as long as it doesn’t affect the generated
> output.
We could also keep vue as a blueprint for now to keep the maintenance
burden lower for the main generator.
>
> I’m not sure a side-by-side sub-generator has been started. It
> sounds like a lot of work and I don’t know that we’ve had much
> demand for it. People seem to like the pattern, but I’m not sure
> how widely used it is.
>
> Changing to PostgreSQL is easy, I believe.
>
> Formatting Java with Prettier is already done, I think.
>
> There’s another new feature that’s not listed here: reactive
> support. I tried creating a microservices architecture this weekend
> and was disappointed to find that using MongoDB and Couchbase are
> really the only database options. The entity generator doesn’t work
> for Neo4j or r2dbc. And Cassandra doesn’t have pagination support.
>
Do you mean entity for normal applications or for reactive
applications with neo4j? Do you have a pointer whats missing as the
new neo4j boot integration was designed with reactive in mind, so it
should work.
Let me know what issues you have.
> for that.Do we have made a decision what our goal for micro
> frontends is?
Looking at the approach I favor and e.g. single spa, they are quite
different with single spa (i think) clearly the easier one to
implement for us.
> * Make serviceDiscovery=eureka non default for microservices. Why?
> Would consul become the default? If there’s no Eureka, how do apps
> talk do each other? I don’t think we want to get into the business
> of writing our own service discovery. AFAIK, Eureka is not
> deprecated by Spring Cloud. This change will also break all
> existing microservice tutorials, books, and videos. * Modulith
> support. Who wants this? Are you willing to step up and do the work
> to make it happen? We should drop it if no one wants to invest the
> time. * Server-side package by feature. This is a good idea IMO,
> but I’m not sure it’s necessary since it’s a 5-minute refactor in
> your IDE. Anyone want to take this on?

Basically these two are somehow going together. Package by feature is
"required" to follow modulith approach. I still like the idea and
would like to invest time havin a modular architecture which is backed
and enforced by tests.

> * Zuul to Spring Cloud Gateway - this work is done, but both
> options exist. I’m not sure we should remove Zuul. At the very
> least, we should ask our community. And not just on Twitter because
> I think that only represents 10% of our developers. Maybe we should
> leverage the emails in JHipster Online and send out a survey?
I think we wanted to do that some time ago, but at least from gdpr
point of view it is not easy as we did not get consent before.
> * Ribbon to Spring Cloud Loadbalancer. Why is this needed? Is
> someone willing to do the work? * Hystrix to Resilience4J: same as
> above.
I work with Resilience4J and would like to have a look. Already had
contact with the maintainer, so in case of problems (I doubt there
will be some as it is the proposed spring boot solution I think)
Robert can help.
> * Rename package to tech.jhipster. I’m not sure this is needed, but
> it doesn’t seem hard, just tedious. * Remove Java 8 support. I
> don’t think this is necessary, especially since we’re not even
> leveraging Java 11 in any code. * Migrate from Springfox to
> Springdoc. I like Springdoc, but Swagger 3 seems to work with its
> snapshot versions. Maybe we should offer some $$ to the Springfox
> project to get it released? * Remove getAllJhipsterConfig - seems
> easy enough, but I think it’s break our mobile modules, and
> possibly others. Jon Ruddell and I can probably fix the mobile
> modules if/when it is removed. * Improve client/server generators
> workflow. This seems like it can be done behind the scenes, as long
> as it doesn’t change the outputted code. Anyone willing to do this
> work? * Remove or change audits. Audits have caused issues
> <https://stackoverflow.com/questions/47880068/duplicate-key-value-viol
ates-unique-constraint-pk-jhi-persistent-audit-event-w>
> in my 21-Points app, but I don’t think removing them will make my
> problem go away. It happens when generating primary keys for other
> entities too. I’ve changed all entities to use UUIDs instead
> <https://github.com/mraible/21-points/pull/58> but I’m hesitant
> to merge the code. I’d be willing to add UUID support to JHipster
> as this seems like a better alternative. * Remove and deprecate the
> JHipster Console. Seems easy enough. What should folks use instead?
> Is there a similar app you can run locally to show people pretty
> graphs in demos? * Remove Dropwizard metrics dependency. I believe
> we’re using Micrometer so this shouldn’t take long. I could be
> wrong.
>
> If I search for “jhipster opencollective”, the second result is
> “How JHipster’s Bounty System saved the project
> <https://blog.opencollective.com/jhipsters-bounty-system-and-how-it-sa
ved-the-project/>”.
>
>
This is telling. Can it continue to save the project? I believe it can.
>
> We have ~12K in our bank account today. I’d like to propose we
> spend 10K on making JHipster 7 happen.
>
> Of the issues above, who is passionate about making them happen?
> If you’re not willing to do it for free, what’s the $$ amount that
> would make you motivated?
>
> Thanks,
>
> Matt
>
>> On Apr 20, 2020, at 9:40 AM, Pierre Besson
>> <pierre....@gmail.com <mailto:pierre....@gmail.com>>
>> wrote:
>>
>> Yes we know exactly in which direction we need to go but I'm
>> afraid that we have too few resources for big changes. Right now,
>> few people on the core team can dedicate more than a couple of
>> hours of work to JHipster every week. And It's not just my
>> feeling, this is validated by our Github Code Frequency graph
>> (https://github.com/jhipster/generator-jhipster/graphs/code-frequency
).
>> On the graph, almost every year, we have had periods of "burst"
>> of activity. This is no longer happening from the end of 2019,
>> beginning of 2020 (I'm talking about generator-jhipster).
>>
>> So I think we need to be more realistic about the "roadmap" and
>> maybe we need financial investment in developer time through the
>> association or more sponsoring by companies (which have people
>> without work to do right now !). We are in a global crisis and
>> some developers are desperate to find work, they won't come
>> naturally to JHipster if we don't make the effort to bring them
>> to the project. I think the Association has a role to play here
>> to coordinate resources, maybe open larger bounties/grants that
>> can motivate companies to invest time in JHipster's development.
>>
>> Best regards, Pierre
>>
>> On Mon, Apr 20, 2020 at 4:53 PM Deepu K Sasidharan
>> <deepu.k.s...@gmail.com
>> <mailto:deepu.k.s...@gmail.com>> wrote:
>>
>> Yes, no one has complained so far about this approach, for v7,
>> let's identify and move more stuff into the front end and
>> backend libs, we should have already done that, better late than
>> never
>>
>> Thanks & Regards, Deepu
>>
>>
>> On Sun, Apr 19, 2020 at 2:36 PM Julien Dubois
>> <julien...@gmail.com <mailto:julien...@gmail.com>>
>> wrote:
>>
>> Hi everyone!
>>
>> I think we should indeed continue a bit with v6.x, at least to
>> have Spring Boot 2.3. But we could start v7 in parallel, and to
>> be honest it's time to start building something new.
>>
>> Again, I believe this new version should be the occasion to
>> simplify everything that we generate *from a user perspective* ->
>> people complain a lot that what we generate is too complex, and
>> that it's hard to upgrade. If we simplify what is being generated
>> (for example, thanks to using our Java and Typescript libraries),
>> we will have the same result as of today, but it will appear a
>> lot easier and simpler to new users. I see this as Spring Boot or
>> Quarkus: they are extremely complex under the hood, but most
>> people don't look under the hood, so they have the impression of
>> something simple. This is also part of our move from a generator
>> to a platform.
>>
>> BTW, last month was the first time our BOM was downloaded more
>> than 100,000 from Maven Central, which shows how popular this
>> approach is. I was the first one doubting about this, but the
>> data proves me wrong: we have a ton of users and 0 complaints!!
>>
>> Julien Dubois
>>
>> Le dim. 19 avr. 2020 à 12:15, <mathi...@free.fr
>> <mailto:mathi...@free.fr>> a écrit :
>>
>> +1!
>>
>> Le 18 avr. 2020 11:44, Aurélien Mino <aureli...@gmail.com
>> <mailto:aureli...@gmail.com>> a écrit :
>>
>> I agree with Matt.
>>
>> For example Spring Boot 2.3 is due next month, and will e.g.
>> include non-experimental support for Spring Data R2DBC. It might
>> be interesting to be able to release a new v6 release with SB 2.3
>> if its ready, and not have to wait for all the v7 work to be
>> finished.
>>
>> On Fri, Apr 17, 2020 at 7:35 PM Matt Raible
>> <ma...@raibledesigns.com <mailto:ma...@raibledesigns.com>> wrote:
>>
>> Huge +1!
>>
>> I’m not sure it makes sense to say it’s the last v6 release. I
>> think there’s still a lot to do for v7 and that could take a
>> while.
>>
>> On Apr 17, 2020, at 11:08 AM, Pascal GRIMAUD
>> <pascal....@gmail.com <mailto:pascal....@gmail.com>>
>> wrote:
>>
>> Hi team,
>>
>> What do you think about a new release of generator-jhipster
>> v6.9.0 ? It will contain: - Reactive support, which has been
>> improved a lot - Test Containers for SQL database (PR in
>> progress) - CircleCI support back - tons of bug fix
>>
>> Maybe I forgot some items ? Don't hesitate to tell me, it will be
>> used in the patch note.
>>
>> Do you think it should be the last release of v6 ? Should we
>> start the v7 in master, and create a v6.x_maintenance ?
>>
>> Pascal
>>
>> -- 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
>> <mailto:jhipster-dev...@googlegroups.com>. To view this
>> discussion on the web visit
>> https://groups.google.com/d/msgid/jhipster-dev/CALUG8VuLC0FeYKPNrNJr1
4nhCQX581k7pXuecUMP5mhS0xdqzA%40mail.gmail.com
>>
>>
<https://groups.google.com/d/msgid/jhipster-dev/CALUG8VuLC0FeYKPNrNJr14n
hCQX581k7pXuecUMP5mhS0xdqzA%40mail.gmail.com?utm_medium=email&utm_source
=footer>.
>>
>>
>>
>> -- 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
>> <mailto:jhipster-dev...@googlegroups.com>. To view this
>> discussion on the web visit
>> https://groups.google.com/d/msgid/jhipster-dev/8BDB8953-3090-4759-A84
D-27C9E8F88CBE%40raibledesigns.com
>>
>>
<https://groups.google.com/d/msgid/jhipster-dev/8BDB8953-3090-4759-A84D-
27C9E8F88CBE%40raibledesigns.com?utm_medium=email&utm_source=footer>.
>>
>>
>> -- 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
>> <mailto:jhipster-dev...@googlegroups.com>. To view this
>> discussion on the web visit
>> https://groups.google.com/d/msgid/jhipster-dev/CACXN3_gbb3VTEcd1PFV-4
44sdWgUEGVy%3DoMAywbn2_byhanjgQ%40mail.gmail.com
>>
>>
<https://groups.google.com/d/msgid/jhipster-dev/CACXN3_gbb3VTEcd1PFV-444
sdWgUEGVy%3DoMAywbn2_byhanjgQ%40mail.gmail.com?utm_medium=email&utm_sour
ce=footer>.
>>
>>
>>
>> -- 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
>> <mailto:jhipster-dev...@googlegroups.com>. To view this
>> discussion on the web visit
>> https://groups.google.com/d/msgid/jhipster-dev/a76e786d-dafc-471c-af2
b-a38051df9eb7%40email.android.com
>>
>>
<https://groups.google.com/d/msgid/jhipster-dev/a76e786d-dafc-471c-af2b-
a38051df9eb7%40email.android.com?utm_medium=email&utm_source=footer>.
>>
>>
>>
>> -- Julien Dubois
>>
>> Twitter: @juliendubois <http://twitter.com/#!/juliendubois>
>>
>>
>> -- 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
>> <mailto:jhipster-dev...@googlegroups.com>. To view this
>> discussion on the web visit
>> https://groups.google.com/d/msgid/jhipster-dev/CADNXADGor2Tpbe8PgH10s
0WZszxXO3HNxefuR-Mo%3D9eB6dsMbQ%40mail.gmail.com
>>
>>
<https://groups.google.com/d/msgid/jhipster-dev/CADNXADGor2Tpbe8PgH10s0W
ZszxXO3HNxefuR-Mo%3D9eB6dsMbQ%40mail.gmail.com?utm_medium=email&utm_sour
ce=footer>.
>>
>>
>> -- 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
>> <mailto:jhipster-dev...@googlegroups.com>. To view this
>> discussion on the web visit
>> https://groups.google.com/d/msgid/jhipster-dev/CAFXry55C-rkfnu%2BatWi
OYn-%2BKb9%2BteJcuh8xG972n6Jvye6gAw%40mail.gmail.com
>>
>>
<https://groups.google.com/d/msgid/jhipster-dev/CAFXry55C-rkfnu%2BatWiOY
n-%2BKb9%2BteJcuh8xG972n6Jvye6gAw%40mail.gmail.com?utm_medium=email&utm_
source=footer>.
>>
>
> -- 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
> <mailto:jhipster-dev...@googlegroups.com>. To view this
> discussion on the web visit
> https://groups.google.com/d/msgid/jhipster-dev/8469E7E6-B3B3-48FA-A194
- -0C9F563BADC0%40raibledesigns.com
>
>
<https://groups.google.com/d/msgid/jhipster-dev/8469E7E6-B3B3-48FA-A194-
0C9F563BADC0%40raibledesigns.com?utm_medium=email&utm_source=footer>.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE5wKhRPm9hGEZmys4m4lX4DKXpcUFAl6d8HIACgkQm4lX4DKX
pcU8sg//TeXSQtU2Gp3+D3Xj4r108ItP7iLdGrhGt4UIqiW0WDcrxs/SO6QjRkdw
WZQbfkNOPSDimDv1TkDG8V3iYkHU7uJMh7RUd8C0q9stx5FwefuzP/5QURpyb5bH
7lL9WpTSb9auYU/FYutl3vwXY7zBv72QWMQj9nMiR/20jrt8mbl8UqMQf+4U7VtA
bArRTxRHSUNxEEEzNlUfPSerIig76lWl2dwM2rFuLU1g+6cuwVwRSEyhQWCVTOLk
9LjkWRmpZOn0XzuHvJMa12g2QnpdXNMiN3W1oolJWoi/Dy1wUHZIJSGjF9srItBQ
KNBPn5y+Qg0pU7s4me7yZnQLtp5qscHu2M1DwtMWf5JeSqPTtB+HciEaCC/umB6t
+ndggQAWJD8RxqE6CjiWOJx1WECPZ2Qy30+sD0cV7bi5Z+2B7Du6ZIVlMF2rlhi8
/J96Z6ptuQajmvVa2xbDniKnldLE1dmRsGI3YUBR3BIA5926HgnOHOx0mtINKJ6h
DaSU5O5QW1Q+o2+k4GPeq97u8yLn4C9D0QsNHgEzT8i652noXf6bT/mGZg2/Ky6P
tgCkwyUX5ifYjFTeh4eLUjhFK/dGzHGiBcuHWb9Qya679xknVW4pxI8ekDBiiVzu
pUWUimZQLAKTABYsjqyM3aTHTqD6gxZX4aXPUuJhZGyxWPGnGuA=
=os7n
-----END PGP SIGNATURE-----

Julien Dubois

unread,
Apr 20, 2020, 3:06:46 PM4/20/20
to Frederik Hahne, JHipster dev team
Regarding paying developers using the association (or directly from OpenCollective, that's something to decide): I'm waiting a little bit to have more information about JHipster Code, but then indeed we would have the money to pay some people full time on the project, and that could make a difference. I know some core contributors might soon look for a job, that could be a good option for everyone.

Julien Dubois

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/966c333e-f0aa-ee93-655c-8c9cb8deb617%40gmail.com.

Marcelo Boveto Shima

unread,
Apr 20, 2020, 8:44:13 PM4/20/20
to JHipster dev team
+1 to release v6.9.0 as it is and start v7.
Maintenance should continue on v6 branch.
This will break a lot of blueprints/modules.
It’s in the official documentation.

* Improve client/server generators workflow. This seems like it can be done behind the scenes, as long as it doesn’t change the outputted code. Anyone willing to do this work?

Matt Raible

unread,
Apr 21, 2020, 12:44:48 AM4/21/20
to Frederik Hahne, jhipst...@googlegroups.com

<snip>


There’s another new feature that’s not listed here: reactive
support. I tried creating a microservices architecture this weekend
and was disappointed to find that using MongoDB and Couchbase are
really the only database options. The entity generator doesn’t work
for Neo4j or r2dbc. And Cassandra doesn’t have pagination support.

Do you mean entity for normal applications or for reactive
applications with neo4j? Do you have a pointer whats missing as the
new neo4j boot integration was designed with reactive in mind, so it
should work.
Let me know what issues you have.

For reactive applications with neo4j. Here’s the JDL I tried to use:

application {
  config {
    baseName gateway,
    packageName com.okta.developer.gateway,
    applicationType gateway,
    authenticationType oauth2,
    databaseType neo4j,
    devDatabaseType neo4j,
    prodDatabaseType neo4j,
    enableHibernateCache false,
    reactive true,
    searchEngine elasticsearch,
    serviceDiscoveryType eureka,
    testFrameworks [protractor]
  }
  entities Blog, Post, Tag, Product
}

application {
  config {
    baseName blog,
    packageName com.okta.developer.blog,
    applicationType microservice,
    authenticationType oauth2,
    databaseType couchbase,
    devDatabaseType couchbase,
    prodDatabaseType couchbase,
    enableHibernateCache false,
    reactive true,
    searchEngine elasticsearch,
    serverPort 8081,
    serviceDiscoveryType eureka
  }
  entities Blog, Post, Tag
}

application {
  config {
    baseName store,
    packageName com.okta.developer.store,
    applicationType microservice,
    authenticationType oauth2,
    databaseType mongodb,
    devDatabaseType mongodb,
    prodDatabaseType mongodb,
    enableHibernateCache false,
    reactive true
    searchEngine elasticsearch,
    serverPort 8082,
    serviceDiscoveryType eureka
  }
  entities Product
}

entity Blog {
  name String required minlength(3),
  handle String required minlength(2)
}

entity Post {
  title String required,
  content TextBlob required,
  date Instant required
}

entity Tag {
  name String required minlength(2)
}

entity Product {
  title String required,
  price BigDecimal required min(0),
  image ImageBlob
}

relationship ManyToOne {
  Blog{user(login)} to User,
  Post{blog(name)} to Blog
}

relationship ManyToMany {
  Post{tag(name)} to Tag{post}
}

paginate Post, Tag with infinite-scroll
paginate Product with pagination

microservice Product with store
microservice Blog, Post, Tag with blog


The error I get is:

Found the .jhipster/Blog.json configuration file, entity can be automatically generated!

events.js:187
      throw er; // Unhandled 'error' event
      ^

Error: The entity generator doesn't support reactive apps with databases of type neo4j at the moment
    at Environment.error (/Users/mraible/dev/generator-jhipster/node_modules/yeoman-environment/lib/environment.js:284:40)
    at EntityGenerator.error (/Users/mraible/dev/generator-jhipster/generators/generator-base.js:1551:18)
    at EntityGenerator.validateReactiveCompatibility (/Users/mraible/dev/generator-jhipster/generators/entity/index.js:240:26)
    at Object.<anonymous> (/Users/mraible/dev/generator-jhipster/node_modules/yeoman-generator/lib/index.js:751:25)
    at /Users/mraible/dev/generator-jhipster/node_modules/run-async/index.js:25:25
    at new Promise (<anonymous>)
    at /Users/mraible/dev/generator-jhipster/node_modules/run-async/index.js:24:19
    at runLoop.add.once.once (/Users/mraible/dev/generator-jhipster/node_modules/yeoman-generator/lib/index.js:752:11)
    at processImmediate (internal/timers.js:439:21)
Emitted 'error' event on EntityGenerator instance at:
    at Immediate.<anonymous> (/Users/mraible/dev/generator-jhipster/node_modules/yeoman-generator/lib/index.js:791:20)
    at processImmediate (internal/timers.js:439:21)
INFO! App: child process exited with code 1

Deepu K Sasidharan

unread,
Apr 21, 2020, 4:35:06 AM4/21/20
to Matt Raible, Frederik Hahne, JHipster dev team
Hi Matt,

You indeed make some excellent points and yes, unfortunately, most of the stuff listed for v7 are tech debts(Even among things you listed as new features, only side-by-side is really new). It is true that previous versions we had more enthusiasm in driving features (I was one of them I guess who ended up burning out and now we have a lot of new blood in the core team who seems to be doing a great job and honestly when I want to code something I don't even find anything interesting to work on that is not already picked up by someone)

Maybe instead of focusing on adding new features just for the sake of doing so, we could focus on making JHipster a truly rapid application development platform that supports multiple backends and frontends. This would mean
  • Restructure docs to showcase the official backends like .Net, Nodejs, Kotlin, Micronaut, Quarkus and so on and make sure these work well with the frontends we have
  • Like Julien mentioned yesterday, move more code onto frontend/backend libs (Maybe even aggressively) to reduce the boilerplate we generate, because "we generate a lot of code" is still a criticism people use to dismiss JHipster
  • Promote JDL first approach for everything

Regarding deprecating .yo-rc and entity json, that's something I wanted to do for a while. You are right that for end-users it might not be very useful but it will greatly simplify our codebase and workflows I believe. For v7 I think we should at least start using JDL for managing all configurations and deprecate the json files used today with backward compatibility so that we can remove them in V8, this way end users wouldn't be affected and it gives ample time for users to start getting used to it as well. I can do the refactor on the generator side for that and I hope Mathieu will help with the JDL part.

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/E5024ECD-6F36-43A0-9182-399A2A38FA89%40raibledesigns.com.

Julien Dubois

unread,
Apr 21, 2020, 5:25:02 AM4/21/20
to Deepu K Sasidharan, Matt Raible, Frederik Hahne, JHipster dev team
Big +1 for what Matt and Deepu said.

We also need to work on JHipster Online, we have a ton of people using it and we should push it forward.

We need to have a look at paying some of us full-time for this: we have the money, and we can probably find more if we look for it.

Julien

Sendil Kumar N

unread,
Apr 21, 2020, 7:05:15 PM4/21/20
to Julien Dubois, Deepu K Sasidharan, Matt Raible, Frederik Hahne, JHipster dev team
+1 on Whatever Matt & Deepu said. 

I am also more inclined towards clearing the technical debts that we have and concentrate more towards the blueprints and update JHipster Online,  JHipster.tech. 

We can experiment the boilerplate code reduction with something like `jhipster lite`. 

Thanks
Sendil 

Matt Raible

unread,
Apr 24, 2020, 3:52:01 PM4/24/20
to Frederik Hahne, jhipst...@googlegroups.com
Comments below regarding micro frontends and our package name.

On Apr 20, 2020, at 12:56 PM, Frederik Hahne <frederi...@gmail.com> wrote:

Let’s look at the rest of the breaking changes listed:

* Make front-end apps
first-class citizens. I’m not sure why we need this since a
JHipster frontend can’t exist without a JHipster backend. I’d
rather see microfrontend support and I’m willing to do the work
for that.Do we have made a decision what our goal for micro
frontends is?
Looking at the approach I favor and e.g. single spa, they are quite
different with single spa (i think) clearly the easier one to
implement for us.


This is the approach I hope to try soon:


* Rename package to tech.jhipster. I’m not sure this is needed, but
it doesn’t seem hard, just tedious.

I’m not sure we should do this as it doesn’t really buy us anything. Also, Facebook thinks it’s a malicious link in Messenger. I reported it, but I was still surprised to find this.

Matt Raible

unread,
Apr 25, 2020, 11:41:35 AM4/25/20
to Frederik Hahne, jhipst...@googlegroups.com
OMG, so annoying! It happened again with a FB comment this morning. 🤬

I'm willing to donate jhipster.org! Or maybe just use it to redirect requests. 😊



On Apr 24, 2020, at 13:51, Matt Raible <ma...@raibledesigns.com> wrote:

Comments below regarding micro frontends and our package name.
<Screen Shot 2020-04-24 at 1.45.23 PM.png>

Julien Dubois

unread,
Apr 26, 2020, 3:32:15 PM4/26/20
to Matt Raible, Frederik Hahne, jhipst...@googlegroups.com
Hey Matt,

Are you sure it won’t happen with a .org? How can we better understand the cause of this issue?

Julien

--
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.

Matt Raible

unread,
Apr 26, 2020, 3:47:44 PM4/26/20
to Julien Dubois, Frederik Hahne, jhipst...@googlegroups.com
I’ve tested jhipster.org and I was able to send it in a message on Facebook. However, when I checked it at https://developers.facebook.com/tools/debug/, it says it contains a blocked URL. Maybe because it redirects to jhipster.tech? It could also be because it doesn’t use HTTPS. It says jhipster.tech is blocked and I’ve reported it as a mistake (a couple of times now).

On Apr 26, 2020, at 1:32 PM, Julien Dubois <julien...@gmail.com> wrote:

Hey Matt,

Are you sure it won’t happen with a .org? How can we better understand the cause of this issue?

Julien
Le sam. 25 avr. 2020 à 17:41, Matt Raible <ma...@raibledesigns.com> a écrit :
OMG, so annoying! It happened again with a FB comment this morning. 🤬

I'm willing to donate jhipster.org! Or maybe just use it to redirect requests. 😊

<image0.png>

Charlie Mordant

unread,
Apr 26, 2020, 8:37:02 PM4/26/20
to Matt Raible, Julien Dubois, Frederik Hahne, JHipster dev team
Hi everyone,

I may have an unpopular opinion, but still, it's the place and the time to express it.
Disclaimer, I've been an Eclipse Modeling Developer for 5 years, and still alive, even enjoying the paradigms I learned :-).

I think that JHipster get a thing already, and generates really cool stuff.
However, I always find it difficult to include contributions into JH, and I think it is even harder for blueprint.

If we want to focus on contributivity (JH.net, JHQuarkus, Jdl studio and friends), reduce debt and make 'jhipster lite' things, I think that it is the time to make the DSL 'Industrial' and contribution friendly by having the generator-jhipster itself being in the form of blueprints, backed by a smarter framework to contribute.

The good:
A very big part is already here in the the jhipster-core part, which really looks like an EMF metamodel.

The thing to focus IMHO is to implement a generation framework:

- We always have things like 'if option.elastic == true and relationship == manytomany' then ...' and it's everywhere in our template:
  -> It's bond to our core options
  -> It's vendor specific
  -> It's not contribution friendly at all: to add a new compatible technology (for example a JOOQ blueprint + elastic), you have to copy the service template, remove what you don't want (Hibernate and neo4j) and add your integration (JOOQ), plus contribute to your blueprint file.js .
  -> Templates tend to be bigger and bigger, harder and harder to read, to understand and to not break: when I work on an elastic contribution:
      ==> I don't want to see neo4j <%if else%> conditions...
      ==> I don't know were elastic contribs are in the vue and react code (really, I just know angular at the time writing)

=> We could have a really smarter approach using the good patterns we all know (aspects, factories, IOC, visitors, template) at the generator level.

Let suggest something (can be completely different and refined in a github ticket), the goal being to have an idea of what I mean:

- Let's abstract our templates:
Repository Jhipster-core or generator-core

abstract class JavaClassTemplate extends FileGenerationActivity {

@override
run() {
generate(getTemplate ()); 
}

getTemplate() {
<%_ importDeclaration().run() _%> 
<%_ class-comments().run() _%>
<%_ pre-class().run() _%> 
<%_ class-definition().run() _%>
<%- for ( field in fields ) { -%>
<%_ pre-field(field).run() _%>
<%_ field(field).run() _%>
<%- } -%>
}
importDeclaration(): ImportGenerationActivity;
...
}

- Let's introduce the concept of activity (which can be composed of tasks):

Repository: java-generator

 JavaEntityImportsTemplate extends ImportGenerationActivity {

run() {
generate(getTemplate ())
postGenerate();
}

getTemplate () {
<% javaLangImports %>
<% for (persistenceProvider in persistenceProviders) { %>
<% for (entityImport in entityImports()) { %>
import <% entityImport().run() %>;
<% } %>
<% if (hasOneToOne) { %>
<% for (oneToOneImport in oneToOneImports()) { %>
import <% oneToOneImport().run() %>;
<% } %>
<% } %>
<% } %>
...
  }

postGenerate() { // in ImportGenerationActivity :-)
this.sortImports();
}
}

- Let's create the concept of Java entity
class EntityTemplate extends Composer<JavaClassTemplate> { // will call 

import-declaration(): ImportGenerationActivity => new JavaEntityImportsTemplate();
}

and finally the hibernate blueprint (in its own repo):

hibernate extends PersistenceProvider  {
PersistenceProviderOption(): String {
  return "hibernate";
}
 entityImports(): List<String> {
   - org.hibernate
}

oneToOneImports()...
}

The overall being used by our beloved End user models:
application { ... }
entity { ... }


Advantages:
- Implements Inversion of control at the generator level with Composers (Who remembers the good old beans.xml files :-))
- Infinite contributivity
- Templates will be more easy to read
- Micro-generators (like microservices but for generators) using a common API/contract being the activities (at the definition level, as well as at the generation level)
-> with maturity, we can even imagine true microgenerators, for example: generator-core being extended by (java-generator-core and persistence-generator-core) being extended by hibernate-java-generator
- Four basic concept for every contributor: template, model, activity, composer
- Thin blueprints, which I hope will increase the amount of contributions: contributors will only specify the bare minimum when implementing their activities and templates, at least for standard ones: others will have to define their own activities and composers
- Strong typing: breaking change will easily be detected (you won't implement the good activities), and will be at an atomic level (ex: entityImports() method renaming). However, they will be more frequent, so we should do a smart 'cookiecutter'-like blueprint template project template in order to have fix reactivity from the contributors

Drawbacks:
- keeping everything readable won't be easy
- breaking change for every existing blueprint and module

Finally, once we have this framework:

- split the actual generator content into blueprints: angular, vue, react, elastic, hibernate, ...
- generator options embedded in their own module
- discoverability of options at runtime (using models to define module linkage, an high level activity or module scanning).
- celebrate our platform modeling framework that can easily accept small and large contributions \o/.


I think that we can't do that entirely for V7, but announcing blueprint/module API breaking changes between V7 and V8 could be a thing.

best regards,



--
Charlie Mordant

Frederik Hahne

unread,
Apr 27, 2020, 2:18:10 AM4/27/20
to JHipster dev team
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

I agree our templates are not very easy to understand.
I think Deepu once said it, we have outgrown yeoman by far.
Maybe it is time to look at larger scale approaches (I did work with
EMF during university a lot).

Maybe what could be a first step towards easier templates and better
modularization is to keep our templates smaller. I have found recently
we have

* EntityRepository
* EntityReactiveRepository

which helps a lot (and it imports other templates, so it very small).

While looking e.g. CacheConfiguration or AccountResource the templates
are very large and hard to understand. If we would have e.g. templates
tailored for redis, hazelcast with common parts that are imported (or
oauth, jwt, no user management templates) it might help already, but
of course it is also a breaking change.

best regards

Fred
> <mailto:ma...@raibledesigns.com>> a écrit :
>
> I’ve tested jhipster.org <http://jhipster.org> and I was able to
> send it in a message on Facebook. However, when I checked it at
> https://developers.facebook.com/tools/debug/, it says it contains a
> blocked URL. Maybe because it redirects to jhipster.tech
> <http://jhipster.tech>? It could also be because it doesn’t use
> HTTPS. It says jhipster.tech <http://jhipster.tech> is blocked and
> I’ve reported it as a mistake (a couple of times now).
>
> https://developers.facebook.com/tools/debug/?q=https%3A%2F%2Fjhipster.
tech
>
>
<https://developers.facebook.com/tools/debug/?q=https://jhipster.tech>
>
>> On Apr 26, 2020, at 1:32 PM, Julien Dubois
>> <julien...@gmail.com <mailto:julien...@gmail.com>>
>> wrote:
>>
>> Hey Matt,
>>
>> Are you sure it won’t happen with a .org? How can we better
>> understand the cause of this issue?
>>
>> Julien
>>
>> Le sam. 25 avr. 2020 à 17:41, Matt Raible
>> <ma...@raibledesigns.com <mailto:ma...@raibledesigns.com>> a écrit
>> :
>>
>> OMG, so annoying! It happened again with a FB comment this
>> morning. 🤬
>>
>> I'm willing to donate jhipster.org <http://jhipster.org/>! Or
>> maybe just use it to redirect requests. 😊
>>
>> <image0.png>
>>
>>> On Apr 24, 2020, at 13:51, Matt Raible <ma...@raibledesigns.com
>>> <mailto:ma...@raibledesigns.com>> wrote:
>>>
>>> Comments below regarding micro frontends and our package
>>> name.
>>>
>>>> On Apr 20, 2020, at 12:56 PM, Frederik Hahne
>>>> <frederi...@gmail.com <mailto:frederi...@gmail.com>>
>>>> wrote:
>>>>>
>>>>> Let’s look at the rest of the breaking changes listed:
>>>>>
>>>>> * Make front-end apps first-class citizens. I’m not sure
>>>>> why we need this since a JHipster frontend can’t exist
>>>>> without a JHipster backend. I’d rather see microfrontend
>>>>> support and I’m willing to do the work for that.Do we have
>>>>> made a decision what our goal for micro frontends is?
>>>> Looking at the approach I favor and e.g. single spa, they are
>>>> quite different with single spa (i think) clearly the easier
>>>> one to implement for us.
>>>
>>>
>>> This is the approach I hope to try soon:
>>>
>>> https://github.com/ScriptedAlchemy/webpack-external-import
>>>
>>>>> * Rename package to tech.jhipster. I’m not sure this is
>>>>> needed, but it doesn’t seem hard, just tedious.
>>>
>>> I’m not sure we should do this as it doesn’t really buy us
>>> anything. Also, Facebook thinks it’s a malicious link in
>>> Messenger. I reported it, but I was still surprised to find
>>> this.
>>>
>>> <Screen Shot 2020-04-24 at 1.45.23 PM.png>
>>
>> -- 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
>> <mailto:jhipster-dev...@googlegroups.com>. To view this
<https://groups.google.com/d/msgid/jhipster-dev/A7D37F67-FBE0-4CC6-B101-
A70D8AFD0A1B%40raibledesigns.com?utm_medium=email&utm_source=footer>.
>>
>> -- Julien Dubois
>>
>> Twitter: @juliendubois <http://twitter.com/#!/juliendubois>
>>
>
> -- 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
> <mailto:jhipster-dev...@googlegroups.com>. To view this
> discussion on the web visit
> https://groups.google.com/d/msgid/jhipster-dev/C689A559-051F-4B8E-A080
- -A0947910861E%40raibledesigns.com
>
>
<https://groups.google.com/d/msgid/jhipster-dev/C689A559-051F-4B8E-A080-
A0947910861E%40raibledesigns.com?utm_medium=email&utm_source=footer>.
>
>
>
> -- Charlie Mordant
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE5wKhRPm9hGEZmys4m4lX4DKXpcUFAl6meRsACgkQm4lX4DKX
pcWHJhAAu8M53LdHIB3+unQqbKeqzGEvsXVOu+hBy2Fb70V9TYwcHZt6DSGtFNYP
LArUb9w3kwaN1eTi+GtaEYYju2sZp+4P9L9T2JL0BtAO7yhnr5UCBQ6aRSw58I6W
t8V3lR7/mAtPH8SAr0re255xzfDkCz7MWdgCmaTBMHExvEGmuQAXs2dNv5+WQ1Hv
gcvfR/KJe9CAtmBXceRQGMNg8ZQ1MD3+xkX/NEGdKATwenVtAPUPi0Vv+fOh97f7
xttPRFzhUdnpfzu5/BimWvJ9U1EtzEF7TtSt3pJCt0AprGNSY9y0HU93/w/J6oIM
fBtXg7Z7T4oLsk2imq8QBkAVSvwauWGQ+ZcN1kbbSKsWHV4fAikRYoQFMkrg3/Yb
PF/z+VHd6vCLeVC+2CymmGpnDlUPdN76xMTA2k8F0SN851SaUE95wGHNA+OFGaxV
x8M60xRZs9JwJNZ5IUDtbTW6c1psye0bT0RS/I++soIpLHrnRP8gYuX0VAghU7Bp
0kcjI5pSt37gGCuw3tJAEHiLWchnnfGQJ9U4PI4EzpMhBzt/kBvjoz+oFHmrw/uF
k/VEaBwFZByPzAV9yvgjpNNTpi8vWMQHGS7j4uzYa5KredhxjSzLbPPHmGHariKP
/DUKzQSkukOWjFoucyAp/jWKNFWqPcZmIReMOizMvECMMT9tvVo=
=mTmE
-----END PGP SIGNATURE-----

Julien Dubois

unread,
Apr 27, 2020, 3:31:05 AM4/27/20
to Frederik Hahne, JHipster dev team
Good points concerning our templates.

This is mostly my fault, so I feel I need to answer.

- Indeed, they are sometimes very complex and nearly impossible to understand
- On the other hand, most of the time they are very simple, and as it's just plain JS, this allows a lot of people to contribute

So we must keep the simplicity (for simple stuff), and refactor/improve the hard parts.

As for JHipster 7, one of the key goals would be to simplify, using our libraries more, this means we would have 2 simplifications efforts to do in parallel:

- There are templates which will be removed or greatly simplified because we don't generate that code anymore (it will be in our libraries). For example, the JWT code shouldn't be generated anymore, but be in our framework.
- There are templates which need to be refactored so they are easier to understand (this is Charlie's point), but will generate the same thing in the end. For example, the JPA entities will probably stay the same.

And we need to keep in mind we have 2 goals here:

- Help our end-users: for this we need to generate less, so it's easier to understand and upgrade
- Help our contributors, as the success of the project comes from them

Would you agree, Charlie?

Julien Dubois

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/17f090ce-0747-a52c-985b-e86afc76c3f8%40gmail.com.

Frederik Hahne

unread,
Apr 27, 2020, 3:44:15 AM4/27/20
to JHipster dev team
Just a small heads up from Michael when he implemented the initial neo4j
integration:

He is not a JS developer and he said it was quite easy to find the
relevant parts when you have an application which contains the required
changes already. So he was very pleased that it was quite easy to get
started.
> <mailto:frederi...@gmail.com>> a écrit :
>> <mailto:ma...@raibledesigns.com <mailto:ma...@raibledesigns.com>>> a
> écrit :
>
>> I’ve tested jhipster.org <http://jhipster.org>
> <http://jhipster.org> and I was able to
>> send it in a message on Facebook. However, when I checked it at
>> https://developers.facebook.com/tools/debug/, it says it contains a
>> blocked URL. Maybe because it redirects to jhipster.tech
>> <http://jhipster.tech>? It could also be because it doesn’t use
>> HTTPS. It says jhipster.tech <http://jhipster.tech> is blocked and
>> I’ve reported it as a mistake (a couple of times now).
>
>> https://developers.facebook.com/tools/debug/?q=https%3A%2F%2Fjhipster.
> tech
>
>
> <https://developers.facebook.com/tools/debug/?q=https://jhipster.tech>
>
>>> On Apr 26, 2020, at 1:32 PM, Julien Dubois
>>> <julien...@gmail.com <mailto:julien...@gmail.com>
> <mailto:julien...@gmail.com <mailto:julien...@gmail.com>>>
>>> wrote:
>>>
>>> Hey Matt,
>>>
>>> Are you sure it won’t happen with a .org? How can we better
>>> understand the cause of this issue?
>>>
>>> Julien
>>>
>>> Le sam. 25 avr. 2020 à 17:41, Matt Raible
>>> <ma...@raibledesigns.com <mailto:ma...@raibledesigns.com>
> <mailto:ma...@raibledesigns.com <mailto:ma...@raibledesigns.com>>> a écrit
>>> :
>>>
>>> OMG, so annoying! It happened again with a FB comment this
>>> morning. 🤬
>>>
>>> I'm willing to donate jhipster.org <http://jhipster.org>
> <http://jhipster.org/>! Or
>>> maybe just use it to redirect requests. 😊
>>>
>>> <image0.png>
>>>
>>>> On Apr 24, 2020, at 13:51, Matt Raible <ma...@raibledesigns.com
> <mailto:ma...@raibledesigns.com>
>>>> <mailto:ma...@raibledesigns.com <mailto:ma...@raibledesigns.com>>>
> wrote:
>>>>
>>>> Comments below regarding micro frontends and our package
>>>> name.
>>>>
>>>>> On Apr 20, 2020, at 12:56 PM, Frederik Hahne
>>>>> <frederi...@gmail.com <mailto:frederi...@gmail.com>
> <mailto:frederi...@gmail.com <mailto:frederi...@gmail.com>>>
>>>>> wrote:
>>>>>>
>>>>>> Let’s look at the rest of the breaking changes listed:
>>>>>>
>>>>>> * Make front-end apps first-class citizens. I’m not sure
>>>>>> why we need this since a JHipster frontend can’t exist
>>>>>> without a JHipster backend. I’d rather see microfrontend
>>>>>> support and I’m willing to do the work for that.Do we have
>>>>>> made a decision what our goal for micro frontends is?
>>>>> Looking at the approach I favor and e.g. single spa, they are
>>>>> quite different with single spa (i think) clearly the easier
>>>>> one to implement for us.
>>>>
>>>>
>>>> This is the approach I hope to try soon:
>>>>
>>>> https://github.com/ScriptedAlchemy/webpack-external-import
>>>>
>>>>>> * Rename package to tech.jhipster. I’m not sure this is
>>>>>> needed, but it doesn’t seem hard, just tedious.
>>>>
>>>> I’m not sure we should do this as it doesn’t really buy us
>>>> anything. Also, Facebook thinks it’s a malicious link in
>>>> Messenger. I reported it, but I was still surprised to find
>>>> this.
>>>>
>>>> <Screen Shot 2020-04-24 at 1.45.23 PM.png>
>>>
>>> -- 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
> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>
>>> <mailto:jhipster-dev...@googlegroups.com
> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>>. To view this
> <https://groups.google.com/d/msgid/jhipster-dev/A7D37F67-FBE0-4CC6-B101-
> A70D8AFD0A1B%40raibledesigns.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/jhipster-dev/A7D37F67-FBE0-4CC6-B101-A70D8AFD0A1B%40raibledesigns.com?utm_medium=email&utm_source=footer>>.
>>>
>>> -- Julien Dubois
>>>
>>> Twitter: @juliendubois <http://twitter.com/#!/juliendubois>
>>>
>
>> -- 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
> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>
>> <mailto:jhipster-dev...@googlegroups.com
> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>>. To view this
> -A0947910861E%40raibledesigns.com <http://40raibledesigns.com>
>
>
> <https://groups.google.com/d/msgid/jhipster-dev/C689A559-051F-4B8E-A080-
> A0947910861E%40raibledesigns.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/jhipster-dev/C689A559-051F-4B8E-A080-A0947910861E%40raibledesigns.com?utm_medium=email&utm_source=footer>>.
>
>
>
>> -- Charlie Mordant
>
> --
> 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
> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>.
> To view this discussion on the web visit
>
> Twitter: @juliendubois <http://twitter.com/#!/juliendubois>
>

signature.asc

Pascal GRIMAUD

unread,
Apr 27, 2020, 3:51:26 AM4/27/20
to Charlie Mordant, Matt Raible, Julien Dubois, Frederik Hahne, JHipster dev team

Hi,


Here my personal own opinion.


I don’t think our template are complex.

When I show to someone our template, the 1st words are: “really ? in fact, it’s easy to understand”

For me, “if option.elastic == true” is easier to understand.


So, if I understand well, the main goal is to increase the contributors.

We have already a lot of contributors, 547 only on the generator-jhipster. It’s already good and we can be happy for that. We have 37 core team members too. But to be honest, we are not all active. We can’t make contributions mandatory, it’s an open source project and personal time with family is important.

IMO, the 1st problem is time.


Why do you think our template is so complex ?

Yes, there are a lot of condition, if, else, if, else…

For me, the 2nd problem is the number of options we provide.

We have really too much options. We have some options which are used by less than 1% of the generated projects. We want to make all people happy by accepting new options, but it increases the maintenance, add more conditions in our templates, uses more resources to launch builds in CI, etc.

Sometimes, we had some daily builds which failed for days, weeks (months too).
Who cares ? No one uses these options...


Our blueprint system is pretty fine today.

Look at the Vue.js blueprint, it works well, without a lot of contributors / maintenance.


Don’t change the system and make it more complex, for, maybe less than 10 real blueprints ?


Again, it’s just my opinion. But to help the project, instead of refactoring everything, just let’s clean options which are not used a lot.


Pascal



Julien Dubois

unread,
Apr 27, 2020, 3:55:04 AM4/27/20
to Pascal GRIMAUD, Charlie Mordant, Matt Raible, Frederik Hahne, JHipster dev team
Oh Pascal you are totally right about the options: for JHipster 7, we should remove options. But it's always very hard to do!!!!

Deepu K Sasidharan

unread,
Apr 27, 2020, 4:04:41 AM4/27/20
to Julien Dubois, Pascal GRIMAUD, Charlie Mordant, Matt Raible, Frederik Hahne, JHipster dev team
This is the exact reason I'm always pushing for blueprints instead of adding something to core. Even for vuejs I'll rather have it as blueprint that integrated into core, if its up to me I'll even move Angular and React to blueprints and just compose them to show the options.


I also agree with Pascal, our templates are not complex they are just big and messy. But they are still easy for contributors than many other complex setup. May be what we can do is split templates into multiple, there will be duplication, to reduce the if elses

Also lets not add more options to core, IMO the neo4j stuff should have been a blueprint, I don't know how much it will be used, probably at same level as Cassandra or Couch base

Pascal GRIMAUD

unread,
Apr 27, 2020, 4:08:49 AM4/27/20
to Deepu K Sasidharan, Julien Dubois, Charlie Mordant, Matt Raible, Frederik Hahne, JHipster dev team
I agree about Vue.js too.
I'm changing my mind : it works too well in blueprint today and I think it should stay like this...

Frederik Hahne

unread,
Apr 27, 2020, 4:16:17 AM4/27/20
to JHipster dev team
I would also like to keep vue as a blueprint. With that we are more
flexible, e.g. using cypress instead of protractor. Or just supporting
some options.
On 4/27/20 10:08 AM, Pascal GRIMAUD wrote:
> I agree about Vue.js too.
> I'm changing my mind : it works too well in blueprint today and I think
> it should stay like this...
>
> Le lun. 27 avr. 2020 à 10:04, Deepu K Sasidharan
> <deepu.k.s...@gmail.com <mailto:deepu.k.s...@gmail.com>> a
> écrit :
>
> This is the exact reason I'm always pushing for blueprints instead
> of adding something to core. Even for vuejs I'll rather have it as
> blueprint that integrated into core, if its up to me I'll even move
> Angular and React to blueprints and just compose them to show the
> options.
>
>
> I also agree with Pascal, our templates are not complex they are
> just big and messy. But they are still easy for contributors than
> many other complex setup. May be what we can do is split templates
> into multiple, there will be duplication, to reduce the if elses
>
> Also lets not add more options to core, IMO the neo4j stuff should
> have been a blueprint, I don't know how much it will be used,
> probably at same level as Cassandra or Couch base
>
> On Mon, 27 Apr 2020, 9:55 am Julien Dubois, <julien...@gmail.com
> <mailto:julien...@gmail.com>> wrote:
>
> Oh Pascal you are totally right about the options: for JHipster
> 7, we should remove options. But it's always very hard to do!!!!
>
> Le lun. 27 avr. 2020 à 09:51, Pascal GRIMAUD
> <pascal....@gmail.com <mailto:pascal....@gmail.com>> a
> écrit :
>
> Hi,
>
>
> Here my personal own opinion.
>
>
> I don’t think our template are complex.
>
> When I show to someone our template, the 1st words are:
> “really ? in fact, it’s easy to understand”
>
> For me, “if option.elastic == true” is easier to understand.
>
>
> So, if I understand well, the main goal is to increase the
> contributors.
>
> We have already a lot of contributors, 547 only on the
> generator-jhipster. It’s already good and we can be happy
> for that. We have 37 core team members too. But to be
> honest, we are not all active. We can’t make contributions
> mandatory, it’s an open source project and personal time
> with family is important.
>
> IMO, the 1st problem is time.
>
>
> Why do you think our template is so complex ?
>
> Yes, there are a lot of condition, if, else, if, else…
>
> For me, the 2nd problem is the number of optionswe provide.
>
> We have really too much options. We have some options which
> are used by less than 1% of the generated projects. We want
> to make all people happy by accepting new options, but it
> increases the maintenance, add more conditions in our
> templates, uses more resources to launch builds in CI, etc.
>
> Sometimes, we had some daily builds which failed for days,
> weeks (months too).
> Who cares ? No one uses these options...
>
>
> Our blueprint system is pretty fine today.
>
> Look at the Vue.js blueprint, it works well, without a lot
> of contributors / maintenance.
>
>
> Don’t change the system and make it more complex, for, maybe
> less than 10 real blueprints ?
>
>
> Again, it’s just my opinion. But to help the project,
> instead of refactoring everything, just let’s clean options
> which are not used a lot.
>
>
> Pascal
>
>
>
> Le lun. 27 avr. 2020 à 02:37, Charlie Mordant
> <cmor...@gmail.com <mailto:cmor...@gmail.com>> a écrit :
> <ma...@raibledesigns.com <mailto:ma...@raibledesigns.com>>
> a écrit :
>
> I’ve tested jhipster.org <http://jhipster.org> and I
> was able to send it in a message on Facebook.
> However, when I checked it
> at https://developers.facebook.com/tools/debug/, it
> says it contains a blocked URL. Maybe because it
> redirects to jhipster.tech <http://jhipster.tech>?
> It could also be because it doesn’t use HTTPS. It
> says jhipster.tech <http://jhipster.tech> is blocked
> and I’ve reported it as a mistake (a couple of times
> now).
>
> https://developers.facebook.com/tools/debug/?q=https%3A%2F%2Fjhipster.tech
> <https://developers.facebook.com/tools/debug/?q=https://jhipster.tech>
>
>> On Apr 26, 2020, at 1:32 PM, Julien Dubois
>> <julien...@gmail.com
>> <mailto:julien...@gmail.com>> wrote:
>>
>> Hey Matt,
>>
>> Are you sure it won’t happen with a .org? How can
>> we better understand the cause of this issue?
>>
>> Julien
>>
>> Le sam. 25 avr. 2020 à 17:41, Matt Raible
>> <ma...@raibledesigns.com
>> <mailto:ma...@raibledesigns.com>> a écrit :
>>
>> OMG, so annoying! It happened again with a FB
>> comment this morning. 🤬
>>
>> I'm willing to donate jhipster.org
>> <http://jhipster.org/>! Or maybe just use it
>> to redirect requests. 😊
>>
>> <image0.png>
>>
>>> On Apr 24, 2020, at 13:51, Matt Raible
>>> <ma...@raibledesigns.com
>>> <mailto:ma...@raibledesigns.com>> wrote:
>>>
>>> Comments below regarding micro frontends and
>>> our package name.
>>>
>>>> On Apr 20, 2020, at 12:56 PM, Frederik Hahne
>>>> <frederi...@gmail.com
>> <mailto:jhipster-dev...@googlegroups.com>.
>> <https://groups.google.com/d/msgid/jhipster-dev/A7D37F67-FBE0-4CC6-B101-A70D8AFD0A1B%40raibledesigns.com?utm_medium=email&utm_source=footer>.
>>
>> -- 
>> Julien Dubois
>>
>> Twitter: @juliendubois
>> <http://twitter.com/#!/juliendubois>
>>
>
> --
> 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
> <mailto:jhipster-dev...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jhipster-dev/C689A559-051F-4B8E-A080-A0947910861E%40raibledesigns.com
> <https://groups.google.com/d/msgid/jhipster-dev/C689A559-051F-4B8E-A080-A0947910861E%40raibledesigns.com?utm_medium=email&utm_source=footer>.
>
>
>
> --
> Charlie Mordant
>
> --
> 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
> <mailto:jhipster-dev...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jhipster-dev/CANHkoGzMj28otKa1otmfTFPHvFxEqXG3dwOusF5MXS6f3W1oJw%40mail.gmail.com
> <https://groups.google.com/d/msgid/jhipster-dev/CANHkoGzMj28otKa1otmfTFPHvFxEqXG3dwOusF5MXS6f3W1oJw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
>
>
> --
> Julien Dubois
>
> Twitter: @juliendubois <http://twitter.com/#!/juliendubois>
>
> --
> 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
> <mailto:jhipster-dev...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jhipster-dev/CADNXADE5Kck7BXHQ_0qXD82%2Bqs%3DBnvrMyo72vfpZGCFdXcmOWg%40mail.gmail.com
> <https://groups.google.com/d/msgid/jhipster-dev/CADNXADE5Kck7BXHQ_0qXD82%2Bqs%3DBnvrMyo72vfpZGCFdXcmOWg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>

signature.asc

Julien Dubois

unread,
Apr 27, 2020, 4:20:04 AM4/27/20
to Frederik Hahne, JHipster dev team
I'm not totally agreeing for VueJS, for 2 reasons:

- You cannot mix blueprints. So you wouldn't be able to use VueJS with Micronaut or Quarkus.
- It's only a marketing thing, but for big options like this, it's better to have them out of the box, if we want people to think they are fully stable and supported

Julien

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/a5da6b64-87bf-f5eb-e2fa-150efd4aa3fc%40gmail.com.

Anthony Viard

unread,
Apr 27, 2020, 4:24:40 AM4/27/20
to Julien Dubois, Frederik Hahne, JHipster dev team
"You cannot mix blueprints. So you wouldn't be able to use VueJS with Micronaut or Quarkus."
This is not really true anymore, the blueprint flag ("--blueprints" accept a list of blueprint). But we cannot be sure that blueprints are compatible... 

Deepu K Sasidharan

unread,
Apr 27, 2020, 4:38:49 AM4/27/20
to Anthony Viard, Julien Dubois, Frederik Hahne, JHipster dev team
IMO if we face issues with blueprints we should try to improve it and push blueprints more. Thats the only way we can grow at this point

Deepu K Sasidharan

unread,
Apr 27, 2020, 4:42:53 AM4/27/20
to Anthony Viard, Julien Dubois, Frederik Hahne, JHipster dev team
And for having it out of the box, we can do that easily without merging it as well. I'll do a pr to demonstrate that

Anthony Viard

unread,
Apr 27, 2020, 4:43:03 AM4/27/20
to Julien Dubois, Frederik Hahne, JHipster dev team
Anyway, I'm agree with both Frederik and Pascal. Sometimes it feels our templates are a little bit complex because of mixing options. For exemple, is it necessary to have such caching options that we have ? I'm not sure. In the meantime, if we reduce the number of options, we will have a less good marketing visibility....

It's not easy to balance....

Charlie Mordant

unread,
Apr 27, 2020, 5:05:06 AM4/27/20
to Anthony Viard, Julien Dubois, Frederik Hahne, JHipster dev team
You're right, templates are not intrinstically complex: most of them are really simple and we just have to stay focus on our dedicated conditional section if we want to contribute a particular option :-).
The real issue is anywhere else (in addition of the readability of some of them): as a contributor, I don't know all the template files I should contribute to in order to bring a feature.
For example, if one want to contribute something on the Elastic side, he should know that:

* he may contribute to the pom template
* he may contribute to the gradlew template
* he may contribute to the entity template
* he may contribute to the configuration template
* he may contribute to the application.yml and test/application.yml template
* he may contribute to the searchrepository template
* he may contribute to the serviceImpl/serviceClass template
* he may contribute to the resource template
* he may contribute to the searchrepository test mock template
* he may contribute to the integrationtest mock template
* X2 for reactive and non reactive backend classes
* he may contribute to the filters template
* he may contribute to the frontend entity service template
* he may contribute to the angular list component template
* same for react
* same for vue
* and for quarkus? micronaut?


But he has to read the entire generator codebase (as well as blueprints) to know that, and every template will be a mix and match of raw POJOs, other vendor code including the one I'm interested in.

The thing is that I'm totally inline with what deepu underlined at the extreme position: there's no reason to have 'core' technologies and 'blueprints' anymore (as the core libs and the blueprint framework is mature enough), at least at the generator level => everything could become blueprint, ones being 'official', others 'provided by the community':
* I'll know where to contribute because all the templates I need to improve will be in the same repository/package
* generator-jhipster will be blueprint-friendly because everything (but the skeleton and POJOs) will be a contribution...
* DDD at the technology level/MicroGenerator
* the only long term strategy to handle the variability we are proud of and we want to push and that make jhipster a crazy thing.




--
Charlie Mordant

mathi...@free.fr

unread,
Apr 27, 2020, 5:59:10 AM4/27/20
to Charlie Mordant, Anthony Viard, Julien Dubois, Frederik Hahne, JHipster dev team
Hello there!

My 2 cents about templates, I've had the (dis)pleasure of updating some templates very recently and for the same object: they're either duplicated (react and angular enums) or in a single file (java enum template). I was lucky because the implementation is very simple.

Sometimes the logic is in the templates rather than the files providing the data to fill them (duplication fixes that issue incidentally).
As Charlie pointed out: "The real issue is anywhere else (in addition of the readability of some of them): as a contributor, I don't know all the template files I should contribute to in order to bring a feature.". The same happened to me, and without Marcelo's help I wouldn't have made it.

Perhaps, we should consider splitting the templates differently. Instead of doing this the "layery" way, we should try the "logic" splitting way (a folder for enums, entities, controllers, liquibase, etc). A bit like Rails does.

Anyway, I'm okay to implement new things so as to provide users new toys to play with but we should clean up and have a clear guide on how to do "clean coding" in the generator repo.

Mathieu

Matt Raible

unread,
May 2, 2020, 10:32:33 AM5/2/20
to mathi...@free.fr, Charlie Mordant, Anthony Viard, Julien Dubois, Frederik Hahne, JHipster dev team
I'd like to bring this thread back to the 6.9.0 release. If you have demos or articles you're writing in the next few weeks, now would be a good time to test your code using the master branch. I have a few:

* Build a React + Node.js app for Scotch.io
* Reactive Microservices 
* Micronaut monolith

Of course, I'll be using OAuth for both. I haven't decided which web frameworks to use for the last two, but Angular + Micronaut might be best for the widest audience.

I'll do my best to test these combinations in the next few days.

Cheers,

Matt

On Apr 27, 2020, at 03:59, mathi...@free.fr wrote:



Pascal GRIMAUD

unread,
May 4, 2020, 12:31:14 PM5/4/20
to Matt Raible, Mathieu Abou-Aichi, Charlie Mordant, Anthony Viard, Julien Dubois, Frederik Hahne, JHipster dev team
Hi all,

I'm on vacations this week, but stay at home :-)
I'll time to do a release before friday.
Are you all ok ? No blocking issue ?

Pascal

Frederik Hahne

unread,
May 4, 2020, 12:53:31 PM5/4/20
to JHipster dev team
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I will try to get the neo4j heroku support out tonight.
The other open bug is not critical right now, will fix it after my
talk on friday. Maybe Michael from the neo4 team will pick it up too.
They both are very interested in making neo4j & jhipster a success story
.

best regards

Fred


On 5/4/20 6:30 PM, Pascal GRIMAUD wrote:
> Hi all,
>
> I'm on vacations this week, but stay at home :-) I'll time to do a
> release before friday. Are you all ok ? No blocking issue ?
>
> Pascal
>
> Le sam. 2 mai 2020 à 16:32, Matt Raible <ma...@raibledesigns.com
> <mailto:ma...@raibledesigns.com>> a écrit :
>
> I'd like to bring this thread back to the 6.9.0 release. If you
> have demos or articles you're writing in the next few weeks, now
> would be a good time to test your code using the master branch. I
> have a few:
>
> * Build a React + Node.js app for Scotch.io * Reactive
> Microservices * Micronaut monolith
>
> Of course, I'll be using OAuth for both. I haven't decided which
> web frameworks to use for the last two, but Angular + Micronaut
> might be best for the widest audience.
>
> I'll do my best to test these combinations in the next few days.
>
> Cheers,
>
> Matt
>
>> On Apr 27, 2020, at 03:59, mathi...@free.fr
>> <mailto:mathi...@free.fr> wrote:
>>
>>  Hello there!
>>
>> My 2 cents about templates, I've had the (dis)pleasure of
>> updating some templates very recently and for the same object:
>> they're either duplicated (react and angular enums) or in a
>> single file (java enum template). I was lucky because the
>> implementation is very simple.
>>
>> Sometimes the logic is in the templates rather than the files
>> providing the data to fill them (duplication fixes that issue
>> incidentally). As Charlie pointed out: "The real issue is
>> anywhere else (in addition of the readability of some of them):
>> as a contributor, I don't know all the template files I should
>> contribute to in order to bring a feature.". The same happened to
>> me, and without Marcelo's help I wouldn't have made it.
>>
>> Perhaps, we should consider splitting the templates differently.
>> Instead of doing this the "layery" way, we should try the
>> "logic" splitting way (a folder for enums, entities,
>> controllers, liquibase, etc). A bit like Rails does.
>>
>> Anyway, I'm okay to implement new things so as to provide users
>> new toys to play with but we should clean up and have a clear
>> guide on how to do "clean coding" in the generator repo.
>>
>> Mathieu
>>
>> Le 27 avr. 2020 11:04, Charlie Mordant <cmor...@gmail.com
>> <mailto:cmor...@gmail.com>> a écrit :
>>
>> @Grimaud Pascal <mailto:pascal....@gmail.com> You're right,
>> <mailto:anth....@gmail.com>> a écrit :
>>
>> Anyway, I'm agree with both Frederik and Pascal. Sometimes it
>> feels our templates are a little bit complex because of mixing
>> options. For exemple, is it necessary to have such caching
>> options that we have ? I'm not sure. In the meantime, if we
>> reduce the number of options, we will have a less good marketing
>> visibility....
>>
>> It's not easy to balance....
>>
>> Le lun. 27 avr. 2020 à 10:24, Anthony Viard <anth....@gmail.com
>> <mailto:anth....@gmail.com>> a écrit :
>>
>> "You cannot mix blueprints. So you wouldn't be able to use VueJS
>> with Micronaut or Quarkus." This is not really true anymore, the
>> blueprint flag ("--blueprints" accept a list of blueprint). But
>> we cannot be sure that blueprints are compatible...
>>
>> Le lun. 27 avr. 2020 à 10:20, Julien Dubois
>> <julien...@gmail.com <mailto:julien...@gmail.com>> a
>> écrit :
>>
>> I'm not totally agreeing for VueJS, for 2 reasons:
>>
>> - You cannot mix blueprints. So you wouldn't be able to use VueJS
>> with Micronaut or Quarkus. - It's only a marketing thing, but for
>> big options like this, it's better to have them out of the box,
>> if we want people to think they are fully stable and supported
>>
>> Julien
>>
>> Le lun. 27 avr. 2020 à 10:16, Frederik Hahne
>> <frederi...@gmail.com <mailto:frederi...@gmail.com>> a
>> écrit :
>>
>> I would also like to keep vue as a blueprint. With that we are
>> more flexible, e.g. using cypress instead of protractor. Or just
>> supporting some options. On 4/27/20 10:08 AM, Pascal GRIMAUD
>> wrote:
>>> I agree about Vue.js too. I'm changing my mind : it works too
>>> well in
>> blueprint today and I think
>>> it should stay like this...
>>>
>>> Le lun. 27 avr. 2020 à 10:04, Deepu K Sasidharan
>>> <deepu.k.s...@gmail.com
>> <mailto:deepu.k.s...@gmail.com>
>> <mailto:deepu.k.s...@gmail.com
>>> <mailto:julien...@gmail.com
>> <mailto:julien...@gmail.com>>> wrote:
>>>
>>> Oh Pascal you are totally right
>> about the options: for JHipster
>>> 7, we should remove options. But
>> it's always very hard to do!!!!
>>>
>>> Le lun. 27 avr. 2020 à 09:51, Pascal
>> GRIMAUD
>>> <pascal....@gmail.com
>> <mailto:pascal....@gmail.com>
>> <mailto:pascal....@gmail.com
>> <mailto:cmor...@gmail.com> <mailto:cmor...@gmail.com
>> <mailto:ma...@raibledesigns.com> <mailto:ma...@raibledesigns.com
>> <mailto:ma...@raibledesigns.com>>>
>>> a écrit :
>>>
>>> I’ve tested jhipster.org
>> <http://jhipster.org> <http://jhipster.org> and I
>>> was able to send it in a
>> message on Facebook.
>>> However, when I checked it
>>>
>> at https://developers.facebook.com/tools/debug/, it
>>> says it contains a
>> blocked URL. Maybe because it
>>> redirects to
>> jhipster.tech <http://jhipster.tech>?
>>> It could also be because
>> it doesn’t use HTTPS. It
>>> says jhipster.tech
>> <http://jhipster.tech> is blocked
>>> and I’ve reported it as
>> a mistake (a couple of times
>>> now).
>>>
>>>
>> https://developers.facebook.com/tools/debug/?q=https%3A%2F%2Fjhipster
.tech
>>
>>
>
>> <https://developers.facebook.com/tools/debug/?q=https://jhipster.tech
>
>>
>>
>
>>>> On Apr 26, 2020, at
>> 1:32 PM, Julien Dubois
>>>>
>> <julien...@gmail.com <mailto:julien...@gmail.com>
>>>>
>> <mailto:julien...@gmail.com
>> <mailto:julien...@gmail.com>>> wrote:
>>>>
>>>> Hey Matt,
>>>>
>>>> Are you sure it won’t
>> happen with a .org? How can
>>>> we better understand
>> the cause of this issue?
>>>>
>>>> Julien
>>>>
>>>> Le sam. 25 avr. 2020 à
>> 17:41, Matt Raible
>>>> <ma...@raibledesigns.com
>> <mailto:ma...@raibledesigns.com>
>>>>
>> <mailto:ma...@raibledesigns.com <mailto:ma...@raibledesigns.com>>>
>> a écrit :
>>>>
>>>> OMG, so annoying!
>> It happened again with a FB
>>>> comment this
>> morning. 🤬
>>>>
>>>> I'm willing to
>> donate jhipster.org <http://jhipster.org>
>>>>
>> <http://jhipster.org/>! Or maybe just use it
>>>> to redirect
>> requests. 😊
>>>>
>>>> <image0.png>
>>>>
>>>>> On Apr 24, 2020,
>> at 13:51, Matt Raible
>>>>>
>> <ma...@raibledesigns.com <mailto:ma...@raibledesigns.com>
>>>>>
>> <mailto:ma...@raibledesigns.com <mailto:ma...@raibledesigns.com>>>
>> wrote:
>>>>>
>>>>> Comments below
>> regarding micro frontends and
>>>>> our package name.
>>>>>
>>>>>> On Apr 20, 2020,
>> at 12:56 PM, Frederik Hahne
>>>>>>
>> <frederi...@gmail.com <mailto:frederi...@gmail.com>
>>>>>>
>> <mailto:frederi...@gmail.com
>> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>
>>>>
>> <mailto:jhipster-dev...@googlegroups.com
>> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>>.
>>>> To view this
>> discussion on the web
>>>>
>> visit
01-A70D8AFD0A1B%40raibledesigns.com?utm_medium=email&utm_source=footer>.
>>
>>
>>
>>>> -- Julien Dubois
>>>>
>>>> Twitter: @juliendubois
>>>>
>> <http://twitter.com/#!/juliendubois>
>>>>
>>>
>>> -- 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
>> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>
>>>
>> <mailto:jhipster-dev...@googlegroups.com
>> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>>.
>>> To view this discussion
>> on the web visit
>>>
>> https://groups.google.com/d/msgid/jhipster-dev/C689A559-051F-4B8E-A08
0-A0947910861E%40raibledesigns.com
>>
>>
>
>> <https://groups.google.com/d/msgid/jhipster-dev/C689A559-051F-4B8E-A0
80-A0947910861E%40raibledesigns.com?utm_medium=email&utm_source=footer>.
>>
>>
>
>>>
>>>
>>> -- Charlie Mordant
>>>
>>> -- 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
>> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>
>>>
>> <mailto:jhipster-dev...@googlegroups.com
>> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>>.
>>> To view this discussion on
>> the web visit
>>>
>> https://groups.google.com/d/msgid/jhipster-dev/CANHkoGzMj28otKa1otmfT
FPHvFxEqXG3dwOusF5MXS6f3W1oJw%40mail.gmail.com
>>
>>
>
>> <https://groups.google.com/d/msgid/jhipster-dev/CANHkoGzMj28otKa1otmf
TFPHvFxEqXG3dwOusF5MXS6f3W1oJw%40mail.gmail.com?utm_medium=email&utm_sou
rce=footer>.
>>
>>
>
>>>
>>>
>>> -- Julien Dubois
>>>
>>> Twitter: @juliendubois
>> <http://twitter.com/#!/juliendubois>
>>>
>>> -- 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
>> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>
>>>
>> <mailto:jhipster-dev...@googlegroups.com
>> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>>.
>>> To view this discussion on the web visit
>>>
>> https://groups.google.com/d/msgid/jhipster-dev/CADNXADE5Kck7BXHQ_0qXD
82%2Bqs%3DBnvrMyo72vfpZGCFdXcmOWg%40mail.gmail.com
>>
>>
>
>> <https://groups.google.com/d/msgid/jhipster-dev/CADNXADE5Kck7BXHQ_0qX
D82%2Bqs%3DBnvrMyo72vfpZGCFdXcmOWg%40mail.gmail.com?utm_medium=email&utm
_source=footer>.
>>
>>
>
>>
>> -- 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
>> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>. To view
>> this discussion on the web visit
>> https://groups.google.com/d/msgid/jhipster-dev/a5da6b64-87bf-f5eb-e2f
a-150efd4aa3fc%40gmail.com.
>>
>>
>>
>>
>>
- --
>> Julien Dubois
>>
>> Twitter: @juliendubois <http://twitter.com/#!/juliendubois>
>>
>> -- 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
>> <mailto:jhipster-dev...@googlegroups.com>. To view this
>> discussion on the web visit
>> https://groups.google.com/d/msgid/jhipster-dev/CADNXADED%3DUvag_f7v51
N80E6_6%3DDMG7ds3wPyHZDO%3DsMD1CqZw%40mail.gmail.com
>>
>>
<https://groups.google.com/d/msgid/jhipster-dev/CADNXADED%3DUvag_f7v51N8
0E6_6%3DDMG7ds3wPyHZDO%3DsMD1CqZw%40mail.gmail.com?utm_medium=email&utm_
source=footer>.
>>
>> -- 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
>> <mailto:jhipster-dev...@googlegroups.com>. To view this
>> discussion on the web visit
>> https://groups.google.com/d/msgid/jhipster-dev/CAPEJTRfbfcO1MqnHpJaRH
5sJrCdL9ZgYjPkhqK6k%2BPgvA3fv2Q%40mail.gmail.com
>>
>>
<https://groups.google.com/d/msgid/jhipster-dev/CAPEJTRfbfcO1MqnHpJaRH5s
JrCdL9ZgYjPkhqK6k%2BPgvA3fv2Q%40mail.gmail.com?utm_medium=email&utm_sour
ce=footer>.
>>
>>
>>
>> -- Charlie Mordant
>>
>> -- 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
>> <mailto:jhipster-dev...@googlegroups.com>. To view this
>> discussion on the web visit
>> https://groups.google.com/d/msgid/jhipster-dev/CANHkoGyifh1t2RswAt1%2
Bd6UKp10nYS93UCbstAvRgztp9W07TA%40mail.gmail.com
>>
>>
<https://groups.google.com/d/msgid/jhipster-dev/CANHkoGyifh1t2RswAt1%2Bd
6UKp10nYS93UCbstAvRgztp9W07TA%40mail.gmail.com?utm_medium=email&utm_sour
ce=footer>.
>>
>>
>> -- 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
>> <mailto:jhipster-dev...@googlegroups.com>. To view this
>> discussion on the web visit
>> https://groups.google.com/d/msgid/jhipster-dev/6cec2385-d170-4c08-95f
1-3395ed3ee187%40email.android.com
>>
>>
<https://groups.google.com/d/msgid/jhipster-dev/6cec2385-d170-4c08-95f1-
3395ed3ee187%40email.android.com?utm_medium=email&utm_source=footer>.
>
> -- 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
> <mailto:jhipster-dev...@googlegroups.com>. To view this
> discussion on the web visit
> https://groups.google.com/d/msgid/jhipster-dev/1A6AB26D-983A-488A-81FF
- -416E2F17BD1A%40raibledesigns.com
>
>
<https://groups.google.com/d/msgid/jhipster-dev/1A6AB26D-983A-488A-81FF-
416E2F17BD1A%40raibledesigns.com?utm_medium=email&utm_source=footer>.
>
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE5wKhRPm9hGEZmys4m4lX4DKXpcUFAl6wSIQACgkQm4lX4DKX
pcVeSw//c7NuqdbkHEbjeX+tNaacjjO2gSpne1HDuBYTyKl7CZsXQEkww5oD3YFo
R4IOpW26cwgvmmryscsW64SsOYdkRo+5yeUKGL/etTR6Tpz9RVl3SFHgfeV02lYq
5QhuPPWDkTZW/CiiIOF/cwWyhlQlqAfR5g6NSmsKMyjk5PP+hCb0kcr8yUm4f3CO
tWJz9PQXqpHaTSH74VcksUaVdW03CX6C67ZcWSlOYANQTaGcj1UJUcJsnB7OpaSm
eVFiLF/Ce894XRUSg+vDwVpifqghsnN3YjjQgXgjq76md6thc0I2MPtrmDini1l3
VrH6kXY4LKRGBClieZnrQ2U224lI3jgLSbtFQ99yFrMoj7n5gJ7ZXBTtGC55uzQh
Gec4LoU3o19MfMtLzwR7qMWKGEiFR2UfZqDPjb9QKSP0sDzEeMjlY58h/l8dEDIR
IAYNd+YCE/cOE6luZWCXNzVeyWo+RIOTHWxtW0YmsoulxXJEg2DRsiLyiVTjxkMv
fOFHKDZ8IRi0T5Q2RjXS8Pq5lebnvO51TnLWcy1fCwoL4e0p5POaVcQKDem8xGv8
e5tQSypik5ZdPsevKkTHCEVkf1B7iybjBa5NBi+ZLDlQfnWO9vR3oam3aMrNqQFg
l988Gswl7XbXoFMEXW3NsW3PhB8tobWEJNlEEpGySpGO4yXgTfk=
=wSPX
-----END PGP SIGNATURE-----

Daniel Franco

unread,
May 4, 2020, 1:03:57 PM5/4/20
to Frederik Hahne, JHipster dev team
Next Thursday May 07th, spring-boot 2.2.7 will be out, and I will update it on Friday the last.
So, for me it is OK after this small upgrade.

Then we can focus on the update to spring-boot 2.3.0 for next release.

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/b986a2e2-7f77-0bc5-b688-5ad2627ac631%40gmail.com.

Pascal GRIMAUD

unread,
May 4, 2020, 1:07:20 PM5/4/20
to Daniel Franco, Frederik Hahne, JHipster dev team
Ok thanks. I'm preparing the other projects, and waiting Spring Boot 2.2.7 so !


Matt Raible

unread,
May 5, 2020, 12:31:46 AM5/5/20
to Pascal GRIMAUD, Daniel Franco, Frederik Hahne, JHipster dev team
I tested out Node.js + React tonight and entered a number of issues in the Node.js blueprint project.


I don’t think these issues have anything to do with v6.9.0, but it does show that the Node.js blueprint isn’t very polished.

I also tried reactive microservices (using the master branch) with the following JDL.

application {
  config {
    baseName gateway,
    packageName com.okta.developer.gateway,
    applicationType gateway,
    authenticationType oauth2,
    databaseType neo4j,
    devDatabaseType neo4j,
    prodDatabaseType neo4j,
    enableHibernateCache false,
    reactive true,
    searchEngine elasticsearch,
    serviceDiscoveryType eureka,
    testFrameworks [protractor]
  }
  entities Blog, Post, Tag, Product
}

application {
  config {
    baseName blog,
    packageName com.okta.developer.blog,
    applicationType microservice,
    authenticationType oauth2,
    databaseType couchbase,
    devDatabaseType couchbase,
    prodDatabaseType couchbase,
    enableHibernateCache false,
    reactive true,
    searchEngine elasticsearch,
    serverPort 8081,
    serviceDiscoveryType eureka
  }
  entities Blog, Post, Tag
}

application {
  config {
    baseName store,
    packageName com.okta.developer.store,
    applicationType microservice,
    authenticationType oauth2,
    databaseType mongodb,
    devDatabaseType mongodb,
    prodDatabaseType mongodb,
    enableHibernateCache false,
    reactive true
    searchEngine elasticsearch,
    serverPort 8082,
    serviceDiscoveryType eureka
  }
  entities Product
}

entity Blog {
  name String required minlength(3),
  handle String required minlength(2)
}

entity Post {
  title String required,
  content TextBlob required,
  date Instant required
}

entity Tag {
  name String required minlength(2)
}

entity Product {
  title String required,
  price BigDecimal required min(0),
  image ImageBlob
}

relationship ManyToOne {
  Blog{user(login)} to User,
  Post{blog(name)} to Blog
}

relationship ManyToMany {
  Post{tag(name)} to Tag{post}
}

paginate Post, Tag with infinite-scroll
paginate Product with pagination

microservice Product with store
microservice Blog, Post, Tag with blog
When I login, I get the following error. Starting Elasticsearch using Docker Compose solves the issue. This is puzzling since ES is supposed to store indexes in target/elasticsearch (not localhost:9200) when running the “dev” profile.


2020-05-04 22:14:13.120 ERROR 42389 --- [ctor-http-nio-8] o.z.problem.spring.common.AdviceTraits   : Internal Server Error

org.springframework.data.elasticsearch.client.NoReachableHostException: Host 'localhost:9200' not reachable. Cluster state is offline.
at org.springframework.data.elasticsearch.client.reactive.SingleNodeHostProvider.lambda$null$3(SingleNodeHostProvider.java:101)
Suppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException:
Assembly trace from producer [reactor.core.publisher.MonoFlatMap] :
reactor.core.publisher.Mono.flatMap(Mono.java:2734)
org.springframework.data.elasticsearch.client.reactive.SingleNodeHostProvider.lookupActiveHost(SingleNodeHostProvider.java:94)
Error has been observed at the following site(s):
|_       Mono.flatMap ⇢ at org.springframework.data.elasticsearch.client.reactive.SingleNodeHostProvider.lookupActiveHost(SingleNodeHostProvider.java:94)
|_           Mono.map ⇢ at org.springframework.data.elasticsearch.client.reactive.HostProvider.getActive(HostProvider.java:94)
|_       Mono.flatMap ⇢ at org.springframework.data.elasticsearch.client.reactive.DefaultReactiveElasticsearchClient.execute(DefaultReactiveElasticsearchClient.java:558)
|_         Mono.error ⇢ at org.springframework.data.elasticsearch.client.reactive.DefaultReactiveElasticsearchClient.lambda$execute$18(DefaultReactiveElasticsearchClient.java:567)
|_ Mono.onErrorResume ⇢ at org.springframework.data.elasticsearch.client.reactive.DefaultReactiveElasticsearchClient.execute(DefaultReactiveElasticsearchClient.java:559)
|_   Mono.flatMapMany ⇢ at org.springframework.data.elasticsearch.client.reactive.DefaultReactiveElasticsearchClient.sendRequest(DefaultReactiveElasticsearchClient.java:599)
|_   Flux.publishNext ⇢ at org.springframework.data.elasticsearch.client.reactive.DefaultReactiveElasticsearchClient.index(DefaultReactiveElasticsearchClient.java:302)
|_         Flux.defer ⇢ at org.springframework.data.elasticsearch.core.ReactiveElasticsearchTemplate.execute(ReactiveElasticsearchTemplate.java:126)
|_    Flux.onErrorMap ⇢ at org.springframework.data.elasticsearch.core.ReactiveElasticsearchTemplate.execute(ReactiveElasticsearchTemplate.java:126)
|_          Mono.from ⇢ at org.springframework.data.elasticsearch.core.ReactiveElasticsearchTemplate.doIndex(ReactiveElasticsearchTemplate.java:589)
|_         Mono.defer ⇢ at org.springframework.data.elasticsearch.core.ReactiveElasticsearchTemplate.doIndex(ReactiveElasticsearchTemplate.java:149)
|_           Mono.map ⇢ at org.springframework.data.elasticsearch.core.ReactiveElasticsearchTemplate.save(ReactiveElasticsearchTemplate.java:141)
|_    Mono.thenReturn ⇢ at com.okta.developer.gateway.service.UserService.lambda$updateUser$1(UserService.java:70)
|_       Mono.flatMap ⇢ at com.okta.developer.gateway.service.UserService.updateUser(UserService.java:70)
|_      Mono.doOnNext ⇢ at com.okta.developer.gateway.service.UserService.updateUser(UserService.java:71)
|_          Mono.then ⇢ at com.okta.developer.gateway.service.UserService.updateUser(UserService.java:72)
|_       Mono.flatMap ⇢ at com.okta.developer.gateway.service.UserService.syncUserWithIdP(UserService.java:129)
|_    Mono.thenReturn ⇢ at com.okta.developer.gateway.service.UserService.syncUserWithIdP(UserService.java:147)
|_       Mono.flatMap ⇢ at com.okta.developer.gateway.service.UserService.getUserFromAuthentication(UserService.java:175)
|_           Mono.map ⇢ at org.springframework.http.codec.json.AbstractJackson2Encoder.encode(AbstractJackson2Encoder.java:120)
|_ Flux.singleOrEmpty ⇢ at org.springframework.http.codec.EncoderHttpMessageWriter.write(EncoderHttpMessageWriter.java:121)
|_ Mono.switchIfEmpty ⇢ at org.springframework.http.codec.EncoderHttpMessageWriter.write(EncoderHttpMessageWriter.java:122)
|_       Mono.flatMap ⇢ at org.springframework.http.codec.EncoderHttpMessageWriter.write(EncoderHttpMessageWriter.java:126)
|_         checkpoint ⇢ Handler com.okta.developer.gateway.web.rest.AccountResource#getAccount(Principal) [DispatcherHandler]


The good news is “npm run e2e” passes!

  24 passing (1m)

And “./mvn verify” works in each project.

Cheers,

Matt

Pascal GRIMAUD

unread,
May 7, 2020, 5:08:01 PM5/7/20
to Daniel Franco, Frederik Hahne, JHipster dev team
With the release of Spring Boot 2.7, we are ready for the release.
I think it needs to be fixed before the next release, right ?

I can launch the release tomorrow (friday), or this week-end.
Just tell me what is the best for the project.


Julien Dubois

unread,
May 7, 2020, 5:15:40 PM5/7/20
to Pascal GRIMAUD, Daniel Franco, Frederik Hahne, JHipster dev team
Yes indeed, but this is being worked on by Frederik

Frederik Hahne

unread,
May 7, 2020, 5:21:56 PM5/7/20
to JHipster dev team
PR is ready to be reviewed. If we agree on the new regex I can align the
vue blueprint too.

On 5/7/20 11:15 PM, Julien Dubois wrote:
> Yes indeed, but this is being worked on by Frederik
>
> Le jeu. 7 mai 2020 à 23:08, Pascal GRIMAUD <pascal....@gmail.com
> <mailto:pascal....@gmail.com>> a écrit :
>
> With the release of Spring Boot 2.7, we are ready for the release.
> But I saw this
> ticket: https://github.com/jhipster/generator-jhipster/issues/11726
> I think it needs to be fixed before the next release, right ?
>
> I can launch the release tomorrow (friday), or this week-end.
> Just tell me what is the best for the project.
>
>
>
> Le lun. 4 mai 2020 à 19:07, Pascal GRIMAUD <pascal....@gmail.com
> <mailto:pascal....@gmail.com>> a écrit :
>
> Ok thanks. I'm preparing the other projects, and waiting Spring
> Boot 2.2.7 so !
>
>
> Le lun. 4 mai 2020 à 19:03, Daniel Franco <dandr...@gmail.com
> <mailto:dandr...@gmail.com>> a écrit :
>
> Next Thursday May 07th, spring-boot 2.2.7 will be out, and I
> will update it on Friday the last.
> So, for me it is OK after this small upgrade.
>
> Then we can focus on the update to spring-boot 2.3.0 for
> next release.
>
> Frederik Hahne <frederi...@gmail.com
> <mailto:frederi...@gmail.com>> escreveu no dia segunda,
> 4/05/2020 à(s) 17:53:
>
> I will try to get the neo4j heroku support out tonight.
> The other open bug is not critical right now, will fix
> it after my
> talk on friday. Maybe Michael from the neo4 team will
> pick it up too.
> They both are very interested in making neo4j & jhipster
> a success story
> .
>
> best regards
>
> Fred
>
>
> On 5/4/20 6:30 PM, Pascal GRIMAUD wrote:
>> Hi all,
>
>> I'm on vacations this week, but stay at home :-) I'll
> time to do a
>> release before friday. Are you all ok ? No blocking
> issue ?
>
>> Pascal
>
>> Le sam. 2 mai 2020 à 16:32, Matt Raible
> <ma...@raibledesigns.com <mailto:ma...@raibledesigns.com>
>> <mailto:ma...@raibledesigns.com
> <mailto:ma...@raibledesigns.com>>> a écrit :
>
>> I'd like to bring this thread back to the 6.9.0
> release. If you
>> have demos or articles you're writing in the next few
> weeks, now
>> would be a good time to test your code using the
> master branch. I
>> have a few:
>
>> * Build a React + Node.js app for Scotch.io * Reactive
>> Microservices * Micronaut monolith
>
>> Of course, I'll be using OAuth for both. I haven't
> decided which
>> web frameworks to use for the last two, but Angular +
> Micronaut
>> might be best for the widest audience.
>
>> I'll do my best to test these combinations in the next
> few days.
>
>> Cheers,
>
>> Matt
>
>>> On Apr 27, 2020, at 03:59, mathi...@free.fr
> <mailto:mathi...@free.fr>
>>> <mailto:mathi...@free.fr
>>> <mailto:cmor...@gmail.com
> <mailto:cmor...@gmail.com>>> a écrit :
>>>
>>> @Grimaud Pascal <mailto:pascal....@gmail.com
>>> <mailto:anth....@gmail.com
> <mailto:anth....@gmail.com>>> a écrit :
>>>
>>> Anyway, I'm agree with both Frederik and Pascal.
> Sometimes it
>>> feels our templates are a little bit complex because
> of mixing
>>> options. For exemple, is it necessary to have such
> caching
>>> options that we have ? I'm not sure. In the meantime,
> if we
>>> reduce the number of options, we will have a less
> good marketing
>>> visibility....
>>>
>>> It's not easy to balance....
>>>
>>> Le lun. 27 avr. 2020 à 10:24, Anthony Viard
> <anth....@gmail.com <mailto:anth....@gmail.com>
>>> <mailto:anth....@gmail.com
> <mailto:anth....@gmail.com>>> a écrit :
>>>
>>> "You cannot mix blueprints. So you wouldn't be able
> to use VueJS
>>> with Micronaut or Quarkus." This is not really true
> anymore, the
>>> blueprint flag ("--blueprints" accept a list of
> blueprint). But
>>> we cannot be sure that blueprints are compatible...
>>>
>>> Le lun. 27 avr. 2020 à 10:20, Julien Dubois
>>> <julien...@gmail.com
> <mailto:julien...@gmail.com>
> <mailto:julien...@gmail.com
> <mailto:julien...@gmail.com>>> a
>>> écrit :
>>>
>>> I'm not totally agreeing for VueJS, for 2 reasons:
>>>
>>> - You cannot mix blueprints. So you wouldn't be able
> to use VueJS
>>> with Micronaut or Quarkus. - It's only a marketing
> thing, but for
>>> big options like this, it's better to have them out
> of the box,
>>> if we want people to think they are fully stable and
> supported
>>>
>>> Julien
>>>
>>> Le lun. 27 avr. 2020 à 10:16, Frederik Hahne
>>> <frederi...@gmail.com
> <mailto:frederi...@gmail.com>
> <mailto:frederi...@gmail.com
>>> <mailto:jhipster-dev%2Bunsu...@googlegroups.com
> <mailto:jhipster-dev%252Buns...@googlegroups.com>>
>>>>>
>>> <mailto:jhipster-dev...@googlegroups.com
> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>
>>> <mailto:jhipster-dev%2Bunsu...@googlegroups.com
> <mailto:jhipster-dev%252Buns...@googlegroups.com>>>.
>>>>> To view this
>>> discussion on the web
>>>>>
>>> visit
>>>
> https://groups.google.com/d/msgid/jhipster-dev/A7D37F67-FBE0-4CC6-B10
> 1-A70D8AFD0A1B%40raibledesigns.com
> <https://groups.google.com/d/msgid/jhipster-dev/A7D37F67-FBE0-4CC6-B101-A70D8AFD0A1B%40raibledesigns.com?utm_medium=email&utm_source=footer>>.
>>>
>>>
>>>
>>>>> -- Julien Dubois
>>>>>
>>>>> Twitter: @juliendubois
>>>>>
>>> <http://twitter.com/#!/juliendubois>
>>>>>
>>>>
>>>> -- 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
> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>
>>> <mailto:jhipster-dev%2Bunsu...@googlegroups.com
> <mailto:jhipster-dev%252Buns...@googlegroups.com>>
>>>>
>>> <mailto:jhipster-dev...@googlegroups.com
> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>
>>> <mailto:jhipster-dev%2Bunsu...@googlegroups.com
> <mailto:jhipster-dev%252Buns...@googlegroups.com>>>.
> <https://groups.google.com/d/msgid/jhipster-dev/C689A559-051F-4B8E-A0
> 80-A0947910861E%40raibledesigns.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/jhipster-dev/C689A559-051F-4B8E-A080-A0947910861E%40raibledesigns.com?utm_medium=email&utm_source=footer>>.
>>>
>>>
>
>>>>
>>>>
>>>> -- Charlie Mordant
>>>>
>>>> -- 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
> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>
>>> <mailto:jhipster-dev%2Bunsu...@googlegroups.com
> <mailto:jhipster-dev%252Buns...@googlegroups.com>>
>>>>
>>> <mailto:jhipster-dev...@googlegroups.com
> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>
>>> <mailto:jhipster-dev%2Bunsu...@googlegroups.com
> <mailto:jhipster-dev%252Buns...@googlegroups.com>>>.
>>>> To view this discussion on
>>> the web visit
>>>>
>>>
> https://groups.google.com/d/msgid/jhipster-dev/CANHkoGzMj28otKa1otmfT
> FPHvFxEqXG3dwOusF5MXS6f3W1oJw%40mail.gmail.com
> <http://40mail.gmail.com>
>>>
>>>
>
>>>
> <https://groups.google.com/d/msgid/jhipster-dev/CANHkoGzMj28otKa1otmf
> TFPHvFxEqXG3dwOusF5MXS6f3W1oJw%40mail.gmail.com?utm_medium=email&utm_sou
> rce=footer
> <http://40mail.gmail.com?utm_medium=email&utm_source=footer>>.
>>>
>>>
>
>>>>
>>>>
>>>> -- Julien Dubois
>>>>
>>>> Twitter: @juliendubois
>>> <http://twitter.com/#!/juliendubois>
>>>>
>>>> -- 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
> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>
>>> <mailto:jhipster-dev%2Bunsu...@googlegroups.com
> <mailto:jhipster-dev%252Buns...@googlegroups.com>>
>>>>
>>> <mailto:jhipster-dev...@googlegroups.com
> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>
>>> <mailto:jhipster-dev%2Bunsu...@googlegroups.com
> <mailto:jhipster-dev%252Buns...@googlegroups.com>>>.
>>>> To view this discussion on the web visit
>>>>
>>>
> https://groups.google.com/d/msgid/jhipster-dev/CADNXADE5Kck7BXHQ_0qXD
> 82%2Bqs%3DBnvrMyo72vfpZGCFdXcmOWg%40mail.gmail.com
> <http://40mail.gmail.com>
>>>
>>>
>
>>>
> <https://groups.google.com/d/msgid/jhipster-dev/CADNXADE5Kck7BXHQ_0qX
> D82%2Bqs%3DBnvrMyo72vfpZGCFdXcmOWg%40mail.gmail.com?utm_medium=email&utm
> _source=footer
> <http://40mail.gmail.com?utm_medium=email&utm_source=footer>>.
>>>
>>>
>
>>>
>>> -- 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
> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>
>>> <mailto:jhipster-dev%2Bunsu...@googlegroups.com
> <mailto:jhipster-dev%252Buns...@googlegroups.com>>.
> To view
>>> this discussion on the web visit
>>>
> https://groups.google.com/d/msgid/jhipster-dev/a5da6b64-87bf-f5eb-e2f
> a-150efd4aa3fc%40gmail.com
> <https://groups.google.com/d/msgid/jhipster-dev/a5da6b64-87bf-f5eb-e2fa-150efd4aa3fc%40gmail.com>.
>>>
>>>
>>>
>>>
>>>
>
> --
> 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
> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>.
> To view this discussion on the web visit
>
https://groups.google.com/d/msgid/jhipster-dev/b986a2e2-7f77-0bc5-b688-5ad2627ac631%40gmail.com.
>
> --
> 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
> <mailto:jhipster-dev...@googlegroups.com>.
> To view this discussion on the web visit
>
https://groups.google.com/d/msgid/jhipster-dev/CADVdDoZbWSc%3DQUiZ0Yjwap4y8iY1V7GRYYVhcEUi9jZ0jL0-YQ%40mail.gmail.com
>
<https://groups.google.com/d/msgid/jhipster-dev/CADVdDoZbWSc%3DQUiZ0Yjwap4y8iY1V7GRYYVhcEUi9jZ0jL0-YQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
> --
> 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
> <mailto:jhipster-dev...@googlegroups.com>.
> To view this discussion on the web visit
>
https://groups.google.com/d/msgid/jhipster-dev/CALUG8VvJC7B%3D9qhY-KaCgdP_kYMw2suNYo7XYBaGk6Lmpw1XMA%40mail.gmail.com
>
<https://groups.google.com/d/msgid/jhipster-dev/CALUG8VvJC7B%3D9qhY-KaCgdP_kYMw2suNYo7XYBaGk6Lmpw1XMA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
signature.asc

Frederik Hahne

unread,
May 14, 2020, 2:47:49 PM5/14/20
to JHipster dev team
Hi everyone,

should we do a new try for a new release? Tomorrow Michael will talk about SDN/RX at spring bridge io and feature jhipster, also with a blod post on neo's medium publication, so I think it would be great to have the latest fixes (reactive, couchbase etc) available for testing during the weekend. I would say the regex PR can be merged. After that release we can focus on reactive entities for sql (seems shaping quite well, but I think it may take some time still). Also we should get https://github.com/jhipster/generator-jhipster/pull/11708 this out imho.
>> @Grimaud Pascal <mailto:pascal.grimaud@gmail.com> You're right,

>> écrit :
>>
>> I'm not totally agreeing for VueJS, for 2 reasons:
>>
>> - You cannot mix blueprints. So you wouldn't be able to use VueJS
>> with Micronaut or Quarkus. - It's only a marketing thing, but for
>> big options like this, it's better to have them out of the box,
>> if we want people to think they are fully stable and supported
>>
>> Julien
>>
>> Le lun. 27 avr. 2020 à 10:16, Frederik Hahne

>> écrit :
>>
>> I would also like to keep vue as a blueprint. With that we are
>> more flexible, e.g. using cypress instead of protractor. Or just
>> supporting some options. On 4/27/20 10:08 AM, Pascal GRIMAUD
>> wrote:
>>> I agree about Vue.js too. I'm changing my mind : it works too
>>> well in
>> blueprint today and I think
>>> it should stay like this...
>>>
>>> Le lun. 27 avr. 2020 à 10:04, Deepu K Sasidharan
>>> <deepu.k.s...@gmail.com

>> <mailto:julien.dubois@gmail.com>>> wrote:
>>>
>>> Oh Pascal you are totally right
>> about the options: for JHipster
>>> 7, we should remove options. But
>> it's always very hard to do!!!!
>>>
>>> Le lun. 27 avr. 2020 à 09:51, Pascal
>> GRIMAUD
>>> <pascal....@gmail.com

>> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>>.
>>>> To view this
>> discussion on the web
>>>>
>> visit
>> https://groups.google.com/d/msgid/jhipster-dev/A7D37F67-FBE0-4CC6-B10
1-A70D8AFD0A1B%40raibledesigns.com

>>
>>
>>
>> <https://groups.google.com/d/msgid/jhipster-dev/A7D37F67-FBE0-4CC6-B1
01-A70D8AFD0A1B%40raibledesigns.com?utm_medium=email&utm_source=footer
>.
>>
>>
>>
>>>> -- Julien Dubois
>>>>
>>>> Twitter: @juliendubois
>>>>
>> <http://twitter.com/#!/juliendubois>
>>>>
>>>
>>> -- 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
>>>

Frederik Hahne

unread,
May 14, 2020, 2:51:16 PM5/14/20
to jhipst...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Also we should have a look at the two new bugs (TS) which make the
sample app fail the sonar quality gate:

https://sonarcloud.io/project/issues?id=jhipster-sample-application&reso
lved=false&types=BUG

On 5/14/20 8:47 PM, Frederik Hahne wrote:
> Hi everyone,
>
> should we do a new try for a new release? Tomorrow Michael will
> talk about SDN/RX at spring bridge io and feature jhipster, also
> with a blod post on neo's medium publication, so I think it would
> be great to have the latest fixes (reactive, couchbase etc)
> available for testing during the weekend. I would say the regex PR
> can be merged. After that release we can focus on reactive entities
> for sql (seems shaping quite well, but I think it may take some
> time still). Also we should get
> https://github.com/jhipster/generator-jhipster/pull/11708 this out
> imho.
>
> Am Donnerstag, 7. Mai 2020 23:08:01 UTC+2 schrieb Pascal GRIMAUD:
>
> With the release of Spring Boot 2.7, we are ready for the release.
> But I saw this ticket:
> https://github.com/jhipster/generator-jhipster/issues/11726
> <https://github.com/jhipster/generator-jhipster/issues/11726> I
> think it needs to be fixed before the next release, right ?
>
> I can launch the release tomorrow (friday), or this week-end. Just
> tell me what is the best for the project.
>
>
>
> Le lun. 4 mai 2020 à 19:07, Pascal GRIMAUD
> <pascal....@gmail.com <mailto:pascal....@gmail.com>> a
> écrit :
>
> Ok thanks. I'm preparing the other projects, and waiting Spring
> Boot 2.2.7 so !
>
>
> Le lun. 4 mai 2020 à 19:03, Daniel Franco <dandr...@gmail.com
> <mailto:dandr...@gmail.com>> a écrit :
>
> Next Thursday May 07th, spring-boot 2.2.7 will be out, and I will
> update it on Friday the last. So, for me it is OK after this small
> upgrade.
>
> Then we can focus on the update to spring-boot 2.3.0 for next
> release.
>
> Frederik Hahne <frederi...@gmail.com
> <mailto:frederi...@gmail.com>> escreveu no dia segunda,
> 4/05/2020 à(s) 17:53:
>
> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>
> I will try to get the neo4j heroku support out tonight. The other
> open bug is not critical right now, will fix it after my talk on
> friday. Maybe Michael from the neo4 team will pick it up too. They
> both are very interested in making neo4j & jhipster a success
> story .
>
> best regards
>
> Fred
>
>
> On 5/4/20 6:30 PM, Pascal GRIMAUD wrote:
>> Hi all,
>>
>> I'm on vacations this week, but stay at home :-) I'll
> time to do a
>> release before friday. Are you all ok ? No blocking
> issue ?
>>
>> Pascal
>>
>> Le sam. 2 mai 2020 à 16:32, Matt Raible
> <ma...@raibledesigns.com <mailto:ma...@raibledesigns.com>
>> <mailto:ma...@raibledesigns.com
> <mailto:ma...@raibledesigns.com>>> a écrit :
>>
>> I'd like to bring this thread back to the 6.9.0
> release. If you
>> have demos or articles you're writing in the next few
> weeks, now
>> would be a good time to test your code using the
> master branch. I
>> have a few:
>>
>> * Build a React + Node.js app for Scotch.io * Reactive
>> Microservices * Micronaut monolith
>>
>> Of course, I'll be using OAuth for both. I haven't
> decided which
>> web frameworks to use for the last two, but Angular +
> Micronaut
>> might be best for the widest audience.
>>
>> I'll do my best to test these combinations in the next
> few days.
>>
>> Cheers,
>>
>> Matt
>>
>>> On Apr 27, 2020, at 03:59, mathi...@free.fr
> <mailto:mathi...@free.fr>
>>> <mailto:mathi...@free.fr
>>> <mailto:cmor...@gmail.com
> <mailto:cmor...@gmail.com>>> a écrit :
>>>
>>> @Grimaud Pascal <mailto:pascal....@gmail.com
> <mailto:pascal....@gmail.com>> You're right,
>>> <mailto:anth....@gmail.com
> <mailto:anth....@gmail.com>>> a écrit :
>>>
>>> Anyway, I'm agree with both Frederik and Pascal.
> Sometimes it
>>> feels our templates are a little bit complex because
> of mixing
>>> options. For exemple, is it necessary to have such
> caching
>>> options that we have ? I'm not sure. In the meantime,
> if we
>>> reduce the number of options, we will have a less
> good marketing
>>> visibility....
>>>
>>> It's not easy to balance....
>>>
>>> Le lun. 27 avr. 2020 à 10:24, Anthony Viard
> <anth....@gmail.com <mailto:anth....@gmail.com>
>>> <mailto:anth....@gmail.com
> <mailto:anth....@gmail.com>>> a écrit :
>>>
>>> "You cannot mix blueprints. So you wouldn't be able
> to use VueJS
>>> with Micronaut or Quarkus." This is not really true
> anymore, the
>>> blueprint flag ("--blueprints" accept a list of
> blueprint). But
>>> we cannot be sure that blueprints are compatible...
>>>
>>> Le lun. 27 avr. 2020 à 10:20, Julien Dubois
>>> <julien...@gmail.com
> <mailto:julien...@gmail.com> <mailto:julien...@gmail.com
> <mailto:julien...@gmail.com>>> a
>>> écrit :
>>>
>>> I'm not totally agreeing for VueJS, for 2 reasons:
>>>
>>> - You cannot mix blueprints. So you wouldn't be able
> to use VueJS
>>> with Micronaut or Quarkus. - It's only a marketing
> thing, but for
>>> big options like this, it's better to have them out
> of the box,
>>> if we want people to think they are fully stable and
> supported
>>>
>>> Julien
>>>
>>> Le lun. 27 avr. 2020 à 10:16, Frederik Hahne
>>> <frederi...@gmail.com
> <mailto:frederi...@gmail.com> <mailto:frederi...@gmail.com
> <mailto:frederi...@gmail.com>>> a
>>> écrit :
>>>
>>> I would also like to keep vue as a blueprint. With
> that we are
>>> more flexible, e.g. using cypress instead of
> protractor. Or just
>>> supporting some options. On 4/27/20 10:08 AM, Pascal
> GRIMAUD
>>> wrote:
>>>> I agree about Vue.js too. I'm changing my mind : it
> works too
>>>> well in
>>> blueprint today and I think
>>>> it should stay like this...
>>>>
>>>> Le lun. 27 avr. 2020 à 10:04, Deepu K Sasidharan
>>>> <deepu.k.s...@gmail.com
> <mailto:deepu.k.s...@gmail.com>
> <mailto:deepu.k.s...@gmail.com>>>> a
> <mailto:julien...@gmail.com>
>>> <mailto:julien...@gmail.com
> <mailto:julien...@gmail.com>>
>>>> <mailto:julien...@gmail.com
> <mailto:julien...@gmail.com>
>>> <mailto:julien...@gmail.com
> <mailto:julien...@gmail.com>>>> wrote:
>>>>
>>>> Oh Pascal you are totally right
>>> about the options: for JHipster
>>>> 7, we should remove options. But
>>> it's always very hard to do!!!!
>>>>
>>>> Le lun. 27 avr. 2020 à 09:51, Pascal
>>> GRIMAUD
>>>> <pascal....@gmail.com
> <mailto:pascal....@gmail.com>
> <mailto:pascal....@gmail.com>>>> a
> <mailto:cmor...@gmail.com>> <mailto:cmor...@gmail.com
> <mailto:ma...@raibledesigns.com>> <mailto:ma...@raibledesigns.com
> <mailto:ma...@raibledesigns.com>
>>> <mailto:ma...@raibledesigns.com
> <mailto:ma...@raibledesigns.com>>>>
>>>> a écrit :
>>>>
>>>> I’ve tested jhipster.org <http://jhipster.org>
>>> <http://jhipster.org> <http://jhipster.org> and I
>>>> was able to send it in a
>>> message on Facebook.
>>>> However, when I checked it
>>>>
>>> at https://developers.facebook.com/tools/debug/
> <https://developers.facebook.com/tools/debug/>, it
>>>> says it contains a
>>> blocked URL. Maybe because it
>>>> redirects to
>>> jhipster.tech <http://jhipster.tech>?
>>>> It could also be because
>>> it doesn’t use HTTPS. It
>>>> says jhipster.tech
>>> <http://jhipster.tech> is blocked
>>>> and I’ve reported it as
>>> a mistake (a couple of times
>>>> now).
>>>>
>>>>
>>>
> https://developers.facebook.com/tools/debug/?q=https%3A%2F%2Fjhipster
>
>
<https://developers.facebook.com/tools/debug/?q=https%3A%2F%2Fjhipster>
> .tech
>>>
>>>
>>
>>>
> <https://developers.facebook.com/tools/debug/?q=https://jhipster.tech
>
>
<https://developers.facebook.com/tools/debug/?q=https://jhipster.tech>
>>
>>>
>>>
>>
>>>>> On Apr 26, 2020, at
>>> 1:32 PM, Julien Dubois
>>>>>
>>> <julien...@gmail.com
> <mailto:julien...@gmail.com> <mailto:julien...@gmail.com
> <mailto:julien...@gmail.com>>
>>>>>
>>> <mailto:julien...@gmail.com
> <mailto:julien...@gmail.com>
>>> <mailto:julien...@gmail.com
> <mailto:julien...@gmail.com>>>> wrote:
>>>>>
>>>>> Hey Matt,
>>>>>
>>>>> Are you sure it won’t
>>> happen with a .org? How can
>>>>> we better understand
>>> the cause of this issue?
>>>>>
>>>>> Julien
>>>>>
>>>>> Le sam. 25 avr. 2020 à
>>> 17:41, Matt Raible
>>>>> <ma...@raibledesigns.com <mailto:ma...@raibledesigns.com>
>>> <mailto:ma...@raibledesigns.com
> <mailto:ma...@raibledesigns.com>>
>>>>>
> <mailto:ma...@raibledesigns.com>>>>
>>> a écrit :
>>>>>
>>>>> OMG, so annoying!
>>> It happened again with a FB
>>>>> comment this
>>> morning. 🤬
>>>>>
>>>>> I'm willing to
>>> donate jhipster.org <http://jhipster.org>
> <http://jhipster.org>
>>>>>
>>> <http://jhipster.org/>! Or maybe just use it
>>>>> to redirect
>>> requests. 😊
>>>>>
>>>>> <image0.png>
>>>>>
>>>>>> On Apr 24, 2020,
>>> at 13:51, Matt Raible
>>>>>>
>>> <ma...@raibledesigns.com
> <mailto:ma...@raibledesigns.com> <mailto:ma...@raibledesigns.com
> <mailto:ma...@raibledesigns.com>>
>>>>>>
> <mailto:ma...@raibledesigns.com>>>>
>>> wrote:
>>>>>>
>>>>>> Comments below
>>> regarding micro frontends and
>>>>>> our package name.
>>>>>>
>>>>>>> On Apr 20, 2020,
>>> at 12:56 PM, Frederik Hahne
>>>>>>>
>>> <frederi...@gmail.com
> <mailto:frederi...@gmail.com> <mailto:frederi...@gmail.com
> <mailto:frederi...@gmail.com>>
>>>>>>>
>>> <mailto:frederi...@gmail.com
> <mailto:frederi...@gmail.com>
>>> <mailto:frederi...@gmail.com
> <mailto:jhipster-dev%252Buns...@googlegroups.com>>>.
>>>>> To view this
>>> discussion on the web
>>>>>
>>> visit
>>>
> https://groups.google.com/d/msgid/jhipster-dev/A7D37F67-FBE0-4CC6-B10
>
>
1-A70D8AFD0A1B%40raibledesigns.com
> <https://groups.google.com/d/msgid/jhipster-dev/A7D37F67-FBE0-4CC6-B10
1-A70D8AFD0A1B%40raibledesigns.com>
>
>
>>
>>>
>>>
>>>
> <https://groups.google.com/d/msgid/jhipster-dev/A7D37F67-FBE0-4CC6-B1
>
>
01-A70D8AFD0A1B%40raibledesigns.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/jhipster-dev/A7D37F67-FBE0-4CC6-B10
1-A70D8AFD0A1B%40raibledesigns.com?utm_medium=email&utm_source=footer>>.
>
>
>>
>>>
>>>
>>>>> -- Julien Dubois
>>>>>
>>>>> Twitter: @juliendubois
>>>>>
>>> <http://twitter.com/#!/juliendubois
> <http://twitter.com/#!/juliendubois>>
>>>>>
>>>>
>>>> -- 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
>>>>
> <mailto:jhipster-dev%252Buns...@googlegroups.com>>>.
>>>> To view this discussion
>>> on the web visit
>>>>
>>>
> https://groups.google.com/d/msgid/jhipster-dev/C689A559-051F-4B8E-A08
>
>
0-A0947910861E%40raibledesigns.com
> <https://groups.google.com/d/msgid/jhipster-dev/C689A559-051F-4B8E-A08
0-A0947910861E%40raibledesigns.com>
>
>
>>
>>>
>>
>>> <<a
> href="https://groups.google.com/d/msgid/jhipster-dev/C689A559-051F-4B8
E-A080-A0947910861E%40raibled
>
>
<https://groups.google.com/d/msgid/jhipster-dev/C689A559-051F-4B8E-A080-
A0947910861E%40raibled>
>
> -- 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
> <mailto:jhipster-dev...@googlegroups.com>. To view this
> discussion on the web visit
> https://groups.google.com/d/msgid/jhipster-dev/38f597d1-4e59-4a63-8082
- -5277d317b822%40googlegroups.com
>
>
<https://groups.google.com/d/msgid/jhipster-dev/38f597d1-4e59-4a63-8082-
5277d317b822%40googlegroups.com?utm_medium=email&utm_source=footer>.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE5wKhRPm9hGEZmys4m4lX4DKXpcUFAl69kxgACgkQm4lX4DKX
pcVBSA//WR1rzGz27wKLhVG+oFFp2i916LNp/UZFpYT3Ob4xDbjudetIFUFLJRYi
qv0sI99k9k6HtClkx2d5bimK2rC0M51Oh/vewR3fcN3b8SeMFGEBLVC4mMfpFIoY
7kFUcsVYFBDPQvGobMdArbE7eDPz/IL1SQKFwK97p1Vhi52JeGO7TNwUbwUTSd0T
YFRvVViZHq7SYk6hJbl8mKppq65loom6QLfu7Dj0P2mGBfXUBWN1Kv+ROCjolMP/
MnTZPebS+NTNMXMVfJEbcaeqltDxK9FxTYn5SIF3QImfG97wICjgGrFiifLgQGbc
7+CDWWlVJ1a+2+xxIi2ReKYrhCjEHzxHPBlcwq1iDvHQc7rR/kBPsPDST1+SpHg7
ZlU4TYBD5EEtwCRSrtGVkH6bqvVk3lNc6G7V/pCO32tZ6qHQgsR27ZOXg+u1MSdJ
YSibxOTekG2zzrupgixOuN0idaNFkUVO9D3fZUgQxBg/h16u9uo2VOhvQb7Dviuo
3Ta/LUXPgJMcReJgDRAIevID2vJX5h+EBv2lxWoKiG9sMyjog+DXstOJ2yn0hDcq
Z3zmZ1iIZueBZ4wWJgs4h35l6P1smQiLajsHnmUIpIR0OH+Ba3IE2cXs7KFvvO1H
FFaRAKpKd+InhTHyG7PRVyEoRhnJCvrwPQGxAyDrwaMv/O2/hsw=
=3sSA
-----END PGP SIGNATURE-----

Pascal GRIMAUD

unread,
May 14, 2020, 2:53:58 PM5/14/20
to Frederik Hahne, JHipster dev team
I'm waiting for your 'go'...
Just tell me if needed the release tonight but don't decide too late plz :) 

>> @Grimaud Pascal <mailto:pascal....@gmail.com> You're right,

>> écrit :
>>
>> I'm not totally agreeing for VueJS, for 2 reasons:
>>
>> - You cannot mix blueprints. So you wouldn't be able to use VueJS
>> with Micronaut or Quarkus. - It's only a marketing thing, but for
>> big options like this, it's better to have them out of the box,
>> if we want people to think they are fully stable and supported
>>
>> Julien
>>
>> Le lun. 27 avr. 2020 à 10:16, Frederik Hahne

>> écrit :
>>
>> I would also like to keep vue as a blueprint. With that we are
>> more flexible, e.g. using cypress instead of protractor. Or just
>> supporting some options. On 4/27/20 10:08 AM, Pascal GRIMAUD
>> wrote:
>>> I agree about Vue.js too. I'm changing my mind : it works too
>>> well in
>> blueprint today and I think
>>> it should stay like this...
>>>
>>> Le lun. 27 avr. 2020 à 10:04, Deepu K Sasidharan
>>> <deepu.k.s...@gmail.com
>> <mailto:julien...@gmail.com>
>>> <mailto:julien...@gmail.com

>> <mailto:julien...@gmail.com>>> wrote:
>>>
>>> Oh Pascal you are totally right
>> about the options: for JHipster
>>> 7, we should remove options. But
>> it's always very hard to do!!!!
>>>
>>> Le lun. 27 avr. 2020 à 09:51, Pascal
>> GRIMAUD
>>> <pascal....@gmail.com
>> <mailto:pascal....@gmail.com>
>> <mailto:pascal....@gmail.com
>> <mailto:pascal....@gmail.com>>> a
>> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>>.
>>>> To view this
>> discussion on the web
>>>>
>> visit
>> https://groups.google.com/d/msgid/jhipster-dev/A7D37F67-FBE0-4CC6-B10
1-A70D8AFD0A1B%40raibledesigns.com

>>
>>
>>
>> <https://groups.google.com/d/msgid/jhipster-dev/A7D37F67-FBE0-4CC6-B1
01-A70D8AFD0A1B%40raibledesigns.com?utm_medium=email&utm_source=footer
>.
>>
>>
>>
>>>> -- Julien Dubois
>>>>
>>>> Twitter: @juliendubois
>>>>
>> <http://twitter.com/#!/juliendubois>
>>>>
>>>
>>> -- 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
>>>

--
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/38f597d1-4e59-4a63-8082-5277d317b822%40googlegroups.com.

Frederik Hahne

unread,
May 14, 2020, 2:58:31 PM5/14/20
to JHipster dev team
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

You have my go. I thought Matt wanted to wait for reactive sql entities.

Tonight is not needed, tomorrow or even saturday would be fine.

On 5/14/20 8:53 PM, Pascal GRIMAUD wrote:
> I'm waiting for your 'go'... Just tell me if needed the release
> tonight but don't decide too late plz :)
>
> Le jeu. 14 mai 2020 à 20:47, Frederik Hahne
> <frederi...@gmail.com <mailto:frederi...@gmail.com>> a
> écrit :
>
> Hi everyone,
>
> should we do a new try for a new release? Tomorrow Michael will
> talk about SDN/RX at spring bridge io and feature jhipster, also
> with a blod post on neo's medium publication, so I think it would
> be great to have the latest fixes (reactive, couchbase etc)
> available for testing during the weekend. I would say the regex PR
> can be merged. After that release we can focus on reactive entities
> for sql (seems shaping quite well, but I think it may take some
> time still). Also we should get
> https://github.com/jhipster/generator-jhipster/pull/11708 this out
> imho.
>
> Am Donnerstag, 7. Mai 2020 23:08:01 UTC+2 schrieb Pascal GRIMAUD:
>
> With the release of Spring Boot 2.7, we are ready for the release.
> But I saw this ticket:
> https://github.com/jhipster/generator-jhipster/issues/11726 I think
> it needs to be fixed before the next release, right ?
>
> I can launch the release tomorrow (friday), or this week-end. Just
> tell me what is the best for the project.
>
>
>
> Le lun. 4 mai 2020 à 19:07, Pascal GRIMAUD
> <pascal....@gmail.com <mailto:pascal....@gmail.com>> a
> écrit :
>
> Ok thanks. I'm preparing the other projects, and waiting Spring
> Boot 2.2.7 so !
>
>
> Le lun. 4 mai 2020 à 19:03, Daniel Franco <dandr...@gmail.com
> <mailto:dandr...@gmail.com>> a écrit :
>
> Next Thursday May 07th, spring-boot 2.2.7 will be out, and I will
> update it on Friday the last. So, for me it is OK after this small
> upgrade.
>
> Then we can focus on the update to spring-boot 2.3.0 for next
> release.
>
> Frederik Hahne <frederi...@gmail.com
> <mailto:frederi...@gmail.com>> escreveu no dia segunda,
> 4/05/2020 à(s) 17:53:
>
> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>
> I will try to get the neo4j heroku support out tonight. The other
> open bug is not critical right now, will fix it after my talk on
> friday. Maybe Michael from the neo4 team will pick it up too. They
> both are very interested in making neo4j & jhipster a success
> story .
>
> best regards
>
> Fred
>
>
> On 5/4/20 6:30 PM, Pascal GRIMAUD wrote:
>> Hi all,
>>
>> I'm on vacations this week, but stay at home :-)
> I'll time to do a
>> release before friday. Are you all ok ? No
> blocking issue ?
>>
>> Pascal
>>
>> Le sam. 2 mai 2020 à 16:32, Matt Raible
> <ma...@raibledesigns.com <mailto:ma...@raibledesigns.com>
>> <mailto:ma...@raibledesigns.com
> <mailto:ma...@raibledesigns.com>>> a écrit :
>>
>> I'd like to bring this thread back to the 6.9.0
> release. If you
>> have demos or articles you're writing in the next
> few weeks, now
>> would be a good time to test your code using the
> master branch. I
>> have a few:
>>
>> * Build a React + Node.js app for Scotch.io * Reactive
>> Microservices * Micronaut monolith
>>
>> Of course, I'll be using OAuth for both. I haven't
> decided which
>> web frameworks to use for the last two, but
> Angular + Micronaut
>> might be best for the widest audience.
>>
>> I'll do my best to test these combinations in the
> next few days.
>>
>> Cheers,
>>
>> Matt
>>
>>> On Apr 27, 2020, at 03:59, mathi...@free.fr
> <mailto:mathi...@free.fr>
>>> <mailto:mathi...@free.fr
>>> <mailto:cmor...@gmail.com
> <mailto:cmor...@gmail.com>>> a écrit :
>>>
>>> @Grimaud Pascal <mailto:pascal....@gmail.com
>>> <mailto:anth....@gmail.com
> <mailto:anth....@gmail.com>>> a écrit :
>>>
>>> Anyway, I'm agree with both Frederik and Pascal.
> Sometimes it
>>> feels our templates are a little bit complex
> because of mixing
>>> options. For exemple, is it necessary to have
> such caching
>>> options that we have ? I'm not sure. In the
> meantime, if we
>>> reduce the number of options, we will have a less
> good marketing
>>> visibility....
>>>
>>> It's not easy to balance....
>>>
>>> Le lun. 27 avr. 2020 à 10:24, Anthony Viard
> <anth....@gmail.com <mailto:anth....@gmail.com>
>>> <mailto:anth....@gmail.com
> <mailto:anth....@gmail.com>>> a écrit :
>>>
>>> "You cannot mix blueprints. So you wouldn't be
> able to use VueJS
>>> with Micronaut or Quarkus." This is not really
> true anymore, the
>>> blueprint flag ("--blueprints" accept a list of
> blueprint). But
>>> we cannot be sure that blueprints are compatible...
>>>
>>> Le lun. 27 avr. 2020 à 10:20, Julien Dubois
>>> <julien...@gmail.com
> <mailto:julien...@gmail.com> <mailto:julien...@gmail.com
> <mailto:julien...@gmail.com>>> a
>>> écrit :
>>>
>>> I'm not totally agreeing for VueJS, for 2 reasons:
>>>
>>> - You cannot mix blueprints. So you wouldn't be
> able to use VueJS
>>> with Micronaut or Quarkus. - It's only a
> marketing thing, but for
>>> big options like this, it's better to have them
> out of the box,
>>> if we want people to think they are fully stable
> and supported
>>>
>>> Julien
>>>
>>> Le lun. 27 avr. 2020 à 10:16, Frederik Hahne
>>> <frederi...@gmail.com
> <mailto:frederi...@gmail.com> <mailto:frederi...@gmail.com
> <mailto:cmor...@gmail.com>> <mailto:cmor...@gmail.com
> <mailto:ma...@raibledesigns.com>> <mailto:ma...@raibledesigns.com
>>> <mailto:julien...@gmail.com
> <mailto:julien...@gmail.com>
>>> <mailto:julien...@gmail.com
> <mailto:julien...@gmail.com>>>> wrote:
>>>>>
>>>>> Hey Matt,
>>>>>
>>>>> Are you sure it won’t
>>> happen with a .org? How can
>>>>> we better understand
>>> the cause of this issue?
>>>>>
>>>>> Julien
>>>>>
>>>>> Le sam. 25 avr. 2020 à
>>> 17:41, Matt Raible
>>>>> <ma...@raibledesigns.com
> <mailto:ma...@raibledesigns.com>
>>> <mailto:ma...@raibledesigns.com
> <mailto:ma...@raibledesigns.com>>
>>>>>
> <mailto:ma...@raibledesigns.com>>>>
>>> a écrit :
>>>>>
>>>>> OMG, so annoying!
>>> It happened again with a FB
>>>>> comment this
>>> morning. 🤬
>>>>>
>>>>> I'm willing to
>>> donate jhipster.org <http://jhipster.org>
> <http://jhipster.org>
>>>>>
>>> <http://jhipster.org/>! Or maybe just use it
>>>>> to redirect
>>> requests. 😊
>>>>>
>>>>> <image0.png>
>>>>>
>>>>>> On Apr 24, 2020,
>>> at 13:51, Matt Raible
>>>>>>
>>> <ma...@raibledesigns.com
> <mailto:ma...@raibledesigns.com> <mailto:ma...@raibledesigns.com
> <mailto:ma...@raibledesigns.com>>
>>>>>>
> <mailto:jhipster-dev%252Buns...@googlegroups.com>>>.
>>>>> To view this
>>> discussion on the web
>>>>>
>>> visit
>>>
> https://groups.google.com/d/msgid/jhipster-dev/A7D37F67-FBE0-4CC6-B10
>
>
1-A70D8AFD0A1B%40raibledesigns.com
> <https://groups.google.com/d/msgid/jhipster-dev/A7D37F67-FBE0-4CC6-B10
1-A70D8AFD0A1B%40raibledesigns.com>
>
>
>>
>>>
>>>
>>>
> <https://groups.google.com/d/msgid/jhipster-dev/A7D37F67-FBE0-4CC6-B1
>
>
01-A70D8AFD0A1B%40raibledesigns.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/jhipster-dev/A7D37F67-FBE0-4CC6-B10
1-A70D8AFD0A1B%40raibledesigns.com?utm_medium=email&utm_source=footer>>.
>
>
>>
>>>
>>>
>>>>> -- Julien Dubois
>>>>>
>>>>> Twitter: @juliendubois
>>>>>
>>> <http://twitter.com/#!/juliendubois>
>>>>>
>>>>
>>>> -- 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
> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>
>>>
> <mailto:jhipster-dev%252Buns...@googlegroups.com>>>.
>>>> To view this discussion
>>> on the web visit
>>>>
>>>
> https://groups.google.com/d/msgid/jhipster-dev/C689A559-051F-4B8E-A08
>
>
0-A0947910861E%40raibledesigns.com
> <https://groups.google.com/d/msgid/jhipster-dev/C689A559-051F-4B8E-A08
0-A0947910861E%40raibledesigns.com>
>
>
>>
>>>
>>
>>> <<a
> href="https://groups.google.com/d/msgid/jhipster-dev/C689A559-051F-4B8
E-A080-A0947910861E%40raibled
>
> -- 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
> <mailto:jhipster-dev...@googlegroups.com>. To view this
> discussion on the web visit
iQIzBAEBCAAdFiEE5wKhRPm9hGEZmys4m4lX4DKXpcUFAl69lNEACgkQm4lX4DKX
pcWSshAAnwvcVussmHdTf2MMj+teUMP+sTqks1FvDVu/Unk9pgWeL4Beo1Uc6C2x
9XueuFz2Tzx6JvMRT5LQ3Ul8uxWw1EcTfoVCGW9HRvptBmrY+e3IdzHgahW4ricV
wJG/rxFhNM5maAyoZsQBgxIBAzrKKsnxBuj1xlTGWONFG1JNBffsY8VcYnoHcf5x
jEpgnk62vlgtYIhJMN2JUu46FN6SyJvQ38QZCf8YZmTNBt/Uo7354dz9IVQToJpR
m1RHlEHa8OUIzlwKC+M89S7WjeZAd2rgxQx/1eeHLQHbHuu1jr1D0ZCzIRlMIVZ7
sZx9BPMBYYN2t5TOMB49wAk6iPm9atWFx7uHiLJhIdXBKiVCjcu+E6W2TOaO6DPq
CdMy4fQMBsFC0Cnr6t7Qb7Zf/1/vXjwNpfnRJO4Jb4af01d2fwMQagnozTbfTWy0
nXGIPbe0vqkPlnDfweVDa5LRubLX8WY/RWR78a0a9ecP4VieRInENWr4XzZGkSJn
dFtE15ObhUgoIDbQ1dyRVJD0WvBmlkodGxBhLBtAkPXPv0Sxz0po0fff+VnGbKZX
coU7GzAXIToi5/3xujD2pIug1++T1FweL9IDyZffLoYjiiz/m6uYqTKvqVyDweCq
Z8YoYISbQGZU+zojSancQCb4zgGUKAFPzDKmtr3aafqNIaur8ZE=
=VZxb
-----END PGP SIGNATURE-----

Pascal GRIMAUD

unread,
May 14, 2020, 3:01:05 PM5/14/20
to Frederik Hahne, JHipster dev team
Oh I read too quickly.
I'll have time this weekend, so saturday could be the target so

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/f190c38b-f6e1-fd0d-612a-67ec44d18b90%40gmail.com.

Matt Raible

unread,
May 14, 2020, 3:31:35 PM5/14/20
to Frederik Hahne, JHipster dev team
Here’s the PR for entities with R2DBC:


It looks like the webflux-psql test is failing because of the null ID. I’m looking into this now. The other failures seems to be Cassandra (which often fails) and starting Docker containers on Azure DevOps. I don’t seem to have permissions to restart the Azure jobs. Maybe someone else does?

Cheers,

Matt

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/f190c38b-f6e1-fd0d-612a-67ec44d18b90%40gmail.com.

Kaido Hallik

unread,
May 15, 2020, 2:16:41 AM5/15/20
to Frederik Hahne, jhipst...@googlegroups.com
This is a false positive:
https://github.com/SonarSource/SonarJS/issues/1930

Current suggestion from Sonar is to remove this check from quality gate
while this new Typescript feature is not correctly supported by Sonar.

One alternative solution: add //NOSONAR to those optional call lines to
force Sonar ignore these lines. WDYT?

Kaido.

Pascal GRIMAUD

unread,
May 15, 2020, 2:33:34 AM5/15/20
to Kaido Hallik, Frederik Hahne, JHipster dev team
Adding NOSONAR to these lines, sounds good

--
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/em386409d5-a418-4c5c-b951-941dce724bfa%40sille.

Aurélien Mino

unread,
May 15, 2020, 2:47:57 AM5/15/20
to Matt Raible, Frederik Hahne, JHipster dev team
IMO this PR is not ready (it's still WIP), there are a lot issues to resolve, mainly because the R2BC landscape is not mature enough.
Let's release 6.9.0 without it, integrates Spring Boot 2.3 in master and then finish this PR that will benefits from fixes and new features from Spring Data R2BC pulled by Spring Boot 2.3.

Aurélien

Matt Raible

unread,
May 15, 2020, 6:09:18 AM5/15/20
to Aurélien Mino, Frederik Hahne, JHipster dev team
This is OK with me!

On May 15, 2020, at 00:47, Aurélien Mino <aureli...@gmail.com> wrote:



Pascal GRIMAUD

unread,
May 17, 2020, 3:49:08 AM5/17/20
to Matt Raible, Aurélien Mino, Frederik Hahne, JHipster dev team
Hello all,

I'm going to do the release in few hours : v6.9.0
I'm doing to do some tests first.
Plz, don't merge anything on master, unless it's total necessary.

Pascal 

Julien Dubois

unread,
May 17, 2020, 3:49:55 AM5/17/20
to Pascal GRIMAUD, Aurélien Mino, Frederik Hahne, JHipster dev team, Matt Raible
Reply all
Reply to author
Forward
0 new messages