Plugin system - Revision history

MonotoneDev: /* Plugin Directory */

2022-04-26T21:01:40Z

Plugin Directory

← Older revision		Revision as of 21:01, 26 April 2022
Line 14:		Line 14:
	Linux: ~/.openrocket/Plugins/		Linux: ~/.openrocket/Plugins/

	Mac: Root/Applications/OpenRocket/PlugIns		Mac: Root/Applications/OpenRocket/PlugIns (or) Root/Library/Application Support/OpenRocket/Plugins

	== Type of plugins ==		== Type of plugins ==

MonotoneDev: /* Plugin Directory */

2022-04-26T20:57:29Z

Plugin Directory

← Older revision		Revision as of 20:57, 26 April 2022
Line 14:		Line 14:
	Linux: ~/.openrocket/Plugins/		Linux: ~/.openrocket/Plugins/

			Mac: Root/Applications/OpenRocket/PlugIns

	== Type of plugins ==		== Type of plugins ==

2A00:23C4:77A3:5A00:AD5C:D492:8CEA:4648: added plugin folders

2020-07-14T21:18:38Z

added plugin folders

← Older revision		Revision as of 21:18, 14 July 2020
Line 10:		Line 10:
	OpenRocket plugins can be installed to the following folder:		OpenRocket plugins can be installed to the following folder:

	Windows: C:\Users\XXX\AppData\Roaming\OpenRocket		Windows: C:\Users\XXX\AppData\Roaming\OpenRocket\Plugins\

	Linux: ~/.openrocket/Plugins/		Linux: ~/.openrocket/Plugins/

2A00:23C4:77A3:5A00:AD5C:D492:8CEA:4648 at 21:18, 14 July 2020

2020-07-14T21:18:06Z

← Older revision		Revision as of 21:18, 14 July 2020
Line 11:		Line 11:

	Windows: C:\Users\XXX\AppData\Roaming\OpenRocket		Windows: C:\Users\XXX\AppData\Roaming\OpenRocket

	Linux: ~/.openrocket/Plugins/		Linux: ~/.openrocket/Plugins/

2A00:23C4:77A3:5A00:AD5C:D492:8CEA:4648 at 21:17, 14 July 2020

2020-07-14T21:17:48Z

← Older revision		Revision as of 21:17, 14 July 2020
Line 6:		Line 6:

	The plugin system has ties to dependency injection, and ideally one solution would cover both plugin discovery related items and dependency injection.		The plugin system has ties to dependency injection, and ideally one solution would cover both plugin discovery related items and dependency injection.

			== Plugin Directory ==
			OpenRocket plugins can be installed to the following folder:

			Windows: C:\Users\XXX\AppData\Roaming\OpenRocket
			Linux: ~/.openrocket/Plugins/

Sampo Niskanen: 6 revisions: Import existing wiki English pages

2013-02-15T21:17:04Z

6 revisions: Import existing wiki English pages

← Older revision	Revision as of 21:17, 15 February 2013
(No difference)

Plaa: /* Guice */

2012-09-27T10:24:41Z

Guice

← Older revision		Revision as of 10:24, 27 September 2012
Line 121:		Line 121:
	* Proper IoC framework		* Proper IoC framework
	* Works on Android		* Works on Android
			* Plugin-like systems may be supported using Multibindings (http://code.google.com/p/google-guice/wiki/Multibindings)

	Cons:		Cons:
	* ~~Does not support autowiring, all dependencies need~~ to ~~be configured by hand (?~~)		* Unfamiliar to Sampo :)
	* AFAIK does not offer a list of matching beans, i.e. may not be suitable for the plugin system


	=== Others ===		=== Others ===

Plaa at 13:11, 26 September 2012

2012-09-26T13:11:55Z

