AsciidocFX icon indicating copy to clipboard operation
AsciidocFX copied to clipboard

Feature Request: Drop in .jar based extensions into deployment folder

Open ainslec opened this issue 8 years ago • 6 comments

I see that extensions (Such as PlantUmlService.java) seem to be registered via "ApplicationController.java". i.e. extensions need to be registered at compile-time (as I understand it).

I wonder if it might be possible to place a jarfile in an extensions folder (such as "program files/asciidocfx/extensions" folder), and have the extension auto-register (using either Service Registry or OSGi) without having to compile the extension monolithically into AsciidocFX.

Then custom plugins could be used within that local AsciiDocFx installation.

The custom extension should implement an interface such as, let's say:

public interface AsciidocFXExtension {
   public String getActivationString();
   public void init(String[] keyValues);
   public String render(String content);
   public void end();
}

The jarfiles would be self contained and contain all their own dependencies so they can't pollute the classpath of other extensions. They would also be contained in folders each for all their supporting jars.

For example:

extensions/myextension
   myextension.jar   (contains service registry metadata)
   some_yaml_library.jar (added to classpath for this extension run without need for explicit import)

(The above interface assumes that extensions run synchronously which may not be a safe assumption)

Now, with getActivationString() returning "myextension", I can use the following text in my document:

[myextension,key1="value1",key2="value2"]
--
sometext-used-by-my-extension
--

(all without having to recompile the base app).

The interface would be packaged up in a single jar, and then anyone could write a hot deployable plugin.

The reason for this is to be able to add potentially custom bespoke plugins to an individual AsciidocFX installation without having to fork AsciidocFX or to contribute to monolith bloat.

Might this be possible in a future release?

ainslec avatar Apr 04 '17 15:04 ainslec

Hi @ainsley, thanks for the explanation. AsciidocFX should be modular and easy extendable. I want to develop this like feature in the future.

Thanks

rahmanusta avatar Apr 04 '17 17:04 rahmanusta

I would ask for it be a consideration of possibility to also have (non-JAR) regular Asciidoctor extension drop in. E.g. I was looking into bibtex and there is this project which simply adds macro's and utilizes the asciidoctor command line -r switch for enabling extensions.

I'm fairly sure many more extensions to the language have rather simple interfaces and it might be a bit of a drag needing to wrap each and every one of them in Java code.

robjens avatar Nov 10 '17 10:11 robjens

Hi, I just wanted to inquire about this feature. Is it on the roadmap?

ainslec avatar Sep 19 '18 12:09 ainslec

Hi @ainslec , I started a full-time job, and unfortunately have not much time to work on AsciidocFX. I can spend time only on bug fixes.

Because it is an open-source project, and it is not economically supported, I'm very open if developers from AsciidocFX users can help.

rahmanusta avatar Sep 19 '18 12:09 rahmanusta

If I was to add this myself, is there a Contributor License Agreement I need to sign?

Chris

ainslec avatar Sep 19 '18 17:09 ainslec

No, there is nothing to sign. You can freely contribute. https://github.com/asciidocfx/AsciidocFX/blob/master/LICENSE

rahmanusta avatar Sep 19 '18 18:09 rahmanusta