I have built an Xtext based editor for our DSL which works fine, but we get an out of memory error while the workspace is building or when we force a project cleaning. Our DSL plug-in is used in conjunction with the Eclipse CDT to build microcontrollers test programs. A test program project is made of C++ files and ".xxx" files for which I have built the DSL editor. The out of memory error occurs when the test program project contains at least one large ".xxx" file (~300 Mbyte). We don't even open this large file, we simply clean the project and the memory error occurs.
This seems to be an Xtext indexer issue. Is there a way to tell the Xtext indexer to ignore ".xxx" files located in a particular folder of the project? I have read several times the Scoping chapter of the excellent "Implementing DSLs with Xtext and Xtend" from Lorenzo Bettini, but did not find any solution to this issue. Can you help me, please?
the extension points for this are org.eclipse.xtext.resource.IResourceServiceProvider.canHandle(URI) or org.eclipse.xtext.ui.resource.IResourceUIServiceProvider.canHandle(URI, IStorage)
Related
Is it possible to create Eclipse project using make?
I have a bunch of Eclipse CDT c++ projects, but I can't keep the .project and .cproject files in the source reposotory - instead, one option is to create a makefile to be able to re-create Eclipse projects by running make. Would that be possible?
CMake can generate Eclipse project files, you could use that. I haven't come across a way to do it using plain make.
That said, please keep in mind the caveats I mention in this answer about Eclipse project file formats being undocumented and without guarantees of stability.
I'm trying out Java 9 Jigsaw module system (no module experience yet) and would like to use it for capsuling the classes within my project, but it's confusing.
According to this article it should be possible to have multiple modules within ONE project. I made a new project in Eclipse Oxygen (Java 9 is supported) with the same structure as shown in the article. But Eclipse keeps telling me that I must not have more than one module-info.java in a project.
I really don't know how to tell Eclipse that it should use the "multi-module-mode". And I really would appreciate not having to create a new project for every single module.
This works:
This not:
But according to this article something like that should work:
And how about deployment of a modularized project with Eclipse? There is nothing to see about the new jmod extension. Do I still export it as a runnable JAR file like before?
Notice that my questions refer to working with the IDE (no command line, I mean with an IDE that should be possible, right?) Thank you for enlightening me.
Currently, Eclipse requires you to create a separate project for each module (e. g. because each module has its own Java Build Path).
To understand this design decision, consider that Java modules correspond to OSGi bundles / Eclipse plug-ins and it has always been to have a separate project for each bundle/plug-in. If you come from the Maven world, you would probably expect a deeper folder structure instead. But modules are self-contained and combining several modules into one project would only add an additional folder level without meaning. However, Eclipse supports nested projects and so-called working sets if you need an additional folder level.
Exporting modules as images is planned for Eclipse 2019-03 (4.11), on March 20, 2019 (see Eclipse bug 518445). Exporting modules as JARs that can be used on the modulepath (-m) already works (see my video).
I don't know if this question is still open for an answer, but you can solve this problem by simply removing all source folders on the build path. At least this works for Eclipse 2021-12 version.
As you can see this is a demo project from the Official Gradle Guide Book and it has multiple modules. Each module has its own module-info.java.
project structure in IntelliJ IDEA
If I open this project in Eclipse it will give me the 'duplicated entries on module-info.java' error.
Eclipse shows the error
But if I delete all the source folders on the build path, the error is gone and the project can be built and run without problem.
project properties: Java build path
The only problem is that you have to build the project with Gradle so that it will produce the .jar of each module and you have to include them in the libraries later.
include all the .jar in libraries
I think this is probably the same solution mentioned by howlger above.
I have a standard C project in Eclipse CDT. Naturally it uses make. I have decided to add some JSON support to my application to be able to load/save its configuration in a readable format that the user (if such desire occurs) can alter those manually and/or through an external tool. I've looked up two options so far namely Jansson and Json-C. The problem is that both are using cmake, which, if I recall correctly, can be imported in Eclipse CDT without problems (though in itself CDT can't create cmake projects).
I was thinking of adding a script for the pre-build step of my project that runs cmake (as an external command) and sets up the JSON library (static and/or dynamic) so that when the build process of my projects starts the library file will be available.
Is there a better way to combine a cmake with a make project in Eclipse CDT? I know that cmake basically generates a Makefile but I've never done such a combination before.
Even if there is a JSON C library somewhere out ther that uses make (I'm 99.9% sure there is such thing :D) I'd still like to know how to tackle this situation.
I have a legacy, in-house tool that creates an Eclipse CDT project out of all the C files that I use to run Simulink simulations. I use the eclipse project as front end to GDB (in Windows using Cygwin) to debug by simulation C code. The tool uses an unchanging .cproject file to make the projects.
I am now running my simulations on Unix so I'm trying to port the tool to create an Eclipse project in Unix. I am stuck on how to turn my Windows .cproject file into a Unix .cproject file. For example in Unix Eclipse project build is giving me errors like below:
Managed Build system manifest file error: Option cdt.managedbuild.option.gnu.cross.path.2110017774
uses a null category that is invalid in its context. The option was ignored.
I am guessing that this is being caused by the .cproject file since it is the only file in the tool that has cdt.managedbuild in it.
<option id="cdt.managedbuild.option.gnu.cross.path.2110017774"
superClass="cdt.managedbuild.option.gnu.cross.path" value="MinGWPath" valueType="string"/>
I don't even understand what this file is doing or how it was generated in the first place. I did not create the tool and I am an Eclipse novice. Are there any resources that I could use to understand how to create, modify, and interpret a .cproject file?
.cproject files aren't really designed to be generated by external tools. Their exact format is not documented, and is considered to be an implementation detail.
Extensibility and automation in the Eclipse ecosystem is intended to happen through Eclipse plugins. Eclipse plugins have access to a set of stable, documented APIs which can be used to manipulate an Eclipse workspace. For example, for creating a project you might use APIs like IWorkspaceRoot.getProject(), IProject.create(), and CoreModel.create(IProject). The implementation of these APIs will take care of details such as creating the .cproject file.
If you really want to generate the .cproject file yourself, your best bet is to refer to the CDT source code for details about its exact format, and ask any clarifying questions on the CDT mailing list. It may also be helpful to look at the source code of other cross-platform tools that create .cproject files, such as CMake which has an Eclipse project generator.
I am new in Scala and I have to learn Scala and SBT, I read the sbt tutorial but i am unable to understand the use of sbt, for what purpose its been used.After reading this tutorial
I am still confused can any one will explain it in simple words, also suggest me if there is some tutorial for simple build tool
When you write small programs that consist of only one, or just two or three source files, then it's easy enough to compile those source files by typing scalac MyProgram.scala in the command line.
But when you start working on a bigger project with dozens or maybe even hundreds of source files, then it becomes too tedious to compile all those source files manually. You will then want to use a build tool to manage compiling all those source files.
sbt is such a tool. There are other tools too, some other well-known build tools that come from the Java world are Ant and Maven.
How it works is that you create a project file that describes what your project looks like; when you use sbt, this file will be called build.sbt. That file lists all the source files your project consists of, along with other information about your project. Sbt will read the file and then it knows what to do to compile the complete project.
Besides managing your project, some build tools, including sbt, can automatically manage dependencies for you. This means that if you need to use some libraries written by others, sbt can automatically download the right versions of those libraries and include them in your project for you.