It is possible to implement the refactoring by using Eclipse library (JDT,LTK) without involving of the wizards. I would like to get benefit from refactoring feature of eclipse but I wan't to provide input for refactoring by other ways (that is not entering in the wizard) such as reading from file, etc.
If possible , Please suggest me how
You can find a sample in the JDT's SurroundWithTryCatchAction (eliding a lot of detail):
SurroundWithTryCatchRefactoring refactoring= SurroundWithTryCatchRefactoring.create(cu, selection);
Change change= refactoring.createChange(new NullProgressMonitor());
PerformChangeOperation op= new PerformChangeOperation(change);
WorkbenchRunnableAdapter adapter= new WorkbenchRunnableAdapter(op);
PlatformUI.getWorkbench().getProgressService().runInUI(
new BusyIndicatorRunnableContext(), adapter, adapter.getSchedulingRule());
The refactoring is set up entirely non-interactively through the create-helper.
Related
I'm developing a Modelica library and need to produce a document with source code listings. I'd like to be able to include the source of the Modelica models without annotations.
I could manually edit them out, but I'm looking for a more automated strategy. I'm guessing the most convenient and straightforward approach is to use some tool to save .mo files with no annotations and include those in my document (I'm using \lstinputlisting in LaTeX).
Is it possible to do this? I have access to Dymola, OpenModelica and JModelica. Dymola is obviously capable of producing such a listing, as it's able to include it in the automatically generated documentation (File > Export > HTML...). I've been looking into scripting with Dymola and OpenModelica, but haven't found a way to do this either.
JModelica seems like it could be a good option, but I don't have experience working with Python. If this is possible and someone gives me some pointers, I'm willing to look into it myself. I found a mention to a prettyprint function that might do the job, but I'm not sure where to start. I can't even find reference to that function in the latest documentation.
It would also be more convenient for me to find a way of doing it with Dymola/OpenModelica (whether through the UI or by using a script). Have I missed something?
I think you could use saveTotalModel("total.mo", MyModelName) in OpenModelica. This will strip most annotations (not ones used for code generation if I remember correctly) and pretty-print the source code including all dependencies. Then you just copy-paste the models/packages that you want to include in the listing. Or if you prefer, you can do something like the following to only include code for a particular model:
loadModel(Modelica);
loadFile("MyModel.mo");
saveTotalModel("total.mo", MyModel.A.B);
clear();
loadFile(MyModel);
str := list(MyModel.A.B);
writeFile("MyModel.A.B.listing", str);
I have a rather silly question. I am using xtext to define a simple dsl and Xpand to generate code.
Now I want to use xpand to read my dsl models and generate code. How can i do that?
I read lot of tutorials saying that I can simple do that by creating a new xtext project from the wizard. Then, among others, the following project will be created:
org.xtext.example.domainmodel.generator.
And inside, the generator looks like this:
src
model (place the dsl model)
templates (place the template for the code generator)
workflow (workflow file)
Then i simple run the workflow and generate the code from the dsl file. That s straightforwards and easy.
My problem is that when I create a new xtext project I dont get the org.xtext.example.domainmodel.generator. project. I only have the following four:
org.xtext.example.domainmodel
org.xtext.example.domainmodel.sdk
org.xtext.example.domainmodel.tests
org.xtext.example.domainmodel.ui
So how can i produce the org.xtext.example.domainmodel.generator file???
Which tutorials do you mean? (links please) And do they really talk about a generator project? Talking about the package org.xtext.example.domainmodel.generator inside the org.xtext.example.domainmodel project is the usual thing.
Probably not relevant to the original person who asked this :) but I had a similar problem and the reason was that in my grammar extended xbase.
When extending xbase building the mwe2 skips the generator stub generation and uses the xbase code generation which is generated instead (the antlr parser, serializer etc.)
I have to use EMF to create a EMF Generator Model from an existing ecore diagram, but it gives me namespace errors when trying to do so.
Here is is the screenshot of the two errors.
I think the error might be in the ecore file (XML), but I have no idea what to write, as I have only been using the GUI tool to create the ecore model...
My ecorediag file is here, and my ecore file is here.
I have bad experience with EMF, as it has never worked smoothly without any hiccups, and this is yet another problem, however, I am forced to use it.
I tried Googling the errors, but only 9 and 8 hits were returned, most of which did not help solve the problem.
What do I need to edit in the ecorediag or ecore file to be able to generate my EMF Generator Model?
For the record, I am using Eclipse 4.2.2.
change nsURI in to "http: ///ecore_file_name.ecore" and nsPrefix into "ecore_file_name" it woks great
The solution I found was to rewrite the whole project from scratch.
The approach was to carefully generate the genmodel for every change I made to the ecore file (adding/renaming/removing attributes/classes) to make sure nothing bad happened between any alterations to the model. By following this approach, you will be able to isolate the problem if something goes wrong.
However, I am still looking for another solution/answer other than rewriting everything.
In Eclipse CDT, I would like to create syntax highlighting and a error parser for a custom filetype, lets say *.xy.
Those files do not contain C-Code, so i cannot use any existing parsers.
What kind of plugins would I have to create?
For the error parser, I think I have to use Codan? (have not tried it yet)
https://www.ibm.com/developerworks/java/library/j-codan/
The CDT is the wrong start for your journey, if your language is not related to the CDT supported languages and workflows. Implement an xtext based language editor instead.
Maybe this is a simple solution for you:
colorEditor plugin
You can simply add a new language by unpacking the jar archive, then adding a xyz.xml file for your .xyz files.
Pakc together again, and copy into your Eclipse "plugins" dir.
You need to introduce a new "language" - this is the extension point: http://help.eclipse.org/helios/topic/org.eclipse.cdt.doc.isv/reference/extension-points/org_eclipse_cdt_core_language.html
Codan is not an "error parser" it is a static analysis framework. Error parser processes output of the command-line tools you use to build the application (e.g. compiler, linker) to identify errors that happened during the build and filling their attributes, e.g. source file name and line number.
Codan analyzes the source code in the editor to identify errors. E.g. it checks if the variable used in the expression was declared beforehand. Note that same check can be performed by a compile at a build time and then captured by error parser and shown in the editor/problems view - the goal of Codan is to detect problems sooner, before the build is even ran. Codan can also perform some checks that compiler doesn't.
I'm using Groovy for a calculation engine DSL and really like the support we now have in Eclipse with STS and the Groovy-Eclipse plug-in (I'm on STS 2.8.0M2 with latest milestone of Groovy-Eclipse 2.5.2).
One issue I have is I don't know how to get the Groovy editor to 'know' the automatic imports I've added to my script runner, meaning Eclipse gives me a whole bunch of false errors. If you use the Groovy class loader, you can add additional import for 'free', so you avoid needing to do imports in your script.
I've had a play with the DSLD support in Groovy-Eclipse (which can be used to add auto-completion support) but it's not obvious to me that this is something I could do with it - I don't find the DSLD documentation the simplest to follow.
The inferencing settings for Groovy in Eclipse didn't look like the right thing either.
For example:
def result = new CalculationResult()
gives me an error on the CalculationResult class as it's not imported, but the script will execute correctly in my environment because of the customized imports on the Groovy class loader. I'm using the standard import customization provided by Groovy, for example:
import org.codehaus.groovy.control.customizers.ImportCustomizer
import org.codehaus.groovy.control.CompilerConfiguration
def importCustomizer = new ImportCustomizer()
importCustomizer.addImport 'CalculationResult', 'ch.hedgesphere.core.type.CalculationResult'
def configuration = new CompilerConfiguration()
configuration.addCompilationCustomizers(importCustomizer)
...
Any pointers appreciated.
This seems to be in their bugtracker as coming in the 2.6 release of the plugin.
But the comment from Andrew Eisenberg doesn't bode well:
Unfortunately, this is not something that DSLDs can do. Since a
missing import could mean compile errors, we would need a way to
augment the compiler lookup for this. There might be a way to specify
this information inside of a DSLD, but that would mean hooking into
DSLDs in a very different way. More likely, this will have to be
specified through an Eclipse plugin (like the gradle tooling).
Another possibility is that we can ensure that certain kinds of AST
Transforms are applied during a reconcile and so the editor would just
"magically" know about these extra imports. We will have to look into
the feasibility of this, however.
Still, maybe a vote on that issue wouldn't go amiss?