Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Future of Xtext (with Sebastian Zarnekow)

Future of Xtext (with Sebastian Zarnekow)

Sven Efftinge

May 19, 2015
Tweet

More Decks by Sven Efftinge

Other Decks in Technology

Transcript

  1. first commit May 2008 Most Innovative Eclipse Project March 2010

    Version 0.7 June, 2009 Version 1.0 June, 2010 What happened so far…
  2. Version 2.5 December 2013 Version 2.0 June, 2011 Version 2.3

    (Xbase) June, 2012 Version 2.6 May, 2014 XtextCON May, 2014 Version 2.7 Sep, 2014 Version 2.4 March 2013 Version 2.8 March, 2015 XtextCon May, 2015
  3. Version 2.8 Over 250 Bugfixes 1263 commits 2.443.791 lines added

    2.030.058 lines removed Total 5.747.523 Lines Of Code 27.539 occurrences of @Test
  4. Version 2.8 New Formatter API Improved Responsiveness Whitespace Sensitive Languages

    Grammar Language Enhancements New Xbase Compiler Options Convert To Xtend
 …
  5. I miss the "big picture" of the injection points. There

    are not enough tutorials and api documentation. Documentation to customize the XBase compiler and validation. Some more documentation of the APIs will definitely help (I wish I could spend some time on this...) Documentation of internal concepts add more docs on how xbase works beyond the inferrer. Default implementations / Xbase implementation is not well documented. Documentation Documentation. Very few interfaces have API specifications. Documentation on xbase customization Documentation could me MUCH improved
  6. Performance I think that the performance can be improved. Performance/background

    compilation. Faster Builder, indexing, cache index of stuff in binary JAR dependencies Performance/footprint of the IDE (CPU fans much louder when activating Xtext/Xtend features) Performance is still a big issue (Xtend included) (didn't test 2.8 yet, though) performance, performance, performance I would improve the performance Performance should be improved.
  7. Performance Working on it every release Incremental Compilation Storaged Resources

    Do nothing in UI Thread Cancelable builds Cancelation policy
  8. Building Our goal is to build just a non-ui module

    using Xtext. However, navigating and fighting the mish-mash of build technologies (maven, mwe2, eclipse projects & plugins, manifest files...) has proven to be a nightmare for us non-Eclipse (RCP/IDE) developers - the biggest detractor by far. project structure (eclipse vs. maven) dependency list required to use xtext-maven-plugin for code generation shouldn't require specifiying 8 different versions of things Maven support out of the box with standard paths e.g src/main/java Building is cumbersome Nothing I can really think about today, except Maven integration maybe. Easier Maven support to build a DSL that can be used during a build in other maven plugins. build process integration !!! usage without eclipse as jar
  9. Declipse Support for additional platforms would be great. I dream

    of Xtext-like frameworks for Visual Studio or for the JavaScript world. Eclipse UI dependency More web integration I'm looking forward to the new "ide" plugin that should be UI independent, this means we can turn a lot of unreliable UI tests into regular tests. Support for Netbeans, generation of Netbeans editor support. Migrating to another RCP Platform, like IntelliJ IDEA (first off all), NetBeans. IntelliJ Support - Eclipse-free mode Web support (Ace editor, Orion, etc.) Web based model editor component. support for web orion/che would be great. Support for Orion and Eclipse Che Decouple stuff from Eclipse, e.g. for standalone usage (or usage in other IDEs)