#10 plugin directory hierarchy


It is foreseeable that there are going to be more plugins in the future.

The plugins directory could become more intuitive if it became directly clear if a plugin is specific to the editor, the server (CDS) or the client (UA).
So it might be a good idea to think about using sub directories. For the distribution, as well as the source code:

At the moment, there don't seem to be any empty "boilerplate" (i.e. example) plugins available, so it is only natural for developers to look into existing plugins, to see how these are implemented. So having distinct sub directories for each type of plugin would make the directory more intuitive and it would be easier for developers to locate relevant plugins.


  • Hervé Girod

    Hervé Girod - 2010-11-12

    I fleshed out a little the Plugin article in the wiki. I also pointed to the MDIFramework tutorial for creating Plugins (not specific to the j661 project). That should help a little.

  • Hervé Girod

    Hervé Girod - 2010-11-19

    For the moment, plugins are looked in only one directory, because there may be libraries in sub-directories. What I could do would be to add more than one sub-directory to look for plugins, but it complexifies the architecture of the project. Did the Plugin Demo source example helped you?

  • Nobody/Anonymous

    I understand that this increases complexity.
    Maybe it would be simpler to introduce a fixed naming convention instead?


    Or maybe even omit the jar suffix altogether?


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks