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

Well, I do not know anything about the details of the technology you mentioned, but the best way to fulfill your "additional requirements" is probably:

  • convince the maintainer of the original plugin to integrate the changes you need into the trunk

Make sure your changes are done in a backward-compatible way, so other users of the plugin can use it still in the original way, if they like, or in the enhanced way, if they prefer that. You should also test your changes well before you make a pull-request to the maintainer, and make sure it will fit into the existing design, that will probably increase the chances of getting your changes merged into trunk.

  • I totally agree, and I do think that my situation is not a good one. Unfortunately, the analytics platform maintainers have made it clear that they won't allow external pull requests at this time. They just got their source on GitHub a month or two ago (on year 10+ of their open-source development). My modification will be invaluable in-house, as we use the platform. I'm hoping I can maintain it well, as you mentioned, and then eventually get it pulled into master when they start accepting pull requests. Until then, the only solution I see for end users is to maintain a second plugin. – joe55 Apr 27 '17 at 17:47
  • @joe55: you could fork on GitHub and make your changes public. If your fork becomes popular, it might increase the motivation of the maintainers to integrate your change. – Doc Brown Apr 27 '17 at 17:53
  • I totally agree. Unfortunately, end-users always download a pre-packaged executable built by the maintainers in order to install the analytics platform, so my fork would probably never see the light of day. And I am by no means a master coder. – joe55 Apr 27 '17 at 17:57

In OSGi you can easily byte code weave other bundles. If register a WeavingHook service then you get a chance to change the byte codes of bundles that are loaded after you. The trick might be to register early enough.

Using Aspect oriented programming libraries you could simplify selecting the actual target.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.