...

• nifi: will have been broken up into nifi-api, nifi-framework, nifi-extensions, nifi-release
  • Alternatively: this repo could be reduced to a single pom module containing the org.apache.nifi:nifi pom that inherits from org.apache:apache and can be a parent pom for other projects.
• nifi-minifi: will become a new assembly of nifi-framework and nifi-extensions that lives in the nifi-release repo

Proposed Approach

Phase 1: nifi

Decompose nifi project/repo into:

...

1. One or more community volunteers will manually attempt the above steps, taking detailed notes of commands they use and changes (such as pom files) that they need to make in order to get everything working.
2. From those notes, a script that streamlines (automated as much as possible) restructuring the nifi repository into new repositories will be written. This will enable us to repeatedly perform the restructuring from any given revision of the master branch.
3. The restructuring automation script(s) and instructions for use will be distributed on this mailing list to the nifi community. The NiFI community will be asked to verify them and the resulting output in a manner similar to an RC verification vote. The final output assembly of the restructured process should match the output assembly of the current nifi-assembly module from the 1.x line on master today.
4. The automation process will go through as many reviews as needed until it passes a vote by the NiFi PMC.
5. A specified date and time will be chosen for the restructuring. Any large branches from master should be merged before that date to avoid burdensome rebasing that will be necessary for any changes not merged before the restructuring.
6. On the agreed upon date and time, with the assistance of ASF Infra, the existing nifi repository will be frozen from modification. The restructuring script will be run and the resulting repositories will be added as top level github repositories, again, with the help of ASF infra.
7. Unmerged pull requests to the nifi repo that were under active development will need to be recreated as PRs to the new repositories. This will fall to the PR authors. PRs will stay open to the old nifi repository for a time as a historical record, but only those that are recreated by their authors will be considered to be merged to the new repositories.
8. Contributions continue as normal, but from forks of the new repositories.
9. The first release after the restructuring will be a release from all repositories/projects (in the order dictated by the dependency tree shown above). After that, releases will only need to be performed as needed from each repository/project.
   • NOTE: There should be a community discussion on how versioning and releasing of the new, smaller projects should be handled. That is, should we always release everything so that versions stay aligned, even if there are not changes to a particular component such as nifi-api, which changes very infrequently, or should we follow semantic versioning for each new project and allow them to advance and be released independently of each other and only as needed.

Phase 2: nifi-commons

Introduce nifi-commons as a home for shared, top-level, reusable libraries of components across the new collection of projects

...

1. A new nifi-commons project and repository is introduced.
2. Similar code across nifi-framework and nifi-registry, and possibly other projects such as nifi-toolkit and nifi-extensions, is rewritten as generic, reusable libraries in sub-modules of nifi-commons, e.g., nifi-commons-security could contain shared authentication and authorization APIs and provider implementations.
3. Code from nifi-framework, nif-registry, etc. is removed and replaced with library implementations from nifi-commons modules.

Phase 3: nifi-minifi

Migrate code modules from nifi-minifi into nifi-framework, nifi-extensions, and (possibly) nifi-commons. Migrate the nifi-minifi assembly into nifi-release.

Additional Potential Phases

...