Xtext: Customize inferred genmodel - eclipse

I'm trying to upgrade an Xtext project to version 2.9 but I cannot figure out how to post process a meta model (inferred from Xtext grammar) when using v. 2.9. In previous versions it was possible to just create a ModelnamePostProcessor.ext file with the necessary custom code and ensure that the MWE2 file contained the necessary setup like so:
fragment = ecore.EMFGeneratorFragment auto-inject {
emfRuntimeVersion = "2.10"
}
However, when using Xtext 2.9 it appears that the extension doesn't get picked up at all. I didn't make any changes to the .ext file, but the MWE2 workflow looks a bit different:
//...
language = StandardLanguage {
name = "org.xtext.example.mydsl.MyDsl"
fileExtensions = "mydsl"
fragment = ecore.EMFGeneratorFragment2 auto-inject {
emfRuntimeVersion = "2.9"
}
serializer = {
generateStub = false
}
}
Does anyone know what's wrong here or is aware of some documentation/example on how to post-process meta models with Xtext 2.9?

this is no longer possible. you may have a look at, comment and follow the workaround in https://bugs.eclipse.org/bugs/show_bug.cgi?id=483209

Related

TypeLite generate external modules?

I am trying to generate external modules rather than a type definition file. I believe I need to do the following:
Change the extension of the file to .ts instead of .d.ts.
Generate one file per module.
Add the key word "Export" in front of each interface and enum.
I was easily able to change the extension of the file by changing the "output extension" setting in the tt file.
I cannot figure out how to split the modules into separate files.
I cannot figure out how to add the Export key word to each interface.
TypeLITE doesn't support generating multiple files. This feature has been requested by several users, but I am not aware of a simple way to generate multiple files from the single tt file.
export keyword can't be added without changing source code of the library (TsGenerator.cs). This is very specific requirement, so I probably won't add it to the library.
TypeLite is a good project but lacking in Documentation and examples, it's open source so anyone can contribute and make it better.
As for creating a file per class i solved it using the code below.
private static void GenerateTypeScriptContracts(string assemblyFile, string outputPath)
{
// Clean TS Folder
System.IO.DirectoryInfo di = new DirectoryInfo(outputPath);
foreach (FileInfo file in di.GetFiles())
{
file.Delete();
}
// --
var assembly = Assembly.LoadFrom(assemblyFile);
// If you want a subset of classes from this assembly, filter them here
var models = assembly.GetTypes();
foreach (var model in models)
{
var generator = new TypeScriptFluent()
.WithConvertor<Guid>(c => "string")
.WithMemberFormatter((identifier) => Char.ToLower(identifier.Name[0]) + identifier.Name.Substring(1));
generator.ModelBuilder.Add(model);
// Generate TS interface definitions
var tsClassDefinitions = generator.Generate(TsGeneratorOutput.Properties | TsGeneratorOutput.Fields);
File.WriteAllText(Path.Combine(outputPath, "I" + model.FullName.Replace("ProjectName.DtoModels.", "") + ".ts"), tsClassDefinitions);
}
}

Code First TVF in 6.1.0-alpha1-30113

EF People,
My understanding is that the newly made public APIs for metadata will allow us to add enough metadata in to the model so that TVF can be called and be composable.
If anyone can point me in the right direction I would greatly appreciate it. Without Composable TVF I have to jump through some major work a rounds.
From looking at the unit test it looks like something a long this line of thought:
var functionImport = EdmFunction.Create()
"Foo", "Bar", DataSpace.CSpace,
new EdmFunctionPayload
{
IsComposable = true,
IsFunctionImport = true,
ReturnParameters = new[]
{
FunctionParameter.Create("functionname", EdmType.GetBuiltInType()
EdmConstants.ReturnType,
TypeUsage.Create(collectionTypeMock.Object),
ParameterMode.ReturnValue),
}
});
...
entityContainer.AddFunctionImport(functionImport);
Thanks,
Brian F
Yes, it is now possible in EF6.1. I actually created a custom model convention which allows using store functions in CodeFirst using the newly opened mapping API. The convention is available on NuGet http://www.nuget.org/packages/EntityFramework.CodeFirstStoreFunctions. Here is the link to the blogpost containing all the details: http://blog.3d-logic.com/2014/04/09/support-for-store-functions-tvfs-and-stored-procs-in-entity-framework-6-1/. The project is open source and you can get sources here: https://codefirstfunctions.codeplex.com/

eclipse jdt automatic method stub generation

i am creating java source files using eclipse JDT & AST. There are cases that generated source files are implementing or extending something.
is it possible to add method stubs automatically before actually creating them? like invoking this "Add unimplemented methods" quick fix via JDT.
i know i can add them myself via those API's, but i want to tweak.
i found solution after a couple of hours; code is roughly like this. there are also many good code manipulation classes in this package "org.eclipse.jdt.internal.corext.codemanipulation.*"
ICompilationUnit createCompilationUnit = getItSomeHow();
RefactoringASTParser parser1 = new RefactoringASTParser(AST.JLS3);
CompilationUnit unit = parser1.parse(createCompilationUnit, true);
AbstractTypeDeclaration declaration = (AbstractTypeDeclaration) ASTNodes.getParent(
NodeFinder.perform(unit, createCompilationUnit.getTypes()[0].getNameRange()),
AbstractTypeDeclaration.class);
ITypeBinding binding = declaration.resolveBinding();
IMethodBinding[] overridableMethods = StubUtility2.getOverridableMethods(unit.getAST(), binding, false);
AddUnimplementedMethodsOperation op = new AddUnimplementedMethodsOperation(unit, binding,
null/* overridableMethods */, -1, true, true, true);

getting OSGI Bundle from Eclipse IConfigurationElement

I am looking for extensions that implement a specific extension point, and am using the following acceptable method to do this:
IExtensionRegistry extensionRegistry = Platform.getExtensionRegistry();
if (extensionRegistry == null) {
return TEMPLATES;
}
IConfigurationElement[] config = extensionRegistry.getConfigurationElementsFor("com.ibm.im.launchpoint.templates.template");
I then would like to get the version of the defining bundle. I would use the following API, but the API for PluginVersionIdentifier is deprecated:
for (IConfigurationElement e : config) {
BlueprintTemplate template = new BlueprintTemplate();
IExtension declaringExtension = e.getDeclaringExtension();
PluginVersionIdentifier versionIdentifier = declaringExtension.getDeclaringPluginDescriptor().getVersionIdentifier();
I could not find an alternative in the new API - i.e. from a IConfigurationElement, how do I get the version id descriptor of the bundle. Obviously, from the Bundle I can get the version using the Bundle.getHeaders(), getting the Bundle-Version value - but how do I get the Bundle in the first place??? Platform.getBundle(bundleId) is not enough since I might have multiple versions of same bundle installed, and I need to know who I am. At the moment I have a chicken & egg situation, and the only solution I have is the above deprecated API.
All this information is based on Eclipse 3.6:
Your IContributor will be an instance of RegistryContributor if you are in the osgi environment which of course you are or you wouldn't be having this issue.
RegistryContributor gives you two methods: getID() and getActualID(). getID() may return the host bundle if this was loaded from a fragment. getActualID() always loads the id of the fragment/bundle the contributor represents. You can use this id in your BundleContext.getBundle(long id) method. Here is a snippet:
Bundle bundle;
if (contributor instanceof RegistryContributor) {
long id = Long.parseLong(((RegistryContributor) contributor).getActualId());
Bundle thisBundle = FrameworkUtil.getBundle(getClass());
bundle = thisBundle.getBundleContext().getBundle(id);
} else {
bundle = Platform.getBundle(contributor.getName());
}
I use a fall through method that will degrade gracefully to a non-version aware solution if IContributor gets a new default implementation in the future. The bundle id is unique to an instance of OSGi so it will load the correct version of the bundle.
I suggest browsing a bit the Javadoc deprecation descriptions, the replacement is documented. I found the following code, but did not test it.
String contributor = e.getDeclaringExtension().getContributor().getName();
Bundle bundle = Platform.getBundle(contributor);
Version versionInfo = bundle.getVersion();
Out of curiosity: why do you need to get the version of the extending plug-in? As far as I know, the goal of the extension point mechanism is to detach specific information about the extender, and only the information described in the extension (plugin.xml) or the referenced code is needed.

Eclipse RCP: How to access internal classes of plugins?

I want to use the default XML editor (org.eclipse.wst.xml.ui) of Eclipse in an RCP application. I need to read the DOM of the xml file currently open. The plugin doesn't offer any extension point, so I'm trying to access the internal classes. I am aware that the I should not access the internal classes, but I don't have another option.
My approach is to create a fragment and an extension point to be able to read data from the plugin. I'm trying not to recompile the plugin, that's why I thought that a fragment was necessary. I just want to load it and extract the data at runtime.
So, my question is: is there another way to access the classes of a plugin? if yes, how?
Any tutorial, doc page or useful link for any of the methods is welcome.
Since nobody answered my question and I found the answer after long searches, I will post the answer for others to use if they bump into this problem.
To access a plugin at runtime you must create and extension point and an extension attached to it into the plugin that you are trying to access.
Adding classes to a plugin using a fragment is not recommended if you want to access those classes from outside of the plugin.
So, the best solution for this is to get the plugin source from the CVS Repository and make the modifications directly into the source of the plugin. Add extension points, extensions and the code for functionality.
Tutorials:
Getting the plugin from the CVS Repository:
http://www.eclipse.org/webtools/community/tutorials/DevelopingWTP/DevelopingWTP.html
Creating extensions and extension points and accessing them:
http://www.vogella.de/articles/EclipseExtensionPoint/article.html
http://www.eclipsezone.com/eclipse/forums/t97608.rhtml
I ended up extending XMLMultiPageEditorPart like this:
public class MultiPageEditor extends XMLMultiPageEditorPart implements
IResourceChangeListener {
#Override
public void resourceChanged(IResourceChangeEvent event) {
// TODO Auto-generated method stub
setActivePage(3);
}
public Document getDOM() {
int activePageIndex = getActivePage();
setActivePage(1);
StructuredTextEditor fTextEditor = (StructuredTextEditor) getSelectedPage();
IDocument document = fTextEditor.getDocumentProvider().getDocument(
fTextEditor.getEditorInput());
IStructuredModel model = StructuredModelManager.getModelManager()
.getExistingModelForRead(document);
Document modelDocument = null;
try {
if (model instanceof IDOMModel) {
// cast the structured model to a DOM Model
modelDocument = (Document) (((IDOMModel) model).getDocument());
}
} finally {
if (model != null) {
model.releaseFromRead();
}
}
setActivePage(activePageIndex);
return modelDocument;
}
}
This is not a clean implementation, but it gets the job done.