[DISCUSS] Nifi Archetypes “refresh”

[Otto Fowler <ot...@gmail.com>]

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

Re: [DISCUSS] Nifi Archetypes “refresh”

[Bryan Bende <bb...@gmail.com>]

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 <ot...@gmail.com> 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

Re: [DISCUSS] Nifi Archetypes “refresh”

[Otto Fowler <ot...@gmail.com>]

So I’ll kick it off with a small one:

- All archetypes should have a dummy additional details documentation entry
to show how that is done.



On January 11, 2019 at 09:25:13, Otto Fowler (ottobackwards@gmail.com)
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