vaadin / hilla

Build better business applications, faster. No more juggling REST endpoints or deciphering GraphQL queries. Hilla seamlessly connects Spring Boot and React to accelerate application development.
https://hilla.dev
Apache License 2.0
879 stars 57 forks source link

Maven Frontend Goals in Hilla Submodule of Multi Module Maven project #1102

Open gitgdako opened 1 year ago

gitgdako commented 1 year ago

Description of the bug

Running Hilla Maven front goals in a Maven Hilla Submodule does not work

Minimal reproducible example

Maven Project Setup Parent: Simple Module without dependencies only containing the submodules:

Expected behavior

Running Maven frontend goals finish the same as if all 3 modules were combined into one

Actual behavior

Calling "mvn hilla:generate" I get

[ERROR] Failed to execute goal on project hilla: Could not resolve dependencies for project com.example.application:hilla:jar:0.0.1-SNAPSHOT: Could not find artifact com.example.application:api:jar:0.0.1-SNAPSHOT in snapshots

Workaround:

mvn install on Parent Module to a local m2 Repo resolves the missing dependencies. This is cumbersome though as these need to be cleaned up for further development

Versions:

- Vaadin / Hilla version: 1.3.15
- Node version: 18.15.0
- Java version: 1.8.0_352

Notes:

Was discussed in https://support.vaadin.com/servicedesk/customer/portal/1/VS-4620 https://support.vaadin.com/servicedesk/customer/portal/1/VS-4612

Reproducer sample was shared via our private GitHub (shared with Tatu)

Ideally this does not break a running server that has hotswap/JRebel running

cromoteca commented 1 year ago

Running mvn hilla:generate in the parent doesn't make much sense to me. Running it in the Hilla module should work like in all other Hilla applications, which means it expects classes to be already there.

cromoteca commented 1 year ago

Can https://github.com/vaadin/hilla/pull/1084 be a solution for your use case?

gitgchpd commented 1 year ago

hello, as a colleague of @gitgdako, #1084 is part of what helps us for our development-cycle but i don't think it will help here.

the reason we need this is that we don't alway want to start out server when we have to implement some frontend stuff. in some cases we just want to start storybook via npm and use that to test our frontent-changes.

in cases were the api-typescript-interfaces hilla generates need to change to implement something that does not suffice though. (even if the files are there from the last server start, it could be that i pulled the latest changes from some other dev and do not want to have to start the server just to generate the latest version of hillas api-typescript-interfaces)

in a multimodule maven project: if i wanted to just compile the sources of one module it would not suffice to just run mvn compile on that modules folder. i would have to run mvn compile -pl :module-artifact --also-make on the root-maven-folder (maven project with packaging "pom").

having hilla in some submodule would require me to do something in line with this. of course i cant run mvn hilla:generate -pl :module-artifact -am because all other modules don't have hilla in their plugin-config. maybe by mapping hilla-generate via profile to some maven phase this would be possible, but i can not find any information about the maven plugin on the internet like https://maven.apache.org/plugins/maven-compiler-plugin/plugin-info.html. maybe it's obvious but for someone with more expertise on maven-plugin configuration but for me it's not

platosha commented 1 year ago

Sounds more like a missing feature around inconveniences with Maven multi module projects rather than a bug.

gitgdako commented 1 year ago

If this can't be done in a meaningful way using Maven we would suggest finding other means to create/update the frontend. We are currently using a selfmade Java Application that basically runs a subset of com.vaadin.flow.server.frontend.NodeTasks (see https://support.vaadin.com/servicedesk/customer/portal/1/VS-4620). If you could integrate (and maintain, which is the hard part for us to accomplish) or reuse that to provide the same functionality of the Maven goal it would solve this issue. Per se we want to