With the launch of new spring-boot 2.1.0, it is time to continue the work started in https://github.com/jhipster/generator-jhipster/issues/8047.
See: https://spring.io/blog/2018/10/30/spring-boot-2-1-0 & https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.1-Release-Notes
TODO:
Bonus: JDK9+ compatibility
@jhipster/developers please add here if I missed any evolution/impact
I don't think we _have_ to upgrade to Spring Security's OIDC support, but we certainly can. It will allow users to configure more than one OIDC provider, so if they wanted to add Google or Facebook, they could.
FWIW, I also have global SSO logout working. I'll create a PR for that against the current version sometime this week.
After thinking about this a bit more, I don't think we should upgrade to use Spring Security's OIDC support in a 5.x release. The property names in application.yml
change and this is a breaking change. We should migrate to OIDC (from OAuth 2.0) in 6.x.
@jhipster/developers Anyone might help to fix last issues?
@DanielFran : if needed, we could focus on this, this tuesday at our JHipster Day at Ippon
I'm definitely very interested, I'll have a look during the week.
Actually I have an issue with AsyncLiquibase due to changes with taskexecutor and also an error with missing javassist in classpath... :(
As with Spring Boot 2.1 you can now start Hibernate lazily (they copied on us, 4 years later!), we should refactor or change this anyway.
Because of microservices we will need to wait until the end of the year for Spring Cloud Greenwich to be released : https://github.com/spring-cloud/spring-cloud-release/milestones
So I think we should create a branch and try to get as many things working on it. We can also publish snapshots of jhipster-dependencies based on SC Greenwich milestones to be able to work on it.
Best case scenario we will be able to release Spring Boot 2.1 with jdk11 by Christmas.
We need first to test if there is anything not working using Finchley.SR2 and maybe release an alfa release.
Then if needed, we can already target Greenwich.M1 (List of dependencies used ) or even wait to Nov-15 to target Greenwich.M2 to release a beta release.
Something I noticed in the 2.1 release notes today:
Elasticsearch REST Clients
As an alternative option to Jest, auto-configurations forRestClient
andRestHighLevelClient
are provided with configurable options from thespring.elasticsearch.rest.*
namespace.
I'm not sure that we want to move away from Spring Data Jest for Elasticsearch, but if we do, this option might help with that.
@jdubois @PierreBesson I updated spring-cloud dependency to Greenwish.M2.
Thanks @DanielFran ! Sorry I didn't have the time yet to work on this
@jdubois me neither. It is just that I am stuck with taskexecutor and also an error with missing javassist in classpath... :(
I did quite a number of commits in the Spring Boot 2.1 branches, fixing some JDK 11 issues and Async configuration issues.
There is one big issue with Hazelcast, as it currently does not support Hibernate 5.3 (and we can't downgrade, because Hibernate 5.3 brings JDK 9 support). See https://github.com/hazelcast/hazelcast-hibernate5/issues/44 for more information -> we need to have the solution at https://github.com/hazelcast/hazelcast-hibernate5/pull/48 as using the solution at https://github.com/hazelcast/hazelcast-hibernate5/issues/44#issuecomment-403793289 is not enough for us (as we have a singleton and need to re-use it)
Can't we downgrade Hibernate and stay on JDK8 for now ? (I know :disappointed: ...)
ElasticSearch version is now updated and seems working.
pending issues:
Cassandra doesn't work as Cassandra 3.x does not support Java 9 and above. As we use CassandraUnit in our tests, which runs an embedded Cassandra, there is no way our tests can pass. Java 9+ support is scheduled for Cassandra 4, but there is no release date available as of today. The main solution to me would be to use TestContainers, like we do for Couchbase.
Now I'm going to tell unpleasant things, but as we have full statistics publicly available on https://start.jhipster.tech/#/statistics we can see that, for last month:
Those three options give us a lot of maintenance work, and are probably going to be blockers for our upcoming JDK 11 and Spring Boot 2.1 support. Considering that nearly nobody uses them, and also that they the 3 of them are backed by companies with tons of $$$ which do not contribute at all to the project, I think we should have a clear and open discussion on removing those options. I'll post this on the dev mailing list right now.
Now I'm going to tell unpleasant things, but as we have full statistics publicly available on https://start.jhipster.tech/#/statistics we can see that, for last month:
* Cassandra is used by 0,33% of users * Couchbase is used by 0,17% of users * Infinispan is used by 0,64% of users
Just wondering: what report are you using to retrieve these numbers?
When I use the last year report, I got this:
Just use the one from last month. We have some bad data at the beginning of the year, which explain your higher numbers.
Some news about Elasticsearch :
Both spring data jest and spring data elasticSearch need 6.2.2 elasticSearch API version.
Spring boot 2.1.1.Release set (in Spring boot dependencies POM) the elasticSearch version on 6.4.3.
Unfortunatly the XContentBuilder class has been modified and do not support string() method. String method is using somewhere by spring data jest.
That's why, at startup, spring boot fire an error.
To fix it I have just open a PR (https://github.com/jhipster/jhipster/pull/135) to force the ElasticSearch version on 6.2.2.
At the same time the docker image is not longer working because of version changement (2 to 2.2) and remove "-E" in command. It seems no longer support on ES 6+. #8927
Both docker and embedded ElasticSearch runs should work now.
thanks to @juliensadaoui and @pascalgrimaud for helping 馃憤
I open issue https://github.com/VanRoy/spring-data-jest/issues/102 to fix those issues.
New status:
Partially fixed:
Still KO:
Thanks @DanielFran ! As discussed earlier and on the mailing list, we will remove the Infinspan/Cassandra/Couchbase options, but as cleanly as possible:
About elasticsearch, actually there is no bug, spring-data-elasticsearch Lovelace-SR3 is targetting 6.2.2, so we need to keep using that version instead of 6.4.3 defined in spring-boot 2.1.1.
Upgrade to spring-boot 2.1
@Mahdihp What are you trying to say with this comment and also https://github.com/jhipster/generator-jhipster/issues/5970#issuecomment-444638306 ?
An important thing to do for JDK11 support is to upgrade the docs and recommend to install java throught the adoptopenjdk site.
@PierreBesson We could also just recommend SDKMAN! for Java 11 installation. That's what I use/recommend.
Sdkman will install the Zulu jdk, I think we should recommend the regular jdk install provided by adoptopenjdk. They also have a docker image.
SDKMAN allows OpenJDK as well.
$ sdk list java
================================================================================
Available Java Versions
================================================================================
12.ea.20-open 1.0.0-rc-8-grl
+ 11.ea.26-open
11.0.1-zulu
* 11.0.1-open
+ 11.0.0-open
10.0.2-zulu
10.0.2-open
9.0.7-zulu
9.0.4-open
8.0.192-zulu
8.0.191-oracle
> + 8.0.181-zulu
7.0.181-zulu
1.0.0-rc-10-grl
1.0.0-rc-9-grl
I'm merging #9005 which should fix the Cassandra tests, once a new release of JHipster Dependencies is done.
-> how about a 2.1.0 release of JHipster BOM + framework, which would use Spring Boot 2.1?
Would be awesome! 馃
Do you think we could then create a beta version of the generator?
@DanielFran first I would like a green build of the Spring Boot 2.1 branch of jhipster/jhipster, and then I'll release new versions of JHipster dependencies and framework. And after that, yes we can do beta versions of the generator.
@jhipster/developers all tasks are done!
Sounds great !
when can we expect an official release with spring boot 2.1?
@rburgst : as we work on JHipster during our free time, we can't give you a date. We hope very soon.
If you need it for your projects, you can use master branch ;
Most helpful comment
@jhipster/developers all tasks are done!