Skip to content
This repository has been archived by the owner on Aug 18, 2020. It is now read-only.

Rework plugin structure #41

Closed
sebinside opened this issue Jun 17, 2019 · 3 comments
Closed

Rework plugin structure #41

sebinside opened this issue Jun 17, 2019 · 3 comments
Labels
api Requires api changes enhancement New feature or request major Needs a major platform / framework / build environment rework
Milestone

Comments

@sebinside
Copy link
Member

Since the beginning of version 2 of chat overflow, plugins are identified by a pluggable holding all metadata and a plugin class, holding the execution information and requirements.

This should be reworked. Pluggable should not be needed and replaced by a metadata file in the plugin jars resources. The class loader and framework could has to be updated.

@sebinside sebinside added enhancement New feature or request major Needs a major platform / framework / build environment rework labels Jun 17, 2019
@sebinside sebinside added this to the pre-alpha 3 milestone Jun 17, 2019
@J0B10 J0B10 added the api Requires api changes label Jun 18, 2019
@hlxid
Copy link
Member

hlxid commented Jul 13, 2019

I would like to start working on this, but still have some questions:

  1. What file format should be used? Propably xml?
  2. Should multiple plugins in one jar be supported? The current code just complains, but allows it:
    pluggableObjects.length match {
    case 0 => logger warn "No pluggable classes found."
    case 1 =>
    case _ => logger warn "More than one pluggable class found."
    }
  3. Should pluggable be directly removed with pre-alpha 3 or be deprecated and slowly removed?

@sebinside
Copy link
Member Author

Some ideas / notes on this:

  • keep all pluggable meta data in a required xml file
  • rework the PluginFramework to load this xml file (e.g. called plugin.xml) before loading the Plugin file
  • only allow one xml and one plugin class per jar
  • rework the create task (see issue Enhance plugin create task #20) to automatically create the proposed structure with the given choice for java or scala, already containing a require for e.g. the sample connector to show the usage
  • rework the fetch task, to only add a plugin to the plugins.sbt if the plugin xml file exists. Its currently a pain in the ass to delete plugins because of this
  • think about other usefull (optional) fields in the xml file, e.g. a support website / source github repo or license. Maybe npm does have other usefull examples
  • deprecate all other approaches. this is main reason we still call it pre-alpha

I hope this answers all your questions. Another spontanious idea: the plugin version could be also embeeded into the xml. Minimal sbt file changes, minimal framework reloads...

@sebinside
Copy link
Member Author

Just an idea...

<plugin>
  <name>sampel</name>
  <author>sebinside</author>
  <description>Just a test</description>
  <api>
    <major>3</major>
    <minor>0</minor>
  </api>
  <version>0.4.2</version>
  <website>codeoverflow.org</website>
  <license>MIT</license>
</plugin>

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api Requires api changes enhancement New feature or request major Needs a major platform / framework / build environment rework
Projects
None yet
Development

No branches or pull requests

3 participants