szaszm commented on a change in pull request #1138:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1138#discussion_r691315887
##########
File path: conf/minifi.properties
##########
@@ -20,6 +20,9 @@ nifi.administrative.yield.duration=30 sec
# If a component has no work to do (is "bored"), how long should we wait
before checking again for work?
nifi.bored.yield.duration=100 millis
+# Comma separated path for the extension libraries. Relative path is relative
to the minifi executable.
+nifi.extension.path=../extensions/*
Review comment:
I currently see two usual ways of launching minifi:
- The normal installation, where the MINIFI_HOME is usually /opt/minifi, and
the binary is under MINIFI_HOME/bin
- After compilation, launching the compiled binary in a preexisting
MINIFI_HOME
In the first case, either version is fine. In the second case, we would need
extensions to be installed to build/extensions/ for them to work without extra
effort, or we could load them from MINIFI_HOME/extensions/ in the proposed case.
Another use case that I could see happening in the future is standard linux
packages:
- minifi binary under /usr/bin/minifi
- config files under /etc/minifi
- extensions under /usr/share/minifi/extensions, and I imagine MINIFI_HOME
would be /usr/share/minifi.
I think the default would cover more use cases with a path relative to
MINIFI_HOME, and we could avoid the "../" at the beginning of practically every
path pattern. Given the above points, do you still prefer paths relative to the
binary?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
