[
https://issues.apache.org/jira/browse/SOLR-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-555:
--------------------------
Attachment: SOLR-555.patch
same patch, just updated against trunk.
I've also updated the generated docs for people to see what the generated doc
structure looks like now with the "components" tag and the "smart linking" (if
a @see or @link tag refers to a class that is a "plugin" link to it as a
plugin, otherwise link to it's normal javadocs)
* list of types of plugins:
http://people.apache.org/~hossman/tmp/SOLR-555/plugins/
* list of instances of a type of plugin:
http://people.apache.org/~hossman/tmp/SOLR-555/plugins/org.apache.solr.request.SolrRequestHandler.html
* A specific instance:
http://people.apache.org/~hossman/tmp/SOLR-555/plugins/org.apache.solr.request.SolrRequestHandler.html#org.apache.solr.DemoChildPlugin
* the regular javadocs for the same class:
http://people.apache.org/~hossman/tmp/SOLR-555/org/apache/solr/DemoChildPlugin.html
Something i didn't really make clear before is that the @solr.component tag
isn't specific to the "SearchComponent, it can refer to any class in the tree,
and if that class defines some @solr.run.params they will be listed.
> Autogenerate "user" docs about "plugins" from code
> --------------------------------------------------
>
> Key: SOLR-555
> URL: https://issues.apache.org/jira/browse/SOLR-555
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
> Assignee: Hoss Man
> Attachments: SOLR-555.patch, SOLR-555.patch, SOLR-555.patch,
> SOLR-555.patch, SOLR-555.patch, SOLR-555.patch
>
>
> Our current strategy of using javadocs for "developer" documentation and the
> wiki for documenting "user" features only gets us so far -- among other
> things, it makes it hard to include the "user" documentation in our releases,
> but it also results in a disconnect between when code changes and when
> documentation gets updated.
> in an ideal world, "user" documentation would live in the code right along
> side the implementation, just like with javadocs -- but the standard set of
> information displayed by javadocs isn't very user friendly. we should find a
> better way to allow us to "edit" the info about how to use a plugin right
> along side the code for that plugin and generate user friendly documentation
> from that.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
