What we are currently seeing, when using Quartz with Spring Boot, is that only the high level configurations are available through properties. There is no way at the moment to configure the job details and triggers out of the box without creating a configuration. The problem is that we always kind of do the same configuration over and over again per projects.

I've created an example of how we fix the problem internally but we also think it would be possible to do something with an annotation (I.E @QuartzJob with attributes) or something similar. Even the first implementation could be based on properties only with auto-configuration.

I'm sharing with you an example of what we did so that the discussion can be started on how this could get improved with future releases of spring.

https://github.com/sambrodeur/quartz-job-auto-configuration

I would be happy to discuss this further if needed. I'm also going to try to find a solution that is using annotation if it could help the sharing of ideas with your team.

Comment From: snicoll

@sambrodeur thanks for the suggestion. Configuration property for a Class is usually a red flag as we'd prefer to use code and compiler validation for them. Looking at the sample, you're providing the name of the class and a cron expression. CronScheduleBuilder also has high-level methods that are better than writing a cron for simple use cases.

All in all, I don't think that what's suggested here is general enough to be included. If what you've built works for you, then I'd suggest continuing using it. I can see that Phil flagged it for team meeting so we'll see what he meant to share with the team. In the meantime, feel free to reply on the above.

Comment From: sambrodeur

@snicoll Thanks for reply. I get what you answered to be honest.

I have two ideas for this :

1) Do something similar to how you create spring.security.client.registration.* but for the quartz job details and trigger. My example is a bit simple right now but it was mostly to show the first implementation I had in mind.

2) Remove completely the properties shown in my example and provide an annotation similar to this : @QuartzJob(cron="0 */10 * * * ?") That way you wouldn't need to define the class that is executed (the way I did it in my example) since the annotation on the class knows which one gets added to the scheduler.

Let me know what you think. If the idea is not implemented, I know I have a workaround. Just though it could be a nice improvement.

Comment From: snicoll

My example is a bit simple right now but it was mostly to show the first implementation I had in mind.

I understand that but we can't really start simple and then have a justifiable reason to keep it that way. If we do it, then it means that the 80%+ use cases are or can be covered. I don't think we want to do that for Quartz given how broad the options are.

an annotation similar to @QuartzJob(cron="0 */10 * * * ?")

You already have one with @Scheduled. I understand it's not the same thing but I think it'll bring confusion if we have a separate annotation. We're also back with the problem that @QuartzJob won't cover the 80%+. I also find adding the annotation at class level while the class has to implement the Job interface to be quite confusing. Quartz separates clearly JobDetails and Trigger and this would be going against that which I don't think is something we want to do.

For things like this, your own solution brings the best flexibility as you can add only the options that you need and defaults that match your organization.