NIFI-11308 Adding expression language function to return nifi version

[annanys23]

Summary

NIFI-11308

New ExpL function added: ${nifiVersion()}

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

• Apache NiFi Jira issue created

Pull Request Tracking

• Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
• Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

• Pull Request based on current revision of the main branch
• Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

• Build completed using mvn clean install -P contrib-check
  • JDK 21

Licensing

• New dependencies are compatible with the Apache License 2.0 according to the License Policy
• New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

• Documentation formatting appears as expected in rendered files

[exceptionfactory]

Thanks for proposing this new feature @annanys23.

The concept seems useful, but the implementation is problematic because it introduces framework-level dependencies to the expression language library, which is contrary to the general design of the system.

A simpler approach would be to configure the Maven JAR Plugin to write the standard manifest entries, and then use standard Java Package implementation version methods to retrieve the version from that expression language library itself.

Although nifiVersion is fairly clear, it might be better to name this frameworkVersion instead.

[markap14]

I agree, we definitely want to avoid adding any sort of framework-specific dependencies to the nifi-expression-language module. Ideally, though, I think we should actually avoid updating the Expression Language at all. There's no need to expose a new function for this, but instead just update NarClassLoaders.InitContext so that when it sets the framework bundle it also sets a system property: System.setProperty("nifi.version", frameworkBundle.getBundleDetails().getCoordinate().getVersion());
This should make it available to the Expression Language as ${'nifi.version'}

[annanys23]

Thanks for the review and suggestions!

[exceptionfactory]

Recommend adding a comment indicating the reason for this addition. I would recommend naming this framework.version to avoid potential confusion that could result from different NAR extension versions, which are also part of NiFi, but could be different in particular installations.

[dan-s1]

@exceptionfactory A concern I have is how will users know this property exists in order to take advantage of it? Shouldn't this PR include documenting this system property is now available?

[annanys23]

agreed. where are the properties documented?

[dan-s1]

I see there is a section for System properties in the user guide but I am not sure that would be the place for this particular system property.

[exceptionfactory]

Good point @dan-s1. The Expression Language Guide notes that System properties can be referenced, but does not list any of them. This probably warrants a new short sub-section along the lines of Framework System Properties, above the Functions section.

[mosermw]

Could we name this system property nifi.framework.version? This is more specific and may avoid confusion with generic system properties that are not related to NiFi.

[annanys23]

changed prop name to: nifi.framework.version and added a section to the Expression Language Guide. Are there any other system properties that need to be documented? I did not find any, outside of test classes.

[exceptionfactory]

Thanks for working through the feedback and updating the documentation @annanys23, the latest version looks good. Thanks for the recommendation on the implementation @markap14. +1 merging