Jenkins plugin architecture - what would you change?
Brad Larson
have worked on the internals of the plugin architecture.
The git-together conference and Gerrit hack-a-thon is coming up, and
one topic of discussion will be supporting plugins in Gerrit. The
Jenkins plugin structure is great and is one of the key features which
has made Jenkins the top CI solution it is today. We'd like to
investigate solving some problems in Gerrit which Jenkins has solved
through plugins (supporting multiple methods of authentication,
customizing the response to uploaded changes, different methods of
user notification, etc, etc).
The real question is - Given what you have learned from the Jenkins
plugin framework development, what would you change and what would you
keep the same? If you were to start over with the tools available
today, would you do anything significantly different? Would you use
OSGi or some other framework?
Any feedback is greatly appreciated!
Thanks!!
Brad
Kohsuke Kawaguchi
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!
--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Nectar, our professional version of Jenkins