Is some of the thinking that projects other than nifi projects would use this?
On Feb 22, 2018 10:00 PM, "Scott Aslan" <[email protected]> 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 <[email protected]> > 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 <[email protected]> > > 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 <[email protected] > > > > > 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 < > [email protected] > > > > > > > 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 <[email protected]> > > 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 < > > [email protected]> > > > > > > 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: [email protected] > > > > > > > > > >
