Yes and it is all quite easy to capture (until too much dynamism
indirections but it is "ok").
Issue remains how to provide a description.

>From the app i used the Config direct usage is very limited and it is ok to
write this one manually but the ConfigProperty one (including
@ConfigProperty on a class - guess it was your @Configuration) is
widespread everywhere so i see it as the 80% of pareto law.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 22 août 2018 à 12:42, Mark Struberg <[email protected]> a écrit :

> Hiho!
>
> In general I like the idea to have a generated list of config switches +
> description.
>
> But @Inject @ConfigProperty is probably not the only way.
>
> One could use a ConfigValue, inject a Config instance, an @Configuration
> interface (those features are now just ConfigJSR, but will be backported to
> mp-config as soon as I find time).
>
> LieGrue,
> strub
>
>
> > Am 22.08.2018 um 08:59 schrieb Romain Manni-Bucau <[email protected]
> >:
> >
> > Hi  guys,
> >
> > What about adding in the project a mojo to scan @ConfigProperty usages
> (potentially we can scan for getOptionalValue/getValue usages too but not
> sure we should do it upfront) and dump them in an adoc (we can make it
> pluggable later if requested). Goal is to have some auto doc for the config
> very quickly and without effort.
> >
> > My main question is how to get the documentation part of each config
> entry. In my apps I tend to add a @Documentation annotation which is usable
> at build and runtime times but wonder if if there is a way to avoid it
> without using the javadoc parsing which would be my last option.
> >
> > Are you for this feature?
> > Any idea for the doc issue?
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>
>

Reply via email to