Create a quarkus wrapper script for the Quarkus CLI and add it to the codestarts #37147
Conversation
|
Thanks for your pull request! The title of your pull request does not follow our editorial rules. Could you have a look?
This message is automatically generated by a bot. |
quarkus-bot
bot
added
area/devtools
This comment has been minimized.
This comment has been minimized.
iocanel
force-pushed
the
quarkus-wrapper
branch
2 times, most recently
from
1dc7afa to
396b031
Compare
iocanel
changed the title
This comment has been minimized.
This comment has been minimized.
iocanel
force-pushed
the
quarkus-wrapper
branch
from
396b031 to
7719612
Compare
Failing Jobs - Building 7719612
You can also consult the Develocity build scans. Failures⚙️ JVM Tests - JDK 17 #- Failing: integration-tests/container-image/maven-invoker-way
📦 integration-tests/container-image/maven-invoker-way✖ |
|
Test failures seem unrelated. |
|
Interesting idea. I will test it and report back. |
|
For the Quarkus CLI version, the default is ok, but in usage, I think we should use the Quarkus version from the selected platform when possible? |
I don't fully understand your comment. Can you please elaborate? |
|
Currently in the PR, the version of quarkus-cli will be set to the quarkus-cli (over maven plugin) used to create the project. Maybe we want to use the latest-cli version? or the version chosen for the created project? IMO, we should go for the latest cli version. cc @maxandersen |
The intention here was to use the chosen version for the project, but you are right the creating tool version is used instead. It's not clear to me why this happens as the templates do use
Let's go with the later which was the original intention. I don't want to pull in a 3rd version into the equation (having creating tool version and project version are enough).
|
|
${project.version} is resolved to the quarkus version used during the build of the base codestart artifact (you can keep this as default), but we need to pass the platform version resolved by the tooling when creating the project and pass it as data to the codestart . |
There was a problem hiding this comment.
Im torn on this idea.
I like it because it makes the cli more directly easily available but dont like it because it adds noise to the default generated app and that its "stuck" at a version used when geberating the app.
Shouldnt we start with adding a quarkus wrapper command that generated and User Can set this up if need be?
Ps. Jbang has a wrapper command if You want be inspired :)
| import java.nio.file.StandardCopyOption; | ||
|
|
||
| // An adapted version of the Maven MavenWrapperDownloader for the Quarkus CLI | ||
| public final class MavenWrapperDownloader |
There was a problem hiding this comment.
So This should be named QuarkusWrapperDowbloader?
|
@iocanel @maxandersen What should we do here? |
The missing piece is making the CLI upgradable. |
|
My suggestion was that instead of us adding this by default started by making a Quarkus wrapper command that sets this up. That can be done without requring update feature and enables to do this without changing the defuslt app. |
|
I agree with @maxandersen. Is there an issue with your suggestion? |
It's really handy to have a quarkus-cli wrapper script that can be used OOTB in environments like:
without requiring additional installation tasks, custom container images etc.