[
https://issues.apache.org/jira/browse/FLEX-33333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13770004#comment-13770004
]
gurkerl commented on FLEX-33333:
--------------------------------
I think OSGi is the way to go! OSGi provides not only a very powerful plugin
infrastructure, it will force the developer to develop features in certain
boundaries. It avoids a lot of headaches e.g. cyclic dependencies, ... .
Personally I`m a fan of the blueprint specification - Apache Aries. A Plugin
Structure like OSGi provides further key benefits - plugins lifecycle, allow a
different deployment strategies to run the compiler from, eg. autonomous remote
OSGi Containers - see Apache Karaf.
Cheers Markus
> Create a plugin architecture for Falcon
> ---------------------------------------
>
> Key: FLEX-33333
> URL: https://issues.apache.org/jira/browse/FLEX-33333
> Project: Apache Flex
> Issue Type: New Feature
> Components: Falcon
> Reporter: Roland Zwaga
> Priority: Minor
> Labels: extensibility, falcon, plugin, sdk
>
> Falcon should support a clean plugin architecture which should enable
> developers to extend or modify the compiler's behavior in an easy manner.
> A set of hooks ought to be defined that make sense to plug into. Suggestions
> for these hooks are:
> - An AST postprocessing hook which enables a plugin to modify the AST
> - An emitter postprocessing hook which enables a plugin to modify the
> emitter's output
> Perhaps the emitters ought to be seen as a form of plugin as well? ABC output
> and JS output could then simply be configured as plugins. (This way its even
> possible to output SWF and JS output in one run)
> Besides defining interfaces for these hooks there ought to be a simple
> discovery mechanism for the compiler to locate plugins.
> Simplest solution would be a specific directory (or directories) that the
> compiler watches. Any jar added to such a directory will be scanned for
> implementations of the known plugin interfaces and registered with the
> compiler.
> For more verbose configuration probably an XML dialect will be needed. In
> this XML the plugin locations might be defined, but also things like enabling
> a plugin to run only in debug or release mode could be defined here. The
> location of the plugin could even be a URL, that way plugins could, for
> example, be downloaded directly from a Maven repository. (Flexmojos could
> play an interesting role here)
> This ticket is meant to start a discussion, so please feel free to throw in
> your 2 cents. Designing this plugin architecture as cleanly as possible is
> very important. So please discuss.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
