Reputation: 9476
I'm working on custom Eclipse/CDT based IDE. Up until now this was just a product based on Eclipse/CDT with custom plug-ins. I export this as product and update site and this works well enough.
But now I need to make a small change to one of CDT plug-ins. For this I imported (only) that plug-in in question from eclipse repository and modified it. Now, with this plug-in loaded in my workspace, this version seems to take precedence over baseline, but the baseline feature containing this plug-in still requires hard-coded version of this plug-in. If I add hard-coded version number to my copy of this plug-in and then I can export product. Exported version contains the change and it works fine. But this is obviously wrong thing to do (as patched plug-in now poses for original one). I guess I can import more of CDT into my workspace and export all that, and it would work without modifying version numbers. Downside is that users probably can-not use default eclipse update site to install anything, as they could overwrite patched version of plug-ins with later release of unpatched ones?
I have read obvious blog-posts on feature patches (a feature lacking documentation I must say :) ). I added feature patch for this feature and then my modified plug-in to list of required plug-ins of this feature patch. I can export patch feature (with plug-in version at default something.qualifier in plug-in and to "copy from plug-in and fragment manifests" in feature patch plug-ins).
However I'am still unable to export my product. When I try to do export, it still wants original version of plug-in, which it now can not find.
So, the questions that bugs me the most: What is the right way to release Eclipse product with minor change to one of "base" plug-ins and still allow users to use generic Eclipse (eclipse.org) update sites (to install different products, for example)?
Or at least what is the best way to release a product with modified base plug-in?
Upvotes: 2
Views: 66
Reputation: 721
If the change is one liner then you might consider using OSGi adapter hooks. In such a hook you can perform required modification via bytecode modification library (e.g. ASM). This is not trivial but gives pretty good results when the code you're modifying is stable across Eclipse releases. Users might upgrade Eclipse and the newer plugin will get overridden with no problems.
If you don't want to play with the bytes though the best way is to pull the feature containing the modified plugin into your sources. No easy solution to the upgrade problem though. Either you block upgrades by bumping the modified plugin's version (and disabling Eclipse updates sites) or you allow overriding your change.
Upvotes: 1