[
https://issues.apache.org/jira/browse/NIFI-15708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18066613#comment-18066613
]
Scott Aslan edited comment on NIFI-15708 at 3/18/26 6:19 PM:
-------------------------------------------------------------
I am still not sure I am following. You have a separate nx monorepo you are
using to build your Advanced UI application? And if so, how does having the
nifi-frontend-<version>sources.jar containing the nifi-frontend sources help
you? The same issues are present with this setup as the ones I mentioned for
extra work/complexity introduced by exposing @nifi/xxx artifacts as npm
packages. Even copying the @nifi/theme src will have this issue. If we do what
you suggest and include the @nfif/theme source code with the
nifi-frontend<version>-sources.jar then your Advanced UI application would be
dependent upon a specific version of the the nifi-frontend<version>-sources.jar
which implies that the Advanced UI should be released with that particular nifi
version.
If you look at how the nifi nx monorepo is setup and how it works with the nifi
maven build and if you look at the examples of UpdateAttribute and
JoltTransformJSON you can see that those Advanced UI applications are built
alongside the other frontend applications so that they may leverage the power
of the monorepo, the theme, and the shared library of components. Then maven
takes the artifacts produced by those frontend applications build processes and
includes those in the .war for that Advanced UI. These Advanced UIs require
that the nifi-api's etc must also exist and it is invoked by these Advanced
UI's by relative path...
Hopefully this is helpful information. I am not sure it is the responsibility
of the community nor do I think is it the intent of the community to produce a
design system specification, implementation, or support versioning or
maintenance of said package. We tried that approach with nifi-fds and found
that it, along with the nifi-registry, largely went unmaintained with no
community support, interaction, or involvement otherwise. With the nifi 2.0
release we focused on the Nx monorepo and shared library of components to
support consistency across themes and UI/UX applications within nifi use cases.
Is there a way you can achieve what you are trying to do with maven following
the the examples I mentioned from the other Advanced UI's?
was (Author: scottyaslan):
I am still not sure I am following. You have a separate nx monorepo you are
using to build your Advanced UI application? And if so, how does having the
nifi-frontend-<version>sources.jar containing the nifi-frontend sources help
you? The same issues are present with this setup as the ones I mentioned for
extra work/complexity introduced by exposing @nifi/xxx artifacts as npm
packages. Your Advanced UI application would be dependent upon a specific
version of the the nifi-frontend<version>-sources.jar which implies that the
Advanced UI should be released with that particular nifi version.
If you look at how the nifi nx monorepo is setup and how it works with the nifi
maven build and if you look at the examples of UpdateAttribute and
JoltTransformJSON you can see that those Advanced UI applications are built
alongside the other frontend applications so that they may leverage the power
of the monorepo, the theme, and the shared library of components. Then maven
takes the artifacts produced by those frontend applications build processes and
includes those in the .war for that Advanced UI. These Advanced UIs require
that the nifi-api's etc must also exist and it is invoked by these Advanced
UI's by relative path...
Hopefully this is helpful information. I am not sure it is the responsibility
of the community nor do I think is it the intent of the community to produce a
design system specification, implementation, or support versioning or
maintenance of said package. We tried that approach with nifi-fds and found
that it, along with the nifi-registry, largely went unmaintained with no
community support, interaction, or involvement otherwise. With the nifi 2.0
release we focused on the Nx monorepo and shared library of components to
support consistency across themes and UI/UX applications within nifi use cases.
Is there a way you can achieve what you are trying to do with maven following
the the examples I mentioned from the other Advanced UI's?
> [Advanced UI] Ease providing additional Advanced UIs leveraging NiFi Theme
> logic
> --------------------------------------------------------------------------------
>
> Key: NIFI-15708
> URL: https://issues.apache.org/jira/browse/NIFI-15708
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core UI
> Affects Versions: 2.8.0
> Reporter: Denis GARET (AmeXio)
> Priority: Major
>
> *As* a developer extending NiFi with extra capabilities
> *I want to* be provided with helpers / integrated mechanisms
> *In order to* ease building Advanced UIs for custom components (keeping
> overall UX consistency)
> My specific concern is around the way *NiFi theme* is injected into advanced
> UIs.
> * The "nifi-frontend" module provides valuable assets to be reused across
> various "Advanced UIs for custom components" (as it is the case for OOTB
> Advanced UIs such as UpdateAttribute or JOLTTransformJSON)
> * In order to keep overall UI/Theme consistent for other advanced UIs I plan
> to leverage such elements
> * At the time being I did not find a proper way to achieve this rather than
> copy/pasting existing "source code files" (subfolder
> src/main/frontend/libs/shared from module nifi-frontend into my own
> repository/modules
> Would there be another way to achieve this objective of keeping UX/Theme
> consistent when developing addintional Advanced UIs for custom components ?
> (I may have missed some documented instructions/hints to setup an alternate
> strategy)
> Aternatively, would it be possible to consider anticipating smoother
> extension mechanisms for Advanced UIs such as
> * (ideal) Exposing the @nifi/shared package/bundle in order to make it
> reusable in other Advanced UIs (my understanding being that it is currently
> only available locally when building the nifi-frontend module
> * (acceptable workaround that would require less effort I guess) Adapt
> configuation applicable for the maven-source-plugin on module nifi-frontend
> in order to have the associated publishedjar
> (nifi-frontend-<version>-sources.jar) contain frontend source files (I guess
> the default plugin configuration makes it ignore non java files) so that
> custom developments could reuse it through maven-dependency-plugin
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
