Fluxnova Modeler: Plugin & Testing Framework Strategy

[bryankenneally]

Executive Summary

This strategy outlines a comprehensive approach for the creation, management, and distribution of plugins and a testing framework for the Fluxnova Modeler.

Key objectives:

• Enable efficient collaboration between FINOS and the broader community
• Establish governance, technical standards, and contribution guidelines for plugins and the testing framework
• Ensure high-quality, discoverable, and reusable plugins to accelerate process automation and model development
• Create Git repositories where appropriate to store plugins and testing framework code

Background and Context

• Extensibility through Plugins: Plugins transform the Modeler from a generic BPMN editor into a tailored development environment, supporting modeling standards, workflow streamlining, and custom logic integration. This modularity promotes maintainability, portability, and community-driven innovation.
• Robust Process Testing: A dedicated testing framework allows users to validate BPM processes and scripts, generate coverage reports, and ensure reliability prior to deployment. The framework is being refactored to maximize reusability and accessibility for the community.

Current Limitations

• Many plugins are highly specific to individual organizations, limiting their broader applicability
• Lack of standardization across plugins leads to duplicated code and inconsistent quality
• Plugins are not catalogued or made easily discoverable for the community
• No shared code or common tooling between plugins
• A testing framework is not yet available as a reusable base for the community, limiting collaboration and standardization

Solution Overview

Contribution Guidelines:

• Contribute to open source if functionality is broadly applicable, generic, and non-proprietary
• Retain internally if functionality is organization-specific, proprietary, or experimental
• Use a simple decision flow to guide contribution targeting

Repository Structure and Ownership:

• All open-source, broadly useful plugins should be contributed to the FINOS-owned Fluxnova plugins repository (https://github.com/finos/fluxnova-plugins)
• Each plugin should have its own subdirectory, with utilities to scaffold new plugins and ensure consistency and adherence to best practices
• Work with FINOS to request the creation of a new repository dedicated to the testing framework, ensuring it is accessible and maintainable for the community (https://github.com/finos/fluxnova-testing-framework)

Standardizing Publishing Practices:

• Publish all open-source plugins to the public npm registry with "fluxnova", "modeler", "plugin" keywords for discoverability
• Use semantic versioning, clear metadata, and provide documentation and CI/CD pipelines
• Publish the testing framework to Maven Central with similar standards

Next Steps and Implementation Plan

• Socialize and review the strategy with FINOS and the community
• Create new GitHub repositories as needed
• Define and document contribution guidelines and provide scaffolding tools
• Contribute testing framework and review community feedback
• Contribute plugins
• Monitor and improve plugin quality, bundle sizes, etc.

[bryankenneally]

Full Stack Plugins

Some plugins may require both backend and frontend components (“full stack plugins”) to deliver their functionality. For these:

• If the plugin is considered core to the Fluxnova platform:

  • The backend component should be versioned and deployed alongside the engine
  • The frontend component should either:
    • Reside directly in the modeler source code, or
    • Be packaged as a plugin that is maintained in the modeler repository

• If the plugin is optional (not core to the platform), it should be managed in the plugins repository, following the same contribution, publishing, and governance standards as other community plugins

This strategy balances the need for tightly integrated, reliable core features with the flexibility and discoverability of a plugin ecosystem

[pieter-schutte]

Thanks for this guide, I think it is sensible. My outstanding questions are:

1. Is there a release cycle? Do we tie it to the main release cycle or do we just merge a pr and that is the latest available version of a plugin?
2. Is there scope for packaging up related plugins, e.g. all the mcp ones
3. How do we promote these

@finos/fluxnova-maintainers thoughts?

[bwright-scottlogic]

Given this, if I refactor my MCP plugin, we will end up with:

fluxnova-plugins/
│
├── frontend/
│   ├── ...
│
├── backend/
│   ├── mcp-server-plugin/
│
├── fullstack/
│   ├── mcp-process-start-event/
│   │   ├── frontend/
│   │   └── backend/

I dont like the fact that the MCP related items are not grouped together, but it might be best for long term maintenance

Some more thoughts from @finos/fluxnova-maintainers please

I think the frontend/backend/fullstack works well. With regards to MCP items not being grouped together, I don't think (from the looks of things) there currently are / will be enough MCP plugins for the foreseeable across the different layers to warrant an individual MCP folder. So unless there are any major objections / bad experiences with having a layered directory design with individual plugins sitting in each, I'm happy to go with that.

[tom-stavert]

I also agree with the approach of splitting frontend/backend/fullstack, I think this provides the best user experience for optional plugins. I've created a version of the MCP Workflow Query plugin following this folder structure and removed the parent level pom. I think this is the best approach for optional plugins but we will need to consider how to ensure they are all built and published to maven.

[bryankenneally]

I've added an item to the maintainers' meeting on 30/04 to try to finalize our initial strategy around the process of contributing plugins

One concern that's been raised is should we have separate repositories for modeler and engine, in order to more closely align with their architectural separation, simplify ownership, release processes, etc.

[pieter-schutte]

Update for todays WG. My concerns can probably be addressed with documentation, so happy with the approach outlined by @bryankenneally. My only request is we get the current prs merged and then relocate.

[tom-stavert]

We have adopted the structure outlined by @bryankenneally in the MCP Workflow Query plugin and in our future agentic AI subprocess work, so will proceed on that basis unless there is any objection/alternative structure proposed.

[bryankenneally]

I spoke with @HarishMalavade on the proposed strategy last week, and while the core goals remain the same, our thinking has shifted in a few important ways, mainly around how we conceptualise plugins and how we organise repositories and CI/CD.

What stays the same?

• Plugins are core to Fluxnova extensibility
• We want high-quality, reusable, discoverable plugins
• They should be centrally-published and easily-consumable
• Publishing should be automated where possible, consistent, and easy for contributors

What has changed?

• Instead of thinking in terms of frontend, backend, and full-stack plugins, we now frame everything as modeler (design-time) and engine (runtime) plugins
• Features that require both are treated as coordinated plugin pairs rather than a separate "full-stack" category
• Each plugin is still independently built, tested and published
• They can share a single version, be released together, and be documented as one feature
• A new repository should be created for modeler plugins, while the existing "fluxnova-plugins" can be used for engine plugins

Why the change?

• Modeler vs. engine aligns better with platform boundaries, makes ownership clearer
• Simplifies CI/CD not having to support polyglot monorepo
• The "full-stack plugin" concept was ambiguous and overloaded

Proposed Repository Structure

Engine

fluxnova-plugins/            # engine-specific plugins
├─ LICENSE
├─ NOTICE
├─ README.md
├─ pom.xml                   # parent POM
├─ .github/
│  └─ workflows/
│     ├─ ci.yml              # mvn verify
│     └─ release.yml         # Maven Central publish
├─ tooling/
│  ├─ parent-pom/            # shared config
│  └─ archetype/             # plugin scaffolding
└─ plugins/
   ├─ mcp-server-plugin/
   │  ├─ pom.xml
   │  ├─ README.md
   │  └─ src/
   │     ├─ main/java/
   │     └─ test/java/
   └─ mcp-start-event/
      ├─ pom.xml
      └─ src/

Modeler

fluxnova-modeler-plugins/
├─ LICENSE
├─ NOTICE
├─ README.md
├─ package.json              # workspace root
├─ .github/
│  └─ workflows/
│     ├─ ci.yml              # build + test
│     └─ release.yml         # npm publish
├─ tooling/
│  └─ create-plugin/         # scaffolding
└─ plugins/
   ├─ code-editor/
   │  ├─ README.md
   │  ├─ package.json
   │  └─ src/
   │     └─ index.ts
   │     ├─ lib/
   │     └─ util/
   └─ mcp-start-event/
      ├─ README.md
      ├─ package.json
      └─ src/

[bwright-scottlogic]

Thanks for the revised strategy. It feels a lot more intuitive, and actually resolves a lot of the ambiguities we had surrounding the structure of our agentic ad-hoc subprocess plugin.

[pieter-schutte]

I agree with this.

[pieter-schutte]

I have raised an issue for the fluxnova-plugins repo here: finos/fluxnova-plugins#16

I feel we need to implement it after some of the existing PR's get merged.

[pieter-schutte]

@bryankenneally - what do you envisage going in the tooling folder in the fluxnova-plugins repo?

[bryankenneally]

@pieter-schutte Our initial thinking in terms of tooling might be to provide a Maven archetype that can help scaffold new plugins, so that they adhere to a common structure, follow best practices and standards, etc.