SpringBoot Provide an alternative to javadoc for documenting configuration properties

The article here gives an illustration of providing javadoc comments on fields to have the generated configuration metadata JSON file include a description. Example of code snippet:

public static class Server {

    /**
     * The IP of the database server
     */
    private String ip;

    /**
     * The Port of the database server.
     * The Default value is 443.
     * The allowed values are in the range 400-4000.
     */
    @Min(400)
    @Max(800)
    private int port = 443;

    // standard getters and setters
}

I would like to be able to provide the description using an annotation (which points to a static final string/inline string):

public static class Server {
   @Description("some string") private String ip;
   // rest of code
}

Is this currently possible? If not then I would like to ask for it to be added as an enhancement.

Comment From: wilkinsona

What's the motivation here? What benefit will you get from using an annotation rather than javadoc? Note that you can already provide descriptions in an additional metadata file.

Comment From: vab2048

I have libraries which have a non spring core and then spring boot starters which wrap those libraries.

Within the libraries each property has a static string variable which provides a description. I would like to have the annotation point to that static string so that the description can be reused rather than copied and pasted into javadoc

Comment From: philwebb

Thanks for the additional context @vab2048. This specific use-case feels quite unique and it's unlikely we'd be able to invest in developing such a feature ourselves. I wonder if you could develop your own annotation processor to generate the metadata file directly. You can find details of the metadata format in our docs. Our existing code might also provide a useful reference.

Thanks anyway for the suggestion.

Comment From: vab2048

Would a PR for this feature be accepted?

Comment From: philwebb

@vab2048 It's hard to say for sure, but I don't think we'd particularly want to take on the maintenance burden.

Comment From: wilkinsona

I agree with Phil. It's not so much the initial development effort that's the problem but the ongoing maintenance burden. The additional complexity would also have a lasting effect for both maintainers and users.