I’m working on my first plugin <https://wiki.jenkins-ci.org/display/JENKINS/Label+Linked+Jobs+Plugin> and I’m trying to understand in details the ExtensionPoint approach, as well as the Descriptor/Describable framework. The first version of my plugin had only one extension point <https://github.com/jenkinsci/label-linked-jobs-plugin/blob/master/src/main/java/jenkins/plugins/linkedjobs/extensions/LabelExtension.java> extending LabelAtomProperty, with an inner Descriptor class extending LabelAtomPropertyDescriptor and its corresponding global.jelly file to show a section in Jenkins configuration page. All good. Things became interesting when I tried to add a second extension point to my plugin. Because I didn’t want to have several sections for my plugin settings in the Jenkins configuration page, I decided to use one common descriptor for my whole plugin. However I didn’t like the idea that the Descriptor for a particular extension would contain a mix of code to configure other parts of my plugin, so I didn’t want to use the descriptor of one my extension points. I created a separate LabelPluginSettings <https://github.com/jenkinsci/label-linked-jobs-plugin/blob/2.0-release/src/main/java/jenkins/plugins/linkedjobs/settings/LabelPluginSettings.java> class that is NOT an ExtensionPoint, extending AbstractDescribableImpl of itself, with an inner class extending Descriptor of itself. And it’s now this class that has a global.jelly shown on the Jenkins configuration page. I like this approach because I have a central class handling global configuration of the whole plugin, and each ‘true’ extension points is not polluted by code belonging to other extension points.
I’m wondering if this is an ok approach or whether I missed something in the plugin framework. I would be interested in checking the code of a plugin implementing several extension points and having one single section in Jenkins configuration page to configure them all. Last curious point: as a result of this approach, the inner descriptor class of my LabelPluginSettings class has to implement method getDisplayName(), which is never shown in Jenkins. That also makes me wonder what I may have done wrong. Thanks! -- View this message in context: http://jenkins-ci.361315.n4.nabble.com/Have-a-common-config-section-for-several-plugin-ExtensionPoints-tp4718868.html Sent from the Jenkins dev mailing list archive at Nabble.com. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
