Open maxandersen opened 1 year ago
Dunno, that sounds extremely specific. What's wrong with the //FILES application.properties
approach?
Edit: And how do you see this used in a way that's not specifically for Quarkus? Is there any other reasonable use-case you can think of?
Edit2: And the //Q:CONFIG
is not really Quarkus-specific, it's a line that can be read by any integration and any integration can add their own //
tags, it's not something hard-coded specifically for Quarkus.
The same approach can be use for anything g configured by properties. Springboot, micronaut, quarkus etc. It's generic after all.
I probably tend to agree it's just fine using external file - it's just that for examples it's nice just being able to copy paste I to one file not multiple.
I was just thinking about something somewhat related, for managing dependency versions, but that would be really geared towards JBang consumption, something along the line of:
///usr/bin/env jbang "$0" "$@" ; exit $?
//PROPS junit.version=5.9.1
//DEPS org.junit.jupiter:junit-jupiter-api:${junit.version}
//DEPS org.junit.jupiter:junit-jupiter-engine:${junit.version}
//DEPS org.junit.jupiter:junit-jupiter-params:${junit.version}
I'd rather prefer having JBang specific prefixes (//PROPS or similar) on each line, as it's easier to detect/parse from a tooling standpoint
Quarkus integration have a notion of //Q:CONFIG to allow config being directly in the file.
unfortunately it is not as reliable as wanted and its Quarkus specific.
Users can just do
//FILES application.properties
and then have a separate file that gets included.But I was wondering if could come up with something that still lets us directly edit single setup.
something like:
which would be treated as writing those key/values into a file that gets place at
/application.properties
I don't like it because its verbose but wondered if we could come up with something better?
Following is multiline which is going to open up a pandoras box but if I squint my eyes I kinda like it :)