Hudson is primarily a set of Java classes that model the concepts of a build system in a straight-forward fashion (and if you are using Hudson, you've seen most of those already). There are classes like Project, Build, that represents what the name says. The root of this object model is Hudson, and all the other model objects are reachable from here.
Then there are interfaces and classes that model code that performs a part of a build, such as SCM for accessing source code control system, Ant for performing an Ant-based build, Mailer for sending out e-mail notifications.
Those Hudson classes are bound to URLs by using Stapler. The singleton
Hudson instance is bound to the "/" URL, and the rest of the objects are bound according to their reachability from this root object.
For example, there's the
Hudson.getJob(String) method. So the URL
/job/foo/ will be bound to the object returned by
Hudson.getJob("foo") (which would be a
Project object that corresponds to the "foo" project. See stapler documentation for more about how it binds Java object model to a URL hierarchy.
Hudson model objects have multiple "views" that are used to render HTML pages about each object. Hudson uses Jelly as the view technology (which is somewhat similar to JSP+JSTL.) Views are really like methods, and each of them work against a particular class. So the views are organized according to classes that they belong to, just like methods are organized according to classes that they belong to. Again, see the stapler project for more about how this works.
Hudson defines a few Jelly tag libraries to encourage views to have the common theme. For example, one of them defines tags that form the basic page layout of Hudson, another one defines tags that are used in the configuration pages, and so on.
Hudson uses the file system to store its data. Directories are created inside
$HUDSON_HOME in a way that models the object model structure. Some data, like console output, are stored just as plain text file. Some are stored in Java property file format. But the majority of the structured data, such as how a project is configured, or various records of the build, are persisted by using XStream.
This allows object state to be persisted relatively easily (including those from plugins), but one must pay attention to what's serialized in XML, and take measures to preserve backward compatibility. For example, in various parts of Hudson you see the
transient keyword (which instructs XStream not to bind the field to XML), fields left strictly for backward compatibility, or re-construction of in-memory data structure after data is loaded.
Hudson's object model is extensible (for example, one can define additional SCM implementations, provided that they implement certain interfaces), and it supports the notion of "plugins," which can plug into those extensibility points and extend the capabilities of Hudson.
Hudson loads each plugin into a separate class loader to avoid conflicts. Plugins can then participate to the system activities just like other Hudson built-in classes do. They can participate in XStream-based persistence, they can provide "views" by Jelly, they can provide static resources like images, and from users, everything works seamlessly --- there's no distinction between functionalities that are built-in vs those from plugins.