Is some of the thinking that projects other than nifi projects would use
this?

On Feb 22, 2018 10:00 PM, "Scott Aslan" <scottyas...@gmail.com> wrote:

> 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