We welcome all contributions to Apache MiNiFi. All new files must include a copy of the Apache License Header. To make development easier, we've included the linter for the Google Style guide. Google provides an Eclipse formatter for their style guide. It is located here. New contributions are expected to follow the Google C++ Style Guide, except for the following points:
#pragma once
over include guardsusing namespace foo
) are discouraged, except for user-defined literal namespacesauto
. The Google Style Guide only allows using it when it makes the code clearer. In MiNiFi C++, it's up to the personal preferences of the contributor.It‘s ok to diverge from any of the rules with a good enough reason. We recommend following the C++ Core Guidelines, when it doesn’t contradict any of the Google Style Guide or the above exceptions.
C++ is a powerful language and “with great power comes great responsibility”. Please aim for simple, readable and maintainable solutions and avoid footguns. Be open for respectful debate in pull request reviews.
Shell script files shall follow the guidelines and best practices defined by the shellcheck analysis tool. New contributions are expected to pass the shellcheck analysis as part of the verification process. If a shellcheck requested change is unfeasible it shall be disabled on per-line basis and will be subjected to review. For more information on an issue please check the shellcheck wiki page. You can run shellcheck by invoking the shellcheck cmake target, e.g. make shellcheck
.
Python script files shall follow the PEP8 guidelines and best practices. The project includes flake8 checks as part of the verification process, that is applied to all new contributions.
Issues within MiNiFi C++ are tracked in the official Apache JIRA. New users can register freely and ask for contributor access on the Developers Mailing List. Unassigned tickets may be assigned to yourself or filed via this JIRA instance. Pull requests can be submitted via our Github Mirror . When doing so please create a JIRA issue for your pull request.
Apache NiFi MiNiFi C++ is a review then commit community. As a result, we will review your commits and merge them following review. We ask that you provide tests and documentation when possible. Typically PRs are merged after they get 2-3 approvals, usually in a week or two.
Once you have completed your changes, including source code and tests, you can verify that you follow the Google style guide by running the following command:
$ make linter
> msbuild linter.vcxproj
This will provide output for all source files.
Please see ThirdParties.md on how MiNiFi builds and uses third party libraries and how you can add new ones.
MiNiFi C++ contains a dynamic loading mechanism that loads arbitrary objects. To maintain consistency of development amongst the NiFi ecosystem, it is called a class loader. If you are contributing a custom Processor or Controller Service, the mechanism to register your class into the default class loader is a pragma definition named:
REGISTER_RESOURCE(CLASSNAME, TYPE);
To use this include REGISTER_RESOURCE(YourClassName, Processor) or REGISTER_RESOURCE(YourClassName, ControllerService) in your cpp file. The default class loader will make instances of YourClassName available for inclusion. In order to include your new component in the manifest in the heartbeat message in a standardized way, REGISTER_RESOURCE requires the presence of a number of static variables and functions. Use an existing Processor or ControllerService as a model to create these static members.
The extensions sub-directory allows you to contribute conditionally built extensions. The system adds all subdirectories in extensions/*
that contain a CMakeLists.txt
file. It is up to the extension creator's discretion how they handle cmake flags. It is important that register_extension
be called at the end of the setup, for the extension to be made available to other stages of the build process.
# extensions/kubernetes/CMakeLists.txt # the author chooses to look for the explicit compilation request if (NOT ENABLE_KUBERNETES) return() endif() # # extension definition goes here # # at the end we should announce our extension register_extension(minifi-kubernetes-extensions "KUBERNETES EXTENSIONS" KUBERNETES-EXTENSIONS "This enables Kubernetes support") # the first argument should be the extension target # the next three arguments are used for documentation purposes # the fifth optional argument designates the directory of the extension's tests # we could optionally enforce a coding style by registering a linter target register_extension_linter(minifi-kubernetes-extensions-linter)