Refactor and polish App READMEs

sabbyanandan commented 7 years ago

As a developer, I'd like to refactor application READMEs for clarity and to include the following specifics.

1) Supported Input/Output Content-Type at each application - see live example: Cassandra Sink

2) Add Build section

== Build
$ ./mvnw clean install -PgenerateApps
$ cd apps

You can find the corresponding binder based projects here. You can then cd into one of the folders and
build it:

$ ./mvnw clean package

3) Add a java -jar sample where applicable; example:

java -jar jdbc.jar --jdbc.columns=name,age --jdbc.tableName=customers

Notes:

Whatever we add/polish at each READMEs would directly feed the SCDF reference-docs stories targeted for 1.2.3.RELEASE.
it is an anti-goal to include SCDF DSL samples in each README

Targeted Apps:

[x] time-source @sobychacko
[x] log-sink @sobychacko
[x] http-source @sobychacko
[x] file-source @garyrussell
[x] file-sink @garyrussell
[x] filter-processor @sobychacko
[x] splitter-processor @sobychacko
[x] transform-processor @sobychacko
[x] aggregator-processor @artembilan
[x] ftp-source @garyrussell
[x] ftp-sink @garyrussell
[x] sftp-source @garyrussell
[x] sftp-sink @garyrussell
[x] bridge-processor
[x] jdbc-source @sobychacko
[x] jdbc-sink @sobychacko
[x] gemfire-source @sobychacko
[x] groovy-filter-processor @sobychacko
[x] groovy-transform-processor @sobychacko
[x] httpclient-processor @dturanski
[x] header-enricher-processor @sobychacko
[x] trigger-source @sobychacko
[x] triggertask-source @cppwfs
[x] task-launcher-cloudfoundry-sink @cppwfs
[x] tasklaunchrequest-transform-processor @cppwfs
[x] cassandra-sink - @viniciusccarvalho
[x] twitterstream-source @sobychacko
[x] aggregate-counter-sink @sobychacko
[x] hdfs-sink @sobychacko
[x] tcp-source @sobychacko
[x] tcp-sink @sobychacko
[x] tcp-client-source @sobychacko
[x] tcp-client-processor @sobychacko
[x] pgcopy-sink @sobychacko
[x] router-sink @sobychacko
[x] scriptable-transform-processor @sobychacko
[x] task-launcher-local-sink @cppwfs
[x] task-launcher-yarn-sink @sobychacko
[x] throughput-sink @sobychacko
[x] websocket-sink @sobychacko
[x] gpfdist-sink @sobychacko
[x] load-generator-source @sobychacko
[x] loggregator-source @sobychacko
[x] rabbit-source @sobychacko
[x] rabbit-sink @sobychacko
[x] syslog-source @sobychacko
[x] hdfs-dataset-sink @sobychacko
[x] jms-source @sobychacko
[x] redis-pubsub-sink @sobychacko
[x] mail-source @sobychacko
[x] gemfire-sink @sobychacko
[x] gemfire-cq-source @sobychacko
[x] mongodb-source @sobychacko
[x] mongodb-sink @sobychacko
[x] pmml-processor @sobychacko
[x] tensorflow-processor @sobychacko
[x] twitter-sentiment-processor @sobychacko
[x] counter-sink @sobychacko
[x] field-value-counter-sink @sobychacko
[x] s3-source @sobychacko
[x] s3-sink @sobychacko
[x] python-http-processor - @dturanski
[x] python-jython-processor - @dturanski

markfisher commented 7 years ago

Can we also change the metadata generator so that it provides simple names, such as "string, boolean, comma-delimited strings" instead of <java.lang.String>, <java.lang.Boolean>, <java.util.List<java.lang.String>>?

markfisher commented 7 years ago

Is it possible to trigger a build failure when the doc is missing rather than having this as the final result? : <documentation missing>

sobychacko commented 7 years ago

All README's are updated with Input/Output content-type and payload. Build instructions and examples are also updated.

ericbottard commented 7 years ago

Can we also change the metadata generator so that it provides simple names, such as "string, boolean, comma-delimited strings" instead of , , <java.util.List>?

Can definitely do the first two. A bit more reluctant about the third because, while also true for the first issue, it depends on what converters are present at runtime and it may not always be true that it accepts a comma delimited string (not plural, btw).

So what about changing: java.lang.X -> just x java.util.List<X> -> list<X> java.util.Map<X, Y> -> map<X, Y> java.util.Set<X> -> set<X>

ericbottard commented 7 years ago

Is it possible to trigger a build failure when the doc is missing rather than having this as the final result? : <documentation missing>

Definitely possible, but I don't thing this is a good idea, because we can't actually cure this in most cases. This is a case where the doc is not "seen", be it because of inheritance, of sources not available at annotation processing time, etc. So I'm not sure we'll be able to fix all of those, even with drastic starter design changes

spring-attic / app-starters-release

Refactor and polish App READMEs #99