I agree, HS should always just work out of the box. Perhaps an sub repo would
be ideal. This may make it easier to reference HS from the samza test suite .
Regarding the data masking , I will provide more specifics shortly. My
intention however would be that we could scale the data masking tra
I agree with Jakob. I'll add that for some users it is useful to see the
gradle/maven configuration of the samza dependency in an external project,
which will most closely reflect how they have to configure their own
project. That way they can just copy the snippet without any additional
knowledge
The big hurdle here is that Hello Samza (HS) should always be ready to
go and work right out of the box, whereas a fresh checkout of trunk
may (though hopefully doesn't) have issues. This is why HS by default
points to the last stable Samza release (and has to be re-branched to
track master on Sam
Hi Steve,
I think when I started contributing to Samza, I had a similar idea about
bringing the samples under the main repository. Also, to add more examples
illustrating the various features that Samza supports. I don't see any
issue in doing this, except that it will make our repository more hea
Hi Samza Devs, I think it would be a good idea to have just the one repo for
Samza + Hello Samza . I haven't been on this mailing list for some time so
there may be a good reason why their seperate.
From a newbie point of view it's nice to check out code and have a folder full
of showcase samp
