nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy LoPresto <alopre...@apache.org>
Subject Lowering the barrier of entry
Date Fri, 25 Jan 2019 01:03:38 GMT
Hi folks,

Based on some recent (and long-term) experiences, I wanted to discuss with the community what
we could do to lower the barrier of entry to using & contributing to NiFi. I hope to get
some good feedback from both long-time and newer members, and determine some immediate concrete
steps we can take. 

Problems identified:
* NiFi has a number of custom profiles, so a simple “mvn clean install” in project root
doesn’t get a new developer up and running immediately
* The API is very well defined, but for new contributors, it can be a challenge to know where
to put functionality, and building a custom processor + NAR and deploying isn’t a one-step
process
* Project size (and build size/time) is large. This can restrict the minimum hardware necessary,
elongate the development cycle, etc. 
* Some new users do not receive mailing list replies

Possible solutions:
* On a clean git clone, “mvn clean install” should build a working instance. Maybe we
provide a quickstart.sh script to handle the default maven build, change to the target directory,
and start NiFi?
* Individual contributors have written excellent blogs, and documentation exists, but making
it more prominent or more easily accessed could help? 
* Extension registry will solve all the world’s problems (related to bundling and build
time)
* Not sure about this one — I don’t know if it’s because they’re not subscribed, their
mail client is blocking them, etc. 

I’ve said my bit, now I am eager to hear from other community members on their experiences,
steps that helped them, and suggestions for the future to continue to make the NiFi community
welcoming to new users. Thanks. 


Andy LoPresto
alopresto@apache.org
alopresto.apache@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message