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
Add codestart data option in CLI and Maven plugin #28372
Comments
/cc @ebullient, @maxandersen, @quarkusio/devtools |
Let me know if i pick it up and start working on this. |
Does that mean you have to know each individual codestart's requirements to make this useful? There is already a way to pass in initial configuration with existing options. This seems like something that is useful if you write codestarts frequently, but is difficult to document (where the goal of the CLI, e.g., is to ensure it is generally useful without having to go look at docs). |
The idea is to be able to pass some additional data for a specific extension codestart. AFAIK there's no way to do that right now. |
yes.. can't that be passed in using the existing config mechanism? Something like |
It's not a config property I want. It's something that I can actually use in the templates when generating the project. |
@arpitbhardwaj you can have a look if you can figure out where to do this. |
This might give you a good idea about where to poke: #28325 |
@ia3andy would it not "just work" if you use -D to set properties today? |
@gsmet I thought app config was available to codestarts ? |
I don't want to push these things to the app config. |
but -D are just system properties - shouldn't be ending up in you generated app config. |
i.e.
should be possible to make work. |
So that could work but is there a way to access system properties from the Qute template directly? I might be missing something obvious. |
We could also set them as template values by calling this:
|
But why would we do that instead of something cleaner with the |
We already use -D to pass an arbitrary keys to maven/gradle/jbang so not sure how much value it brings to add yet-another open-ended key/value command option? |
Ok, my concern using plain system properties is that we would have to find a way to filter them before passing them as data to codestarts if we don't want to have weird behaviors. In the top level where we pass the data, we don't know how it will be consumed by codestarts. |
IMO we should reproduce the same syntax as for config on another named option ( We need a new key and setter in the CreateProject for this (like we do for config): Unlike the config this data needs to be directly passed to the builder here: |
@arpitbhardwaj would you give it a try? |
Yeah I will it a try. Currently setting up the environment. |
@arpitbhardwaj any update on this? |
I'd really like to have it for 2.15 so I think I will drive this puppy home. |
I created a PR here: #29644 . |
Just to be clear - my suggestion was not to use global system properties. Simply that -D is defining data keys for the command. What is the difference now between --data and -D ? |
so I now got to import the code and realize that -D already exist in more generic form. somehow I had in my head for codestarts we had separate dedicated command. so all good - my only gripe is that it relies on command separated "blob" which limits what you can pass in but we can fix that if usecase arises by adding support for i.e. |
Fixes quarkusio#28372 (cherry picked from commit e8b82f6)
Description
It would be nice extension codestart to have user customizable data. This is already possible in codestarts but not yet connected in the tooling.
It would behave like this:
The
my-ext-codestart
prefix is required by the codestart system to know the data is targeting this particular codestart data (and avoid conflicts)The default value is in the codestart.yml:
FYI: I created this issue because @gsmet has a need for this.
The text was updated successfully, but these errors were encountered: