flex-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cyrill Zadra (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (FLEX-33333) Create a plugin architecture for Falcon
Date Fri, 06 Sep 2013 15:17:59 GMT

     [ https://issues.apache.org/jira/browse/FLEX-33333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Cyrill Zadra updated FLEX-33333:

    Component/s:     (was: Compiler API)
> 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
>            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

View raw message