Closed onobc closed 3 months ago
+1 for a list representation: there is no guarantee that we always going to have close number of those sources, processors and sinks.
I also don't think that it would be a big deal to have these lists in a separate adoc
file to be include::
whenever it is necessary.
Indeed such a file could be generated: I believe I can write some Gradle task simply based on Groovy File API, but I don't think it would be possible with Maven without custom plugin or so...
Indeed such a file could be generated: I believe I can write some Gradle task simply based on Groovy File API, but I don't think it would be possible with Maven without custom plugin or so...
I was thinking the same thing. Even w/o the auto-generation, the other 2 points would be a big improvement.
Solved the duplication by making the table in this repo's README the single source of truth and having the other locations simply link to the sample apps section in the README.
Fixed the formatting in this repo's README.
Not going to do any auto-generation of the table at this point.
Duplication
There is a table that lists the available stream apps and it is in multiple locations:
This duplication leads to inconsistency across locations and is toil to attempt to keep the table up-to-date.
Formatting
In addition to the duplication, the table layout is currently confusing. There is a 3 column table (source, processor, sink). Each column is alpha-ordered but there is also an attempt to line up rows that have representation in more than 1 column (eg.
xmpp
,twitter
, etc..). It may be less confusing to instead break the 3 column table into 3 separate lists (one forsource, processor, sink
) and just make them alpha-ordered.