-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
draft: add/move hilla dependencies #4953
Changes from 1 commit
cf994c3
40abbdb
4d24b05
46be5b9
9969c77
9f98dd7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -209,6 +209,11 @@ | |
<artifactId>vaadin-menu-bar-flow</artifactId> | ||
</dependency> | ||
|
||
<dependency> | ||
<groupId>com.vaadin.hilla</groupId> | ||
<artifactId>hilla</artifactId> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also I think we have to make changes in
UPD: 5. Flow adds these three react packages (Auto Crud etc.) if There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I would vote against this; or add "if hilla is on the class path" - otherwise flow only apps gets react packages thanks to reactRouterEnabled=true as default There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yes, agree, that's a good point. I proposed to remove npm package annotations and add packages imperatively in NodeUpdater, so that to relief developers from excluding artifacts by themselves. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Updated the wording for 5. |
||
</dependency> | ||
|
||
<dependency> | ||
<groupId>junit</groupId> | ||
<artifactId>junit</artifactId> | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be better to add
hilla
tovaadin
until at least we don't have a split for core and all react components?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, the idea to add
hilla
tovaadin-spring-boot-starter
looks not that bad to me now. As Jakarta EE and Quarkus users can just not addvaadin-spring-boot-starter
to their pom.xml and they won't have Spring and Hilla then.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would also make it pretty easy to exclude hilla by not using
vaadin-spring-boot-starter
because it is only a wrapper forvaadin-spring
,vaadin-core
andhilla
. So the flow developer only has to addvaadin-spring
andvaadin-core
if they don't wanna deal with exclusions.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would also give easy option to divide it in two platform modules like
vaadin-spring-boot-starter
andvaadin-hilla-spring-boot-starter
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea is to use one dependency
vaadin-spring-boot-starter
and avoid "hilla" artifacts, so having a second one with the hilla in the middle is approx. the same as have oldhilla-spring-boot-starter
.