Re: [recommenders-dev] [snipmatch] headless API for generating code snip

[Fabian Steeg <fsteeg@xxxxxxxxx>]

Hi Marcel!

Is it possible to create a pure headless API to build code snippets with minimal dependencies to existing libraries? I saw that your plugin depends to quite a few plugins [...] How would the dependencies for the minimal runtime look like?

Basically, the current setup already implements the separation into headless/core and UI/editor bundles. What's currently called 'org.eclipse.recommenders.snipeditor' is actually only the language bundle, while all UI/editor-specific stuff and its dependencies are in 'org.eclipse.recommenders.snipeditor.ui'.

I looked into making the generator bundles optional in 'org.eclipse.recommenders.snipeditor', but the core Xtext dependency will transitively pull them in. Also, they are all resolved from the single Xtext feature, so I don't think it would make any difference in practice, since that one feature will be installed in any case.

Or am I missing something?

Cheers,

Fabian

On 29.08.2013, at 21:35, Marcel Bruch <marcel.bruch@xxxxxxxxxxxxxx> wrote:

Stefan,

Fabian,

I just found a few issues in the current "adaptive templates" completion engine and I was wondering whether it makes sense to fix them there or to work towards a headless snippet api based on your grammar and the generated EMF model.

Therefore I need your assessment (since you know better than I do what really is required here):

Is it possible to create a pure headless API to build code snippets with minimal dependencies to existing libraries? I saw that your plugin depends to quite a few plugins [1] - not sure how many other transitive dependencies they would pull in at runtime.

I'd like to know how many of them we could get rid of to create a very lightweight runtime. I'm thinking of the following plugin structure:

• o.e.r.templates - the core runtime that can be reused by our chain and template completion engines as well as serveral API doc providers and documentation generators
• o.e.r.templates.io - the classes responsible for doing the IO, i.e., loading and saving snippets. Not sure whether this actually makes sense?
• o.e.r.templates.rcp - the RCP integration of your basic snippet editor. This component may be reused by any other project that want's to make use of your framework. Dependencies here should also be as minimal as possible
• o.e.r.snipmatch.rcp - the specific parts we need to use your editor in the context of Snipmatch, i.e., the multipage editor we talked about briefly before that collects some metadata for snippets etc.

Can your cut your code in that way? How would the dependencies for the minimal runtime look like?

Thanks,

Marcel

[1]

Require-Bundle: org.eclipse.xtext;visibility:=reexport,

 org.eclipse.xtext.xbase;visibility:=reexport,

 org.eclipse.xtext.generator,

 org.apache.commons.logging;bundle-version="1.0.4",

 org.eclipse.emf.codegen.ecore,

 org.eclipse.emf.mwe.utils,

 org.eclipse.emf.mwe2.launch,

 org.eclipse.xtext.util,

 org.eclipse.emf.ecore,

 org.eclipse.emf.common,

 org.antlr.runtime,

 org.eclipse.xtext.common.types,

 org.eclipse.xtext.xbase.lib

Import-Package: org.apache.log4j,

 org.eclipse.xtext.xbase.lib

_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/recommenders-dev