Sivaprasanna,

I am not sure I follow exactly what you are saying...

NiFi Registry would no longer continue to host a copy of the FDS NgModule.
Instead, NiFi Registry would just add the NiFi FDS sub-project as a client
side dependency in its package.json. This would be analogous to how NiFi
Registry depends on Angular Material, etc. npm supports the ability to
download published packages which are current with the latest stable
release of a package. npm *also* supports the ability to develop off
of the *master
branch (or any other branch really)* of the NiFi FDS. An example of this
can be found in the github.io demo here
<https://github.com/scottyaslan/fluid-design-system/blob/gh-pages/package.json#L45>
. By placing that dependency in the package.json for the NiFi Registry each
subsequent clean build would automatically download the latest master
branch of the NiFi FDS sub-project and developers can leverages the latest
NiFi FDS components.

This also brings up a good point about release management. I have also
included a prototype of one possible implementation of automating the
tagging of a branch and automatically updating release version numbers etc.
leveraging grunt-bump [1]. The FDS-0.0.1-RC.0 tag [2] was created with the
described grunt task.

[1]
https://github.com/scottyaslan/fluid-design-system/blob/master/Gruntfile.js#L47

[2] https://github.com/scottyaslan/fluid-design-system/tree/FDS-0.0.1-RC.0

On Thu, Feb 22, 2018 at 12:39 PM, Sivaprasanna <sivaprasanna...@gmail.com>
wrote:

> I agree with Matt. With clear documentation and guides, contributions on
> the sub-projects can be streamlined and be ensured that the necessary
> changes are already available on the core project i.e NiFi. One challenge
> is that the committer of the sub-project should have the courtesy to check
> wether the supporting changes are made available to the core project and
> track its status but given how contributions are being handled in
> nifi-registry project, I don’t think it’s going to be that much of a
> headache.
>
> We could also add to the helper doc mentioning that if the contribution is
> going to affect a core component, the contributor needs to add the JIRA id
> of the core project’s supporting changes in the sub-projects’ issue
> description.
>
> On Thu, 22 Feb 2018 at 10:42 PM, Matt Gilman <matt.c.gil...@gmail.com>
> wrote:
>
> > Joe, Joe,
> >
> > Regarding the release process... I think it could be similar to how folks
> > verified and validated the NiFi Registry release. Guidance was given in a
> > helper guide regarding how to obtain/build a branch or PR that references
> > the new components. For the Registry release, there was a PR for NiFi
> that
> > had the supporting changes already available.
> >
> > We may have this issue any time we release new versions that depend on
> > another (sub)project.
> >
> > Matt
> >
> > On Thu, Feb 22, 2018 at 11:39 AM, Joe Percivall <jperciv...@apache.org>
> > wrote:
> >
> > > Scott,
> > >
> > > Definitely like the direction of standardizing NiFi and Registry around
> > the
> > > same set of components, so the user has a common UX. Is there precedent
> > for
> > > creating a new sub-project just for common components/modules to be
> used
> > by
> > > the top-level, and it's other sub-projects? My concerns are similar to
> > > Joe's. Along those lines, if the core problems we're trying to address
> is
> > > the release process and distribution, is there a less "heavy-weight"
> > > avenue?
> > >
> > > In the past, we've also talked about pulling out the core NiFi
> framework
> > to
> > > be shared between NiFi and MiNiFi-Java for similar reasons. How we go
> > about
> > > solving this for the UI could be used a model for the core framework as
> > > well.
> > >
> > > - Joe
> > >
> > > On Thu, Feb 22, 2018 at 10:58 AM, Mike Thomsen <mikerthom...@gmail.com
> >
> > > wrote:
> > >
> > > > Also, what sort of framework is the UI being standardized on?
> Angular?
> > > > React? Something else?
> > > >
> > > > On Thu, Feb 22, 2018 at 10:03 AM, Joe Witt <joe.w...@gmail.com>
> wrote:
> > > >
> > > > > Scott
> > > > >
> > > > > Ok so extract out the fluid design work you started with NiFi
> > Registry
> > > > > to its own codebase which can be rev'd and published to NPM making
> it
> > > > > easier to consume/reuse across NiFi projects and offers better
> > > > > consistency.  This sounds interesting.
> > > > >
> > > > > In thinking through the additional community effort or the effort
> > > > > trade-off:
> > > > > How often do you anticipate we'd be doing releases (and thus
> > > > > validation/voting) for this?
> > > > > How often would those differ from when we'd want to do a NiFi or
> NiFi
> > > > > Registry release?
> > > > > How do you envision the community would be able to help
> vet/validate
> > > > > releases of these modules?
> > > > >
> > > > > Thanks
> > > > > Joe
> > > > >
> > > > > On Thu, Feb 22, 2018 at 8:18 AM, Scott Aslan <
> scottyas...@gmail.com>
> > > > > wrote:
> > > > > > NiFi Community,
> > > > > >
> > > > > > I'd like to initiate a discussion around creating a sub-project
> of
> > > NiFi
> > > > > to
> > > > > > encompass the Fluid Design System NgModule created during the
> > > > development
> > > > > > of the NiFi Registry. A possible name for this sub-project is
> > simply
> > > > > > "NiFi Fluid
> > > > > > Design System". The idea would be to create a sub-project that
> > > > > distributes
> > > > > > an atomic set of high quality, reuse-able, theme-able, and
> testable
> > > > UI/UX
> > > > > > components, fonts, and other JS modules for use across the
> various
> > > web
> > > > > > applications throughout the NiFi universe (uNiFiverse???). Both
> > NiFi
> > > > and
> > > > > > NiFi Registry web applications would eventually leverage this
> > module
> > > > via
> > > > > > npm. This approach will enable us to provide our users with a
> > > > consistent
> > > > > > experience across web applications. Creating a sub-project would
> > also
> > > > > allow
> > > > > > the FDS code to evolve independently of NiFi/NiFi registry and be
> > > > > released
> > > > > > on it's own timeline. In addition, it would make tracking
> > issues/work
> > > > > much
> > > > > > clearer through a separate JIRA.
> > > > > >
> > > > > > Please discuss and provide and thoughts or feedback.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Scotty
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > *Joe Percivall*
> > > linkedin.com/in/Percivall
> > > e: jperciv...@apache.com
> > >
> >
>

Reply via email to