Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-6109

Come up with a way to "auto-generate" documentation on our various configuration parameters


    • Type: New Feature New Feature
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Backlog
    • Component/s: Documentation
    • Labels:
    • Similar issues:
      KULRICE-1443Develop and document a naming standard for rice configuration parameters
      KULRICE-12101Document the various *.krad.url configuration parameters
      KULRICE-6436Tune ehcache configuration for the various rice modules
      KULRICE-4064Come up with a way to prevent or handle spring bean name conflicts
      KULRICE-16Document a "How-To" for deploying rice in the various ways (i.e. enterprise shared, enterprise clustered) to show various architectures
      KULRICE-7701Come up with a standard mechanism for handling the service registry and load balancing/clustering
      KULRICE-805Come up with a method for generating documentation about our XML document structure (XSD schema)
      KULRICE-5188Need to remove ImmutableListAdapter and ImmutableCollectionAdapter from our service definitions and come up with a better solution because it is producing undesirable XML
      KULRICE-12814Clean up datasource configuration
      KULRICE-6339Remove unused datasource.pool.size config parameter from various files
    • Rice Module:
      Rice Core


      It's really tedious to have to manually maintain these every release. It would be great if we could come up with a way to generate documentation for these.

      Some quick ideas i thought of:

      1) Document them well as part of the javadocs and point our release documentation to the relevant sections of the javadoc
      2) Move all of the configuration parameters to constants files (most already are) and add annotations to them for the description of what they are
      3) Javadoc as in number 1 but generate custom documentation from them using the javadoc tool

      I kind of like option 3 the best, because then we can have them documented in the javadoc as well as included a more configuration parameter focussed documentation for our end-user technical docs
      (that way they don't have to scour the javadocs to find it)

        Issue Links


          There are no comments yet on this issue.


            • Assignee:
              Eric Westfall
            • Votes:
              0 Vote for this issue
              0 Start watching this issue


              • Created:

                Structure Helper Panel