Closed maxandersen closed 2 days ago
@dmlloyd @stuartwdouglas comments/alternatives to this ?
We should not use profiles for CLI IMO. It is orthogonal to the original use case for profiles.
@dmlloyd what would be used instead ? if not profiles then only option (I see) is a separate module which is just overkill (see above amount of junk that adds).
Also, its not just for command mode/cli. see comment about deployment variations.
Profiles just were not designed in this way, and furthermore they're partway through being added to the MP Configuration specification.
The problem definition is that essentially you want to be able to build more than one program from the same code base. The problem definition of profiles is that the same program has different behaviors in different scenarios.
What about instead of overloading profiles, we add a new "layer" of indirection for application? So profiles would use %foo
but applications could use, for example, @bar
and be processed after profiles.
In this way, you can have both a profile and an application. The application name could normally be set using a Maven profile for example. Then your configuration could contain something like:
@app1.quarkus.package.main-class=com.myapp.App1
@app2.quarkus.package.main-class=com.myapp.App2
%dev.@app2.quarkus.package.main-class=com.myapp.App2WithDebugStuff
# etc.
This keeps the configuration compact.
Now if your two applications have radically different configuration, you're going to want to rethink your stance on having two modules. There is a point where the configuration gets too ridiculous!
Why do you have an app that is both a CLI app and a HTTP based app? Are they run from seperate main classes, just both in the same package? This just generally seems problematic as when you run the CLI app it is still going to open the HTTP endpoint.
Now if your two applications have radically different configuration, you're going to want to rethink your stance on having two modules. There is a point where the configuration gets too ridiculous!
yes, I fully get that - this is for the case where majority of setup is exactly the same except for a few parameters.
I'm not sure the "app" approach would cover the aspect of being able to layer things in the deployment usecase (i.e. variations wether you target minikube or openshift) ?
Why do you have an app that is both a CLI app and a HTTP based app? Are they run from seperate main classes, just both in the same package? This just generally seems problematic as when you run the CLI app it is still going to open the HTTP endpoint.
I can see usecases for that - but also kinda hoping we had a way to say "quarkus.http.enabled=false" - you still want all the other setup happening just that in this run variation I don't need http requests handled.
@maxandersen
Thus my suggestion is to allow for layered profiles particularly to handle command mode but potentially also useful beyond it.
Sounds like #6810. @radcortez is already working on an enhancement for sr-config: https://github.com/smallrye/smallrye-config/pull/399
I believe this is now supported with multiple profiles: https://quarkus.io/guides/config-reference#multiple-profiles
Description With command mode and openshift/kubernetes deployment extension I'm starting to think it would be useful to have a notion of layered profiles.
Usecase is as follows for command mode: Today when adding a
@QuarkusMain
into a project that also has a http end point things gets messy.For now I'm adding a
cli
profile to myapplication.properties
with the following content:Now I can run the cli with
QUARKUS_PROFILE=cli
and output is now more sane.Problem is that as soon as I want to use
quarkus:dev
mode I loose thecli
settings and if I enablecli
profile I loose thedev
settings (i.e. I would like to havequarkus.hibernate-orm.database.generation=drop-and-create
on only for devmode)Only other alternative I come up with is to split out the cli class in separate module but that is not great either as it requires:
MyCli.java
)application.properties
src/main/*
)Similar issue occurs using kubernetes/openshift extension where you like to have a "dev-deployment" profile but not wanting to duplicate the "dev" settings just to do a deployment.
Thus my suggestion is to allow for layered profiles particularly to handle command mode but potentially also useful beyond it.
Implementation ideas This makes current
getActiveProfile()
less precise, but could just have it return the "default" profile which would be eitherprod
,dev
ortest
as it is today. Then have two methods, likeList<String>[] getActiveProfiles()
andboolean isProfileActive(String name)
to allow more fine grained detection.