Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-7061

Plugin/extension handling improvements

XMLWordPrintable

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • core
    • None

      Hello, I've made a few improvements to PluginStrategy and a few other components related to plugin/extension handling. I have implemented a few of the features I've mentioned in previous emails. I've done my best to make the changes as minimal as possible, while still allowing the flexibly that my integration of JSR-330 components requires. The changes are available in my github fork here:


      I've introduced a DescribableFactoryDelegate interface which is used by Descriptor.newInstance(StaplerRequest, JSONObject) to do the work of constructing Describable instances. This object is created by PluginStrategy.getDescribableFactoryDelegate(). I've also created a ClassicPluginStrategy.DefaultDescribableFactoryDelegate which provides the exact same behavior for instance creation via Stapler.

      The diff of this change is here:

      This allows the PluginStrategy to have better control over how Describable instances are created. In my case, it gives me the ability to ask my container for the instance if it has the ability to construct+wire it for me, or else I can delegate back to the ClassicPluginStrategy.DefaultDescribableFactoryDelegate as per-normal and optionally request that the constructed object receive injection of its members.


      The other change I made, was to allow the PluginStrategy to have complete control over how extensions are located. I introduced an ExtensionLocator component, which is created by PluginStrategy.getExtensionLocator. It has a simple locate() method which resembles ExtensionFinder.find(). It is used by ExtensionList.load(), which instead of asking a set of finders to find, asks the single locator to locate(). To provide compatible functionality with finders, I've created ClassicPluginStrategy.DefaultExtensionLocator which performs the equivalent location method as before, find from a set of finders, find the finders by using ExtensionFinder.Sezpoz.

      The diff of the change is here:

      http://github.com/jdillon/hudson/commit/13fc9cfcdae7f7bc48a0e7b621faf297a18768a6

      The current ExtensionList/ExtensionFinder code is a little bit muddled IMO and could be simplified a lot more, but I've done my best to only change what was needed to make extension location more flexible and controllable by the installed strategy.


      I have done some limited testing and I believe that these changes are completely compatible with how Hudson works today. Hudson seems to be fine using the locator to discover extensions and seems equally happy creating describables via the delegate. Both of these changes should help developers to integrate different components models, like JSR-330 which is what I'm working on, while maintaing compatibility with the current extensibility mechanisms which are in place.

      I would like to have these changes applied, can someone please review them? Patches attached.

            Unassigned Unassigned
            user57 user57
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated: