Scott, I understand the vision. I was actually echoing what Matt said i.e. if the contributions being made to the sub-project has any supporting changes that *should* exist in the core-project i.e. NiFi or any other projects that use this sub-project, they have to be checked by the committer. But you have made it clear that it's going to be a npm module so I understand it better now. Disregard my previous comment.
- Sivaprasanna On Fri, Feb 23, 2018 at 9:16 AM, Tony Kurc <[email protected]> wrote: > 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] > > > > > > > > > > > > > > >
