Pluggability: make simpler to inject a custom job to be scheduled

[fabioformosa]

According my opinion, the first step of growth is to improve the mechanics to customize/submit the job to be scheduled. Currently, a developer must fork the project, add his job and build a deliverable. Too tricky! The idea is to adopt a framework that supports pluggability. Quartz-Manager could be deployed once and the user should upload a jar with his job, likely developed with spring-boot. I'm testing two libraries:

• pf4j and spring-pf4j
• sbp

I've developed a PoC: https://github.com/fabioformosa/sbp-pluggable-project I'm stuck plugging a jar in the form of executable spring boot jar. I've reported some feedbacks at this issue: hank-cp/sbp#10

[fabioformosa]

I've created a project to study the feasibility of adopting sbp:

https://github.com/fabioformosa/sbp-pluggable-project

I proved the feasibility of pluggability in development mode (plugin source in the subfolder) but I failed in deployment mode, to provide a spring executable jar. The library doesn't support the spring executable jar built by spring boot.

I've opened an issue to maintainer: https://github.com/hank-cp/sbp/issues/10

[hank-cp]

So why you insist with the spring executable jar? I suppose a normal jar would also be good in this case, since the plugin doesn't need to be run standalone.

[fabioformosa]

I would give the chance to load standard jar and spring boot jar as well.

Spring boot is, by now, standard de facto in development of java project. Spring boot projects have a spring maven plugin that produces 2 jars:

• original jar: with only classes but without libs
• spring executable jar: with classes and libs, but with a specific structure of folders inside it

For developers who will develop plugins for quartz-manager, it would be natural to upload jars built with spring boot builder, because in other case I should give instruction to how-to assembly libs in a standard jar. @hank-cp Do you agree?

[hank-cp]

I agree, plugin should be restraining. In our production case, I flat all classes in jars and re-pack them into a new jar.

gradle code

        task buildPlugin(type: Jar) {
            group 'build'
            dependsOn build
            manifest.attributes(
                    "Plugin-Id": pluginProp.get("plugin.id"),
                    "Plugin-Class": pluginProp.get("plugin.class"),
                    "Plugin-Version": pluginProp.get("plugin.version"),
                    "Plugin-Provider": pluginProp.get("plugin.provider"),
                    "Plugin-Dependencies": pluginProp.get("plugin.dependencies"))
            from configurations.localLibs.asFileTree.files.collect { zipTree(it) }
            with jar
        }

from configurations.localLibs.asFileTree.files.collect { zipTree(it) } do the magic. You could run ./gradlew buildPlugin of sbp to see the result.

Not familiar with maven, not sure if it could do the same.

[kaushikvijay]

Hello Fabio, Good work ongoing! Recently I tried to look at several libraries to provide a UI for Quartz. When I was looking at your project to use in my application, it felt promising but it appeared to be an application itself and not an library.

1. Plug and play. As a user of library, I just want to add a library in application, do little wiring and it should function in most cases. I don't want to compile the full project to be able to use it in my bigger application. Just like quartz itself. (I would try to create it as plugin for quart like shutdown plugin/xml initializer plugin etc)
2. Authentication. As a starting point for a new application, the project appears good but when i want to integrate it as library in existing application, I just want to bring REST api as Authentication etc is already existing in my own application.
3. APIs, APIs for jobs and tracking. My first concern is able to see Jobs and triggers in an running application and then second concern is ability to schedule dynamically Anyways just feedback from my limited experience and my use cases. Hoping to be helpful.

[fabioformosa]

I totally agree with you @kaushikvijay. I'd like to address 2 needs:

• Who has a big project and would like to import quartz-manager to monitor scheduler and jobs
• Who has a only little job to run in a scheduled way. For example: ping an url, send a newsletter to a bunch of customers, etc.

Currently I'm evaluating the feasibility to achieve both. For the first one, I've planned to extract all controllers and services in a core module (without any authentication) to be imported in whatever big project. The concern is related to how to handle custom tables for quartz-manager, how to migrate them, using the datasource of the hosting project. For the second, I'm trying some plugin framework.

Stay tuned... and if you want to contribute, you are welcome!