I think a lot of cases are a specialization of the base cases (processor archetype and service archetype), so when possible I would lean towards some documentation on the Maven Projects wiki page [1] about how to take one of those and slightly modify it to get started with the given scenario. For example, the case of a processor referencing a service API is simply 1) use processor archetype 2) use service archetype 3) modify two dependencies. Otherwise we'd be creating a third archetype that includes everything from the other two, with one or two minor changes.
I could see maybe a new processor archetype geared towards a record processor like convert record, since we want to promote the usage of record-oriented processors. Implementing an actual reader/writer is a lot less common so may not be necessary, but open to what others think. [1] https://cwiki.apache.org/confluence/display/NIFI/Maven+Projects+for+Extensions On Fri, Jan 11, 2019 at 9:34 AM Otto Fowler <[email protected]> wrote: > > I would like to have a discussion around the archetypes. Right now Nifi > has two archetypes : A controller service and a processor. Both are > simple, and don’t reference anything outside of them. > > I have a few topics for comment here: > > 1. Are there things about the current archetypes that could be improved or > refactored such that processors produced need less modification when > submitted? > example: The processor archetype’s method of initializing it’s properties > vs. how standard processors do it, or in fact the archetype service does it > 2. Are there common patterns of use that should be represented in the > current archetypes? > - verification / use of built in verifications > - service usage > 3. Are there patterns of use or components that should have an archetype > that don’t have one? > - reporting > - record readers/writers > - processors that work with records > - new bundle patterns such as the Processor -> API Service pattern, so an > archetype with a processor and service that work together? > 4. ????? > > I would like to gather feedback to create some jiras around this. > > Thanks! > > ottO
