I’ve been working on an OSS project during my spare time which is deeply intertwined with Terracotta Quartz. Because of the nature of the project, I do not interface with Quartz through the standard API (no bundling), but am accessing it via JMX MBean. This is not an easy task, as there are large differences between Quartz 1.x and Quartz 2.x exposed methods and bundling Quartz in the project distro is not an option. Since I plan to support different versions of Quartz, it is left up to my adapters to figure out what version someone has installed and how it should access remote methods. Any guess to what I’m building? ;–)
One thing I was unable to find is how the important Quartz objects relate to each other. In the past, I’ve implemented Quartz in projects, but never really dug around at its internals. Even while implementing Quartz, I found I often ended up with a one-to-one relationship between the major components. Instance –> Schedule –> Group –> (many)Job.
But wouldn’t you know it – Quartz is a lot more flexible than that, allowing many-to-one relationships for several components. Here is a rather raw diagram of how all the pieces pay together. I didn’t do a very good job of showing the many-to-one relationships in the model, but you get the point.
Frankly, I would never have discovered this under normal use, and had to dig around with the JMX MBean to visualize this. It may be documented somewhere, but I couldn’t find it.
Quartz’ flexibility is great, but building a UI around this is going to be interesting. ;–)