jbang icon indicating copy to clipboard operation
jbang copied to clipboard

generic support for properties

Open maxandersen opened this issue 2 years ago • 6 comments

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:

//PROPERTIES(application.properties) quarkus.banner.enabled=true, quarkus.datasource.soething=blah
//PROPERTIES(application.properties) quarkus.some.other=blah

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 :)

//PROPERTIES application.properties
//quarkus.banner.enabled=true
//quarkus.datasource.something=blah
//ENDPROPERTIES

maxandersen avatar Jan 13 '23 14:01 maxandersen

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.

quintesse avatar Jan 13 '23 15:01 quintesse

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.

maxandersen avatar Jan 14 '23 14:01 maxandersen

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

fbricon avatar Feb 13 '23 09:02 fbricon

@maxandersen you mentioned supporting multiple k/v pairs on a single //PROPS directive, separated by whitespace. But how would values containing spaces be handled then? surround them with (double)quotes?

//PROPS key="value with space"

fbricon avatar Jul 20 '24 16:07 fbricon

probably more like escaping commas (i.e. ',') or similar as comma is allowed today.

maxandersen avatar Jul 30 '24 08:07 maxandersen

btw. reason I haven't implemented this yet (as i thought it would be trivial to do) is that it requires fetching the properties first or allow mutating the current passed in property resolver.

haven't figured out which I hate the least yet :)

maxandersen avatar Jul 30 '24 08:07 maxandersen