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

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

    Details

    • 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-6339Remove unused datasource.pool.size config parameter from various files
      KULRICE-6883Add ability for KEW to log and display detailed information about a document which is "on it's way" to exception routing
    • Rice Module:
      Rice Core

      Description

      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

          Activity

          There are no comments yet on this issue.

            People

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

              Dates

              • Created:
                Updated:

                Structure Helper Panel