jbangdev / jbang

Unleash the power of Java - JBang Lets Students, Educators and Professional Developers create, edit and run self-contained source-only Java programs with unprecedented ease.
https://jbang.dev
MIT License
1.37k stars 153 forks source link

generic support for properties #1541

Open maxandersen opened 1 year ago

maxandersen commented 1 year ago

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
quintesse commented 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.

maxandersen commented 1 year ago

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.

fbricon commented 1 year ago

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