exceptionfactory commented on PR #8509: URL: https://github.com/apache/nifi/pull/8509#issuecomment-2004018034
> > Can you provide some additional background on the reason for introducing a PowerShell alternative to the `nifi.cmd` script for Windows? It would be ideal to maintain a unified approach for Windows, as opposed to maintaining two separate scripts for the same OS. > > I am just starting out with NiFi, so I will have to speak in generalities. > > Making changes to _.cmd/_.bat files is fraught (for me). Every time I think I am going to make a small change to one it ends up being a time sink. > > I am planning on extensively using NiFi for a project I am working on. A lot of the work will involve dynamic deployment of NiFi components on a dynamic cluster. I anticipate building tooling to support this work. I would much prefer to use powershell over CMD/BAT. I plan on contributing this tooling back to Apache. > > It may be that the tooling would be better written in one of the JVM scripting languages (i.e. Groovy, Kotlin, Clojure). That said I expect that some of the tooling would still best be written as powershell modules on Windows. > > Obviously, the `nifi.ps1` is not (yet) a powershell module, I am getting a feel for how the NiFi project operates. I would like to see the `nifi.cmd` deprecated in favor of powershell modules. Thanks for additional background @phreed. The shell scripts are intended to provide a minimum wrapper around the environment settings necessary to start NiFi Java processes. For that reason, these scripts should be as minimal as possible, and provide the broadest base of compatibility. That is why the current scripts for Windows do not use PowerShell, and should avoid additional complexity. That is also the reason why they do not use any type of JVM scripting. Running NiFi on Windows is supported in general, but running scalable production deployments most often depends on Linux as the operating system. So with that background, any shell script changes should continue to follow the minimalist approach to maintain compatibility across modern distributions of Windows. With that in mind, it may be best to avoid introducing PowerShell scripts in favor of retaining the limited scope of command scripting. This does highlight the need for reviewing the general approach of Windows startup scripts, including the removal of the `BAT` scripts. If the PowerShell approach works without installing any additional Windows packages on current versions of both Home and Pro, then this seems like a potential option. Are you aware of any compatibility issues with PowerShell on recent Windows versions, particularly on non-server editions? -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