← Older revision		Revision as of 13:11, 26 September 2012
Line 25:		Line 25:

	* Configuration		* Configuration
	* Some plugins need configuration via a UI		** Some plugins need configuration via a UI
	* How to distinguish what is part of core and what is a plugin?		** How to distinguish what is part of core and what is a plugin?
	* Automatic discovery		* Automatic discovery
	* Drop a JAR to the plugin folder and it will be used.		** Drop a JAR to the plugin folder and it will be used.
	* Localisation support		* Localisation support
	* Dependency management		* Dependency management
	* Some plugins may depend on others and be able to automatically load them. This in turn requires that plugins have a consistent identifier / URI and version number.		** Some plugins may depend on others and be able to automatically load them. This in turn requires that plugins have a consistent identifier / URI and version number.
	* I don't think we ''need'' plugin dependency management in the foreseeable future, and such a system may complicate things considerably. -Sampo		** I don't think we ''need'' plugin dependency management in the foreseeable future, and such a system may complicate things considerably. -Sampo
	* Plugins implemented in other languages		* Plugins implemented in other languages
	* Should be possible to create a plugin that allows writing other plugins in scripting languages (e.g. JavaScript/Ruby)		** Should be possible to create a plugin that allows writing other plugins in scripting languages (e.g. JavaScript/Ruby)
	* Simplified access to openrocket document / software state		* Simplified access to openrocket document / software state
	* E.g. currently selected component		** E.g. currently selected component
	* Compatibility		* Compatibility
	* What happens when changes are made to the core that break the plugin?		** What happens when changes are made to the core that break the plugin?
	* Should we have some API versioning that defines which plugins are compatible?		** Should we have some API versioning that defines which plugins are compatible?


Line 104:		Line 104:
	* Proper IoC framework, built for the purpose		* Proper IoC framework, built for the purpose
	* Supports AutoWiring of dependencies		* Supports AutoWiring of dependencies
	* Should be possible to list beans matching to an interface/annotation		* Should be possible to list all beans matching to an interface/annotation
	* Modular, we need core+beans (~1MB)		* Modular, we need core+beans (~1MB)

Line 111:		Line 111:
	* Unknown does it work on Android		* Unknown does it work on Android
	* Need some boilerplate code for pluging functionality		* Need some boilerplate code for pluging functionality
			* Might need provider interfaces (or some black magic using BeanFactories etc)


			=== Guice ===
			http://code.google.com/p/google-guice/

			Pro:
			* Probably more lightweight than Spring
			* Proper IoC framework
			* Works on Android

			Cons:
			* Does not support autowiring, all dependencies need to be configured by hand (?)
			* AFAIK does not offer a list of matching beans, i.e. may not be suitable for the plugin system

Plaa at 12:59, 26 September 2012

2012-09-26T12:59:12Z

@@ Line 117: / Line 117: @@
 Other options that have been considered but seem too immature or too heavy to use:
-* JPF (http://jpf.sourceforge.net/), seems more customizable and
+* JPF (http://jpf.sourceforge.net/), seems more customizable and configurable than JSPF, but not sure do we need the extra muscle. Looks functional, but last activity was in 2007.
-configurable than JSPF, but not sure do we need the extra muscle.
+* OSGi (http://en.wikipedia.org/wiki/OSGi), even more heavy-weight service discovery mechanism, similar to (or used by) Eclipse plug-in system.
-Looks functional, but last activity was in 2007.
+* Java Module System (JSR 277), slated for inclusion to Java 7, but wasn't.  Seems pretty inactive (early draft from 2006) and seems to include language changes.
 == A Rough Interface Design (from a plugin writers point of view) ==

Plaa at 12:57, 26 September 2012

2012-09-26T12:57:44Z

@@ Line 4: / Line 4: @@
 In our case we refer to plugins as something that is installed onto the user's computer which is found by OR and provides additional functionality. The functionality might be simulation listeners, new motor types etc.
 == Type of plugins ==
@@ Line 34: / Line 37: @@
 * Simplified access to openrocket document / software state
    * E.g. currently selected component
 == Anti requirements ==
@@ Line 40: / Line 47: @@
 == Implementation ==
 === Plugin frameworks ===
@@ Line 79: / Line 166: @@
 include language changes.
-=== A Rough Design (from a plugin writers point of view) ===
+== A Rough Interface Design (from a plugin writers point of view) ==
 General operation: