-
Notifications
You must be signed in to change notification settings - Fork 36
Plugin Development Organization
Given that people are now writing plug-ins, we need to be ready to solve the following issues that will arise as a result of this:
- We'd like some of our plug-ins to be created as external projects so plug-in developers can more easily see exactly what is required to write a plug-in, without requiring a complete knowledge of the project.
- We would like to make it easy to take ownership of optional, but broadly useful plug-ins (so that re-factoring keeps them in sync with any API changes), without the expense of internalizing them.
- We'd like to make it easy for people to discover optional plug-ins, and start making use of them.
- We think that external projects that have their own documentation and issues tracking is a better way to incubate plug-ins to the point where they can be contributed back to BladeRunnerJS for maintenance.
- We'd like to have a separate project for core plug-ins since having the code in the same project is currently leading to an unhealthy set of dependencies from the model to the plug-ins.
To achieve this, we are proposing the following Gradle project structure:
- All non plug-in code.
- Same repository as 'brjs-core' but a different project to prevent dependencies from 'brjs-core' to 'brjs-core-plugins'.
- One project per plug-in.
- Makes it easier for other developers to see how to write them.
- The user's help command won't get bombarded with stuff they don't need to see.
- They can have their own documentation and issues, etc.
Optional plug-ins can become contrib plug-ins, where we take ownership of the github project, but leave them as external projects on the basis that it's cheaper not to integrate them, and that they may not adhere to our coding practices, or be adequately tested. Although we're happy to maintain contrib plug-ins as we re-factor our interfaces, we'll won't make the same guarantees about the quality of contrib plug-ins.
The advantages of contrib plug-ins are:
- Previous releases of these plug-ins can also be used for backwards compatibility testing.
- They can be linked to our main project using git subtrees so these plug-ins are kept up to date as we re-factor.
Additionally, we are also proposing that we maintain a list of maintained optional plug-ins, and external optional plug-ins, so these plug-ins are easily discoverable via the community.