A little background on the system I’m dealing with:
analytics platform --comprised of--> OSGi plugins --comprised of--> Java package(s) --containing--> unit(s) of functionality each with independent MVCs (called “nodes”)
The plugin I would like to augment is called “base”, and all of the analytics platform end-users use it by default. It is open-source, standard with the analytics platform, and exposes a Java API. I would like to augment a node inside of base. The node is called “File Reader”.
What I need to do: I need to provide an additional augmented version of the “File Reader” node with one change: I need to add a checkbox to disable auto-casting of data input to the node, and implement the disablement.
Additional Requirements:
- Provide the Augmented File Reader in an additional OSGi plugin which users can download and install
- Ensure the additional plugin can be used alongside plugin “base” without causing issues. I.e., ensure that end-users can use both the original “File Reader” node and my new node “Augmented File Reader” simultaneously
- Keep “Augmented File Reader” up-to-date with bugfixes and updates to “File Reader”
- Maintain multiple releases of my plugin corresponding to multiple releases of the plugin “base”
Challenge: The natural choice is to extend the File Reader’s available API. However, some of the original File Reader node’s functionality is package-private, specifically parts of the MVC’s view. I could try to extend (via inheritance) as much as I can from the API exposed by File Reader, then replicate File Reader’s package-private view in my custom plugin. However, replicating the view would cause me to duplicate 500-2000 lines of code. All I want to do is insert a checkbox that will disable one unit of default functionality in the original File Reader, which should be easy, since it’s Swing. My feature would probably change 5-30 lines of code. Therefore, I don’t think it merits re-implementing the view.
Important notes brought up by discussion with Doc Brown:
The maintainers of the analytics suite have made it clear that they will not accept pull requests at this time.
Also, if I fork the maintainer's git repo and implement the feature in an augmented "base" plugin, end-users simply will not be willing to use my version of the plugin, since it includes so much functionality (99% of which doesn't concern what I'm trying to do).
Has anyone else encountered this situation? Is there a standard way to handle it?
My best idea on a solution as of now (please comment and criticize):
- Branch the original “base” plugin’s codebase (git) in order to add the feature
- maintain the code of “base” as if I was simply adding a feature to the File Reader node in a new branch of plugin “base”
- Make a custom build: include only the the augmented File Reader node in my plugin
- Also in custom build: in order to ensure that there are no package/class conflicts with plugin “base” at loading/runtime, use some sort of pre-compilation refactoring macro to rename classes, packages, and anything else that could cause conflicts
