At first reaction, I think this goes a broader than that use case. These items aren't necessarily used with NiFi, but in support of it. I could probably go either way though.
The Docker items, as I see them, would not be binary images, there are other avenues for that. This is largely in support of NiFi-153 and is completely source driven. The work I have done thus far is simply a Dockerfile, an initialization script, and a Makefile; all source files, no binaries (although the Makefile will retrieve a NiFi release when invoked). On Sat, Mar 21, 2015 at 2:00 PM, Joe Witt <[email protected]> wrote: > Aldrin, > > Mark made a spark receive during this last build cycle. It is under > root/nifi/nifi-externals. Would this cover your case or are you > thinking more broadly? > > In the case of docker i suspect that gets blurry with the lines of > binary release vs source release. What in your view would need to > live in our source for docker support? > > Thanks > Joe > > On Sat, Mar 21, 2015 at 1:54 PM, Aldrin Piri <[email protected]> wrote: > > What is the right destination for handling, for lack of better phrasing > > meta-source/contributions? > > > > This was broached briefly with the site design, but that found a home, > > appropriately with the main repository at the top level. With the talk > of > > configuration for editors as we strive towards a consistent code style > and > > some work I've been doing with Docker to support NiFi, where do these > items > > reside? > > > > Based on my experiences and what I have witnessed on other projects, a > > contrib folder in the repository seems to be how this is classically > > handled; you do not need these items, but they may be helpful. Seems > like > > an appropriate fit, with some subdirectories that group these by intent > to > > avoid it becoming a dumping ground. Any additional thoughts or > suggestions > > on how we can best incorporate these in a sane and organized fashion? >
