Many plugins use the Plugin class [1] to store common configurations. But the GlobalConfiguration extension point [2] is the "new best practice approach" I guess.
[1] http://javadoc.jenkins-ci.org/hudson/Plugin.html [2] https://wiki.jenkins-ci.org/display/JENKINS/Extension+points#Extensionpoints-jenkins.model.GlobalConfiguration /B On Mon, Sep 8, 2014 at 2:28 PM, dominiquebrice <[email protected]> wrote: > 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. > -- Robert Sandell *Software Engineer* *CloudBees Inc.* -- 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.
