I'm using a custom DSL with Xtext grammar.
In my workspace there are several projects, one of them is the development relevant project, another one is for testing purposes.
In the testing project there are a lot (> 5000) of files of my DSL, required for JUnit tests.
When the Xtext nature is added to this project, rebuilding it takes a long time, so I removed it. It's not important to me in the project anyways.
But now everytime I open one of the files, Xtext asks me to add the nature to this project.
Can I disable this dialog, for a specific project or in general?
Thanks for answers!
I believe, the NatureAddingEditorCallback class is responsible for that feature.
To replace this functionality for your language, I would try the following:
Open the «LanguageName»UiModule class from your UI project (be careful, it is in the src folder; an abstract version is in the src-gen folder), and add the following lines (this piece of code came from the XtextUIModule class):
public Class<? extends IXtextEditorCallback> bindIXtextEditorCallback() {
return org.eclipse.xtext.builder.nature.NatureAddingEditorCallback.class;
}
Then replace the returned class with your own.
Related
I would like to know if there is a way to organize multiple DSLs inside a single Eclipse project. More specifically, I would like to organize all five Xtext projects of a DSL in some top-level "project folder".
The background is that we manage complexity and enable reuse by making smaller reusable DSLs, e.g. one reusable for expressions and other one for more domain-specific or application-specific aspects. However, each Xtext DSL results in 5 projects, causing a lot of clutter in the Package Explorer when multiple DSLs are involved. A strongly related question has been asked before:
Xtext: define 2 DSL's in one project
The answer there is that multiple DSLs are not needed inside the project for that specific use-case. My use-case is different because I want to be able to easily view the different DSLs and potentially co-develop them.
We are using Xtext in an environment managed by Gradle. We are using the Gradle Eclipse plugin, which creates a lot of Eclipse project files everywhere. As a result, when choosing to "Open Project from File System" in Eclipse, I not only get the option to import the five projects related to the DSL, but also the option of opening the parent folder as a project. This means I can have each DSL (all its five projects) organized neatly in a "project folder". This is exactly what I want! ...
BUT ...
it does not actually work. The figure below shows my package explorer with the five projects of my ExperimentDSL included in the bottom. This DSL works. On top, it shows the folder structure I get when including the project file generated by Gradle, resulting in a "project folder" that can potentially contain multiple DSLs.
As you can see, GenerateExperimentDSL is flagged red and refuses to run. It seems Eclipse somehow treats it as a Java project, but I do not know how to change this or and if this would help solve my problem. Secondly, I would not know how to set up such a project by hand, since the project file in this failing case was generated by Gradle.
Long story short, does anyone know how to get this kind of folder structure to work so that I can keep all my DSLs in the workspace without clutter?
What you try to do is currently not possible. Have a look at the concept of WorkingSets in Eclipse that let you achieve something similar
I found the source code for the Plugin Manifest Editor, from Eclipse, and noticed that it uses another class as model. The MultiSourceEditor.
In my editor I´m using MultiPageEditorPart. And I need to open 2 source files here with it.
Basically, what are the differences between them? Maybe I should switch to this one?
Thanks a lot.
org.eclipse.pde.internal.ui.editor.MultiSourceEditor is an internal editor used by the Plugin Development Environment. It extends FormEditor which itself is based on MultiPageEditorPart. The editor is just a specialized multi-page editor for PDE.
You must not use any internal classes, they are subject to change without notice - Eclipse API Rules of Engagement. You can, of course, look at the source code to see what it does.
There are a lot of similar questions, but none for this specifically. I have a Netbeans project with a bunch of packages. Only one has Main. I'd like to be able to create a .jar from just one of the packages (and all the classes it contains, of course), which doesn't have main.
Is this feasible without having to put that package in another project or without having to screw around with build.xml? If the latter, any easy way or good rtfm links?
The point is i'm developing part of an application for college, each group member is developing a module of sorts. If each could provide their .jar the main project can just include jars and use them. I'm guessing all the mains in the jars wouldn't really hurt? But still...
You can use the project properties to customize your project's jar file content. This screenshot shows what it looks like for a Java Class Library project.
I am using a kind of framework where every time I make a new Java project. I have to arrange the files in the appropriate packages and reference the appropriate external JAR libraries. How do I make a new project template like in the New Project dialog under a new folder?
I've just done a bit of research on this for our own nefarious purposes, and found the answer.
You need to create an Eclipse plugin that uses the org.eclipse.ui.newWizards package. You can define your own category or use an existing one once you find the category ID. To create a new project wizard rather than a new resource wizard, you need to set the "project=true".
Also, your plugin must contain a class that implement org.eclipse.ui.INewWizard. Clicking on the class link from the plugin.xml editor will do the trick.
That class must do all the work in the performFinish override, and must return true to indicate that it actually did its thing and the wizard can close. This is where you create files, directories, set natures, and so forth.
You need to write an Eclipse plugin for that, and concentrate on New Project Wizard.
Writing Eclipse plugins is covered in Stack Overflow question How to write a plugin for Eclipse?.
Background
I'm a developer of the Vrapper project.
Vrapper contains of 2 major parts
Vim-emulation library (vrapper.core)
Eclipse part that makes a good use of it
We want vrapper.core to be Eclipse-unaware, so it's reusable
outside of the Eclipse. Currently, we can "vrap" all sorts of Eclipse
text editors and our little mock text editor that we use for unit testing.
vrapper.core implements all sorts of Vim commands, modes, etc.
Those all communicate with Platform - an interface that abstracts out
underlying stuff (text editor, clipboards, settings system, etc.).
When mode is created for an editor it asks platform if there are extra
commands that are approperiate for underlying editor, currently edited file type, etc.
EclipsePlatform provides those commands using Eclipse extension points mechanism.
So, let's consider the following projects (there are more):
vrapper.core - Eclipse-independent code for Vrapper
vrapper.eclipse - Eclipse plug-in that depends on vrapper.core
surround.core - Eclipse-independent code that emulates surround.vim (Vim plug-in)
surround.eclipse - Eclipse fragment for vrapper.eclipse
that makes it provide commands form surround.core.
There are two ways we can deal with those:
One plug-in to rule them all
This is how it should look like from Eclipse's perspective.
There is one plug-in that contains code from vrapper.eclipse and vrapper.core,
and one fragment that contains code from surround.core and surround.eclipse.
Many plug-ins
There are 3 plug-ins
two OSGified libraries vrapper.core, surround.core
vrapper.eclipse
surround.eclipse fragment depends on vrapper.core in this case
Problems
Many plug-ins solution have some issues with lazy class loading that I don't understand.
It's beacause when instances of modes from vrapper.core are created they need
classes from surround.core to be created (via vrapper.eclipse -> surround.eclipse).
This works if you run stuff from Eclipse and select all plug-ins from run configuration,
but if one deploys features & plugins and run eclipse normally an exception is thrown
because classes from surround.core cannot be found.
It's something in the spirit of surround.core asking for extra commands from
dependent plug-ins creates implicit circular dependencies.
What I mean by implicit dependencies is that no core class depends on eclipse-specific classes in compile time.
Modes (like vim normal mode) are core classes. They contain commands. There are some commands specific for particular Eclipse editors (like run this JDT-specific refactoring). Those commands implement core interfaces, but their code (obviously) lives in eclipse-specific projects. When mode is created it asks underlying platform for some extra commands - those extra commands are implemented in eclipse plug-ins. This is when lazy class loading in eclipse make everything blow up in runtime - classes for extra commands are referenced by extension points, but they are not yet loaded. Boom, exception.
I tried to work this around by using "one plug-in to rule them all" approach.
Having just one plug-in seems to be much better solution to me, but I couldn't make it work cleanly.
Only thing that succeeded for me was quite an ugly hack.
All .core projects had an Ant task that created .jar file with their classes
and dropped it into corresponding *.eclipse project
*.eclipse projects included that jars and had them enlisted in MANIFEST files.
The problem with this ugly hack approach (besides of it being ugly hack) is
that development becomes quite painful. Eclipse code navigation, code coverage
and few other things in Eclipse stops working.
Summary
We have eclipse independent library + eclipse specific stuff architecture,
but we really need all of this to live in one plug-in (because there are some dependencies in both directions).
How do I make code from few projects live into one plug-in/fragment?
It turned out that adding Eclipse-BuddyPolicy: dependent to MANIFEST.MF files, reexporting some dependencies and turning one fragment into plugin (so there is plug-in dependency for BuddyPolicy to track) was the right solution.
Problem solved :-)
From reading this it sounds as if the actual problem is the fact that there are dependencies in both directions. Can't you refactor your projects to make only the Eclipse-spcific proejcts depend on the core projects, and not the other way around?