[
https://issues.apache.org/jira/browse/NIFI-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14704834#comment-14704834
]
Dan Bress commented on NIFI-725:
--------------------------------
Here are a few drawbacks / open questions with the approach I am suggesting
#The new plugin runs against a single nar, so it doesn't load all the nars, so
it doesn't know which ControllerService nars implement which
ControllerServiceApis. This means we can say [This Processor uses this
controller service api implemented by these controller
services|nifi.apache.org/docs/nifi-docs/components/org.apache.nifi.processors.standard.PostHTTP/index.html]
##This also means makes it difficult to implement NIFI-681, how would you know
all processors under a certain tag to link to them?
#The new plugin is actually run against a jar project, so it doesn't even know
what nar its in. This would make it difficult to add a breadcrumb feature I've
been thinking about
##The breadcrumb would mean the top of each processors HTML would say something
like: nifi-standard-nar-0.2.1 / Processors / PostHTTP
#Would we have two ways of generating the "index" page? JSF for inside of the
app and the plugin for the website? I'm not opposed to this, as I could see a
case for them being different(on the website I'd be OK with moving the
developer/admin/overview guides out of this [NiFi docs index
page|http://nifi.apache.org/docs.html] and onto the documentation menu on the
[main page|http://nifi.apache.org/index.html#])
> Refactor when documentation is generated
> ----------------------------------------
>
> Key: NIFI-725
> URL: https://issues.apache.org/jira/browse/NIFI-725
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, Documentation & Website
> Affects Versions: 0.1.0
> Reporter: Dan Bress
> Assignee: Dan Bress
> Priority: Minor
>
> Currently the DocGenerator, which generates all of our
> Processor/ReportingTask/ControllerService documentation, is invoked directly
> from the
> [NiFi|https://github.com/apache/incubator-nifi/blob/develop/nifi/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-runtime/src/main/java/org/apache/nifi/NiFi.java#L123]
> class in the runtime project.
> Invoking the DocGenerator directly from the runtime hamstrings what libraries
> the DocGenerator can use, because the runtime project should have the least
> number of dependencies possible, and it currently depends on the
> documentation library.
> I'm proposing that we find a new way/place to invoke documentation generation
> such that it may bring in whatever dependencies it needs.
> The first dependency it needs is on nifi-framework-core
> [ReflectionUtils|https://github.com/apache/incubator-nifi/blob/develop/nifi/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/util/ReflectionUtils.java],
> which would let us [this
> copy|https://github.com/apache/incubator-nifi/blob/NIFI-632/nifi/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-documentation/src/main/java/org/apache/nifi/documentation/util/ReflectionUtils.java]
> of that class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
