[
https://issues.apache.org/jira/browse/THRIFT-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jake Farrell resolved THRIFT-1463.
----------------------------------
Resolution: Incomplete
Fix Version/s: 0.9
Bumped to dev mailing list
> Decouple Thrift IDL from generators
> -----------------------------------
>
> Key: THRIFT-1463
> URL: https://issues.apache.org/jira/browse/THRIFT-1463
> Project: Thrift
> Issue Type: Wish
> Components: Compiler (General)
> Reporter: Diwaker Gupta
> Assignee: Jake Farrell
> Fix For: 0.9
>
>
> While Thrift's broad language support is fantastic, it does impose many
> constraints on day to day development.
> * The current design of the compiler make it hard to improve and test the
> generator/library for a particular language. The codebase is monolithic and
> hard to navigate.
> * Each language has it's own idiosyncrasies. For instance, the Java library
> required ant to build, the Ruby library has other dependencies. Running unit
> tests is slightly different for each language library. Currently, all of this
> is duck-taped together (barely) using 'make', which has its own flaws.
> * Adding support for a new language is fairly easy, but rather than making
> the code more modular, it adds to the current complexity of the codebase. For
> example, setting up Jenkins jobs to test/verify builds for a new language
> take a while to come up to parity with other languages.
> I think Google's Protocol Buffer approach is instructive here. They're trying
> to strip down the core compiler and decouple the IDL from language specific
> stubs. For a rich environment like Thrift, I think this decoupling is crucial
> to allow for a more maintainable and testable code base going forward. To
> refresh:
> * the core compiler takes in a Thrift grammar file and generates an
> intermediate representation: think of an in-memory AST
> * each supported language will be implemented via plugins, that can be loaded
> at runtime by the compiler
> * the plugins take this AST and transform it into source code
> * each plugin can be in its own repository (consuming the compiler via a git
> submodule, for instance). Plugins can freely choose their own build system,
> unit test frameworks etc
> * a meta repository can contain the compiler, and the 'blessed' (officially
> supported) languages. This meta repository can include integration tests that
> will test language interoperability
> I realize, of course, that this will be a big change. But we have to start
> somewhere.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
