Ideas for making plugin development easier

[Balazs]

Hi,

while developing my first commercial plugin for Ant Media Server, few ideas came to my mind which I'd like to share with you to see if any of these make sense for you:

* It would be very convenient and nice if you published your pom files, artifacts (including source jars) in a publicly accessible Maven repository. This would allow people to consume dependencies more easily, without the need to fetch the parent project and publish it to a local maven repository. This would make CI builds easier, even your own ones!

* Publish source jars, to make debugging easier in IDEs

* Management UI setting page: expose plugin information on web UI (including a link to the plugin documentation), provide ability to turn plugins on/off even if they are physically located on the classpath

* Allow fetching plugins from different Java packages. This could be achieved by defining plugin metadata using Java SPI, or special descriptor under META-INF.

* UI support for plugin configuration. Plugins currently need to take care of their own configuration management on their own, which is a challenge. It would be nice if they could benefit from the "settings" on the UI, by declaring their configuration parameters (name, data type, help text, etc.) and AMS could take care of editing/reloading/storing those settings and injecting the right configuration bean / property source into plugins, or simply expose an API to query the settings programmatically

* Dependency issues: isolate the classloaders used for loading plugins, so that they can use different dependencies compared to the core AMS server and other plugins. Currently shading with package relocation seems to be the only way to provide future-proof plugins, that are guaranteed not to clash with other plugins.

* Make debugging AMS easier: provide an extension point for the OS service descriptor so that custom JVM settings can be injected, that can be used for adding the debugging related JVM args

* Make application development easier by configuring Tomcat to redeploy the webapplications if the war file is changed (in my experience I had to stop AMS, delete the exploded war directory, upload the new war file, start AMS to see my changes - I might have missed something to do this quicker)

This is my quick brain dump, these need much more thought but @Burak or @mekya you might find some of these worth considering

[Burak]

Thank you @Balazs for sharing your valuable ideas as a plugin developer.
I think there are short, middle and long term items. We can discuss here to prioritize and order what you and other plugin/application needs.

There are some solutions for jar deployment to public repo and debugging, but they aren't documented yet. Maybe we should start with creating some documentation for developers.

I can also add to items here:
- Improve interfaces between AMS and plugins
- Create a Utility package (for ffmpeg functions) to make plugin development easier

According to items we may have such titles:
* Plugin/Application Development
* Plugin/Application Deployment
* Plugin/Application Runtime

Lets everyone writes their ideas and discuss all together.

[varkeli]

Me and my team started to use formal document, outlining your requirements and expectations https://jaydevs.com/how-to-write-an-rfp-for-software-development/ for plugins

[mekya]

I just had a chance to review my emails and late is better than never 😉

Thank you for ideas. Making things easier makes too much sense.
I've some questions to ask @Balazs about your ideas. Shall we have a meeting?
 

Regards
Oguz

[Balazs]

Hi @mekya, apologies, I missed this reply for some reason, happy to have a meeting with you!