jhipster / generator-jhipster-quarkus

Quarkus blueprint for JHipster
https://www.jhipster.tech/blueprints/quarkus/
Apache License 2.0
140 stars 55 forks source link

Generating a blog app with OAuth 2.0 fails to compile #144

Open mraible opened 3 years ago

mraible commented 3 years ago

Describe the bug

I tried generating an app with the blog-oauth2.jdl. It fails to compile.

To Reproduce

jhipster jdl blog-oauth2.jdl --blueprints quarkus

Unfortunately, this results in a compilation error.

[INFO] --- maven-compiler-plugin:3.8.1:compile (default-compile) @ blog ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 30 source files to /Users/mraible/quarkus/target/classes
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] /Users/mraible/quarkus/src/main/java/com/jhipster/demo/blog/domain/Blog.java:[42,12] cannot find symbol
  symbol:   class User
  location: class com.jhipster.demo.blog.domain.Blog
[INFO] 1 error
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  59.470 s
[INFO] Finished at: 2020-12-10T09:09:28-07:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project blog: Compilation failure
[ERROR] /Users/mraible/quarkus/src/main/java/com/jhipster/demo/blog/domain/Blog.java:[42,12] cannot find symbol
[ERROR]   symbol:   class User
[ERROR]   location: class com.jhipster.demo.blog.domain.Blog
[ERROR]
[ERROR] -> [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/MojoFailureException
danielpetisme commented 3 years ago

@mraible as for now the Oauth2 does not produce a User entity as upstream JHipster. I guess in your JDL your Blog entity has a relation to the User entity. That's why it fails by default. Add a custom User entity in your JDL and I'm pretty sure it will work :)

mraible commented 3 years ago

IMO, it should match what the main generator does. The Micronaut blueprint has this capability. I ran it through similar tests when its OAuth support was being developed.

danielpetisme commented 3 years ago

I'm not comfortable with generating User domain object when there is no user management and authentication actually managed by the application. (I'm not with the upstream generator too BTW).

In the Blog sample, we need a user mainly to fullfill the Blog ownership relation. I tend to separate the authentication/authorization aspect of the User from it's data segregation function which is domain dependant.

AFAIK, .Net Core or nodejs blueprints aren't implementing it neither.

mraible commented 3 years ago

Since you're the maintainer of this blueprint, the choice is up to you. I thought it was a cool feature when I added it to the main generator because it allows you to create relationships with the User object, just like you can with JWT authentication. It also works in a microservices architecture.

If you try to create a JWT-based microservice with a relationship to User, the generation succeeds, but the compilation fails (similar to how it does here). I think it'd be better if the generation fails and warns the user before they try to compile.

If you have entities that need a relationship to the current user, how would you suggest a developer implements it?

The "save the user right after they log in" implementation might not be ideal. A better solution would be to use something like Okta Event Hooks which can call an endpoint to sync a user when they're created. However, I don't think Keycloak has anything like that, and it's not a standard part of OAuth.

FWIW, this does work in the Micronaut blueprint. I haven't tested this JDL with the .NET Core or Node.js blueprint, but I'd be happy to sponsor their implementation.