| Issue 861: | Plugin Support | |
| 17 people starred this issue and may be notified of changes. | Back to list |
There are several places that would be nice to be able to customize with plugins. Notifications are an example: Different notification rules for different companies. For example, we'd want a global email notification on new code to review. IRC notifications for people who use IRC, and jabber notifications for people who want that. Asking this all to be in the main code base seems like overkill, but if writing plugins was easy, then I'm sure people would step up to add their favorite feature. Ciao!
May 20, 2011
+1, this would be awesome. I recommend Jenkins/Hudson as a good model to at least get some implementation ideas. There are tons of extension points in the main codebase and hundreds of plugins out there to do all sorts of things. Notifications over IM/SMS, change the look & feel of the web UI, add support for different backends, etc.
May 20, 2011
(No comment was entered for this change.)
Blocking:
618
Jul 20, 2011
(No comment was entered for this change.)
Blocking:
1060
Oct 21, 2011
I'd like to discuss this feature at git-together/the hack-a-thon. I asked the Jenkins dev-list about their plugin architecture [1], as I feel like it is incredibly well-done (at least from a plugin author perspective). Here is the response from KK: I'm actually happy with most of the choices. ServiceLoader style extension lookup of annotated classes (via sezpoz) was good. It was simple to do, allowed Jenkins to tolerate broken plugins easily. Much later we added Guice, and while that brought some good things, we lost some of the resilience to broken plugins, and at times I feel like it's not quite designed for the purpose I'm using it for. I will refrain from commenting on OSGi. I had a pretty horrible experience, but that was a few years ago, and I hear some people say tooling has improved since then. My wound hasn't healed yet, and given the architecture of Jenkins, we won't enjoy some of the benefits of OSGi anyway. Update center was very useful in a number of ways, so is having the whole development cycle packaged as a custom Maven life cycle (but if I am to do this all over, I'd try Gradle first.) In case of Gerrit, I think the major challenge is how you'd let plugins to alter the UI and extend the URL tree space. This is the main reason I had to write Stapler to do Jenkins. AIU, Gerrit uses GWT, which makes runtime UI assembly rather difficult. My advice would be to prioritize. IMHO it's far more important to spend time opening up the interesting pluggability point in the core than to spend time implementing fancy plugin runtime infrastructure. By "opening up pluggability points" I mean defining abstractions that the core uses by itself, allowing plugins to participate in the UI. Put another way, try to implement some of your current core functionalities as plugins. And by "fancy plugin runtime infrastructure", I mean things like nicely isolated classloaders, update center and all the backend that comes with it, and things of that sort. Those things can be added later without breaking compatibility. Good luck with your endeavor! [1] http://groups.google.com/group/jenkinsci-dev/browse_thread/thread/4640eed6d782887a
Nov 13, 2012
Marking this released, since it was introduced in 2.5 (which is now final). Requests for additional plugin points should get their own bugs.
Status:
Released
Nov 13, 2012
(No comment was entered for this change.)
Labels:
FixedIn-2.5
|
|
| ► Sign in to add a comment |
Cc: edwin.ke...@gmail.com