Upgrade micronaut 2 to 3

[kevintanhongann]

Changes:

1. upgraded micronaut 2.4.4 to 3.6.0
2. upgraded micronaut data to 3.7.2 to support IgnoreCase queries
3. changed javax.inject packages to jakarta.inject
4. rxjava3 gradle dependency added for less code changes.
5. Auth classes and test classes fixed to the newest version based on the breaking changes migrating from micronaut 2 to 3.
6. defaulted the server port for dev, prod and test to 8080

Closes issue #259

[CLAassistant]

All committers have signed the CLA.

[atomfrede]

👍 impressive work. Awesome.

[kevintanhongann]

@atomfrede @mraible are there any things on the npm side that I should be aware of when I do PRs?

[atomfrede]

Minor comments, regarding other dependencies and version updates

[atomfrede]

In the ci configuration you might update to jhipster 7.9.2

[kevintanhongann]

Okay, I'll look into it.

[atomfrede]

I was wrong we have initial microservice support. So fixing the server port to 8080 will not work.

[atomfrede]

Failing tests look like wrong jdk version. We support jdk11 by default, but of course we can only support jdk17 in this blueprint if needed.

Error:  Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project jhipster: Fatal error compiling: java.lang.NoSuchMethodError: 'void io.micronaut.annotation.processing.visitor.JavaClassElement.<init>(javax.lang.model.element.TypeElement, io.micronaut.core.annotation.AnnotationMetadata, io.micronaut.annotation.processing.visitor.JavaVisitorContext, java.util.Map, int)' -> [Help 1]
Error:  
Error:  To see the full stack trace of the errors, re-run Maven with the -e switch.
Error:  Re-run Maven using the -X switch to enable full debug logging.
Error:  
Error:  For more information about the errors and possible solutions, please read the following articles:
Error:  [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
Error: Process completed with exit code 1.

[kevintanhongann]

Failing tests look like wrong jdk version. We support jdk11 by default, but of course we can only support jdk17 in this blueprint if needed.

Error:  Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project jhipster: Fatal error compiling: java.lang.NoSuchMethodError: 'void io.micronaut.annotation.processing.visitor.JavaClassElement.<init>(javax.lang.model.element.TypeElement, io.micronaut.core.annotation.AnnotationMetadata, io.micronaut.annotation.processing.visitor.JavaVisitorContext, java.util.Map, int)' -> [Help 1]
Error:  
Error:  To see the full stack trace of the errors, re-run Maven with the -e switch.
Error:  Re-run Maven using the -X switch to enable full debug logging.
Error:  
Error:  For more information about the errors and possible solutions, please read the following articles:
Error:  [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
Error: Process completed with exit code 1.

I suppose this is set within github actions samples.yml? The temurin (jdk17) is the version name. Looks like we need to change that.

[atomfrede]

Its set from main generator. But you can set it fixed to 17 here in the gh action: https://github.com/jhipster/generator-jhipster-micronaut/blob/main/.github/workflows/samples.yml#L76

[jeremyg484]

@jeremyg484 I suppose I agree that we can bump the versioning to Micronaut 4 and see what happens. Technically there should not be any major issues. Thoughts everyone?

My thought is actually to keep that in a separate branch for now. Micronaut framework 4 requires Java 17 as a baseline, so there is probably value in still providing support for generating applications that use v3, even though we'd obviously love for everyone to upgrade to v4 as soon as possible.

I wrote most of the Micronaut 3-to-4 OpenRewrite upgrade recipe, so know from experience it's not as simple as just bumping the version. :) There are other adjustments that must be made to mainly build.gradle / pom.xml due to a slightly different structure to all of the platform dependencies.

If we were to want to support both v3 and v4, how would that typically be handled in JHipster? I'm guessing two differently versioned releases of the blueprint?

[kevintanhongann]

@jeremyg484 as far as I observed for jHipster Spring Boot and the Micronaut variant, versioning seems pretty static and jHipster version upgrades along with the backend versions, and you cant specify the spring boot or micronaut version(in this case) that you want.

[jeremyg484]

@kevintanhongann The blueprint is ultimately just distributed as an NPM module, right? So it would appear to me in theory, there could be say a v2.0.0 of the module that generates Micronaut framework 3 apps, and a v3.0.0 that generates Micronaut framework 4 apps and then it's just a matter of giving users the right npm install instructions for their preferred path.

I realize that certainly complicates things as far as maintenance of this repo. I'll leave it up to you and the project maintainers to voice whether the extra complication to support both would be worthwhile for the JHipster community.

My hope is that I can have an alternate Micronaut framework 4 branch of this current code pushed up to my own repo by the end of the day, then you all could take a look at the differences to decide the preferred approach.

[jeremyg484]

A quick update - since the CI workflows haven't executed yet (looks like they're waiting on approval?), I dug in and did some extensive running and testing of the samples myself. Turns out a couple of them are still broken, which isn't surprising as they include options I hadn't manually tested yet. In particular, the Redis sample and the OAuth samples seem to be breaking. I'm still debugging, but will hopefully be able to push more changes to fix those tomorrow.

[atomfrede]

Sorry @jeremyg484 for the late reply. You first wrote on my first day of vacation and I totally forget about it. And I think @mraible is on vacation too. So big thanks for taking care of the micronaut update that's awesome. I would say we just need to support micronaut 4. The next jhipster release 8, which is in beta right now will require Java 17 so no need to create and to support multiple versions of the blueprint.

[jeremyg484]

@atomfrede No worries! That sounds reasonable to me. I'll go ahead and start shifting things to use Micronaut framework 4 alongside working out these remaining issues.

[jeremyg484]

I have a working branch that takes the existing state of this PR and updates everything to Micronaut 4.

https://github.com/jeremyg484/generator-jhipster-micronaut/commits/micronaut-4

As before, the basics are working with manual testing, but I still need to dig in and ensure it passes the CI tests (at the moment it does not).

Once I have that working, how would everyone prefer I proceed? Should I continue pushing to this same PR branch (and we change the title of the PR to "Upgrade micronaut 2 to 4")? That seems like it would be the most straightforward, but I just wanted to check.

[jeremyg484]

@kevintanhongann, @atomfrede, @mraible

Ok, so after some deeper investigation I realize my micronaut-4 branch is missing something fairly crucial, because to this point I'd only been testing it with mhipster jdl default and mhipster jdl default-gradle. I've not done anything yet to modify the way entities are generated such that they use jakarta.* packages instead of javax.* packages. Micronaut framework 4 has transitioned completely to using only jakarta.* packages. So while the base functionality works, the next step beyond that (generating actual domain classes) fails at the moment because everything there is still getting generated with javax.* package imports.

I believe I can see where I could hook in and change the package imports, but is it worth it? Should the Micronaut framework 4 version of this instead be done in a completely separate PR targeting JHipster 8, where that transition already seems to be done?

Your opinions as to the best direction here would be most welcome.

(FYI, I am about to be on vacation for a week myself, so probably won't make much more progress until I return next Tuesday.)

[mraible]

@jeremyg484 Sorry for the delay; I was having a blast on summer vacation.

Ideally, we could merge this PR once everything succeeds and release v2.0 with Micronaut 3 support. Then, merge the next PR to add Micronaut 4 support and release 3.0.

That way, @kevintanhongann could get credit for the work he's done for Micronaut 3. The PR for Micronaut 4 might be helpful for showing folks how to migrate from 3 to 4.

[jeremyg484]

@jeremyg484 Sorry for the delay; I was having a blast on summer vacation.

No worries, I'm about to do the same. Looks like we were typing simultaneously. :) (See my comment just above re: Micronaut 4.)

Ideally, we could merge this PR once everything succeeds and release v2.0 with Micronaut 3 support. Then, merge the next PR to add Micronaut 4 support and release 3.0.

That way, @kevintanhongann could get credit for the work he's done for Micronaut 3.

I agree, that makes sense. I think to get this particular PR done, it will just require getting the Redis and OAuth tests passing, which is probably a lighter lift at this point overall.

The PR for Micronaut 4 might be helpful for showing folks how to migrate from 3 to 4.

Makes sense. I've pushed up the currently generated Micronaut 4 versions of the default samples - they show what is required beyond just running the OpenRewrite recipe (it did do most of the work, but there are some additional dependency conflicts and such that I had to work out in this case).

They are here if anyone wants to take a look - the most notable differences are in the build files:

https://github.com/jeremyg484/jdl-default-maven-micronaut4

https://github.com/jeremyg484/jdl-default-gradle-micronaut4

It kinda sounds like my instinct is right and that we should align Micronaut 4 support with JHipster 8.

[mraible]

It kinda sounds like my instinct is right and that we should align Micronaut support with JHipster 8.

I agree. I'll work on getting this PR to pass all tests this week.

[mraible]

Tests are failing with:

Couldn't find type javax.inject.Singleton. Are you missing a dependency on your classpath?

I'll try adding:

<dependency>
    <groupId>javax.inject</groupId>
    <artifactId>javax.inject</artifactId>
    <version>1</version>
</dependency>

[jeremyg484]

I just sent a PR for a couple other minor fixes to @kevintanhongann's fork. It doesn't resolve the Redis or OAuth tests, but fixes an error I noticed in manually testing the jdl-default-app CI sample and also gets import of Maven projects into IntelliJ working correctly by updating the version of MapStruct.

https://github.com/kevintanhongann/generator-jhipster-micronaut/pull/2

[mraible]

Wahoo! All tests pass, so I'm merging this.

[kevintanhongann]

Awesome job everyone. Glad to see things moving at a faster pace.