I have DSL written in Xtext, where is use Xbase to implement expressions. To generate code, I use the JVM model inferring mechanisms. But since the project is build by Maven, I do not use the Xtext builder to build my project in Eclipse, but rely on a Maven plugin I wrote to compile my DSL files.
The output of the Maven plugin is then added to the Build-Path of my Eclipse project so that I can use it in other Eclipse projects.
Problems occur if once I am editing a DSL file for which the Maven plugin already generated Java files, since the Xtext inferring now has two versions of the inferred type available. One version that was just inferred by itself and one that was generated by the Maven plugin and is available on the Build-Path.
The results are phantom-errors that do only appear in the DSL editor.
One fix that comes to mind is to instruct the Xbase scoping somehow to ignore types that resist in derived resources, as those generated by the Maven plugin. How can I achieve that?
With kind regards,
Jan
PS: The project setup is kind of unchangeable. So relying on the Xtext builder is not an option.
Related
we have a Java 11 based project with maven and within our source code we do have a package with the classes generated by xjc. As soon as we modify the XSD file, we run xjc and copy the classes into our project in order to access the new fields. This is working fine, but as the project grows, we get more and more XSD files and the process of using xjc is not very intuitive. Also xjc is not part of the java 11 Adopt JDK anymore, so we have to use the old java 8 oracle jdk in order to use xjc.
The other option we do have is to use a maven plugin. But I am wondering, if this is working in our project setup. Because the plugin is executed during install phase, the classes will be generated only during this (or whatever phase it is set up). So the classes are only available after running through this phase.
That means if I change an XSD, I copy the new XSD into my project, run mvn install, then update my sources in IntelliJ and then I can access the new fields?
Or is the usual procedure to manage the XSDs in a separate Maven project and configure this project as a dependency in your own main project? As soon as an XSD changes, would I then have a new version of my dependency and would I have to adjust it in the pom.xml?
I am wondering which way makes sense here.
There are a couple of misconceptions in your question, I'd like to straighten them up:
you don't need Java 8 to use XJC, as this tool is available on Maven in both the com.sun.xml.bind and org.glassfish.jaxb groups (the latter one has its dependencies split into many jars). If you want to use JAXB on Java 11 you must include either jaxb-impl or jaxb-runtime with your software.
the jaxb2-maven-plugin does not run at the install phase, but the generate-sources phase, which precedes the compile phase (cf. Lifecycles Reference).
Whether you decide to run XJC externally or through Maven mostly depends on your development style.
I would split the generated code into another project only if the size of the generated code becomes considerable: e.g. whenever the amount of generated code (which will never be modified manually) started to slow down Eclipse's startup, we migrated it into another project.
I have a simple GWT project; I've read here that:
NOTICE There is a new plugin (archetypes and eclipse integration), a
fresh start that correctly support multi-module projects, it is not
version-bounded with GWT, support multiples GWT versions and other
fixes, improvements and best practices. This plugin is now considered
the legacy GWT maven plugin (aka mojo GWT maven plugin) and the new
one is considered the new generation GWT maven plugin (aka tbroyer GWT
maven plugin). The legacy maven plugin is still supported but it is
strongly encouraged to use the new one for new projects.
The plugin referenced is:
<groupId>net.ltgt.gwt.maven</groupId>
<artifactId>gwt-maven-plugin</artifactId>
I'm trying to update my project to use the new plugin. I have the following problems:
No module auto-discovery; with the old Maven plugin, it wasn't mandatory to specify a moduleName; one would get auto-discovered for you (and it was working fine for me). Do you know if there is anything equivalent with the new plugin?
If I place my gwt.xml file under src/main/resources instead of src/main/java (which is Maven standard), the the file is not found, and I get a "Module has no entry points defined" error. Is this expected behavior, any reason for this?
So I'm either missing some configuration that should allow me to do what I want, or the plugin is pretty young, and still has some missing things. But if the problem is with the plugin itself, then why does the old plugin page say "The legacy maven plugin is still supported but it is strongly encouraged to use the new one for new projects. " ? It looks like these guys hurried a bit.
The plugin is several years old already and production-ready despite it's RC versioning (disclaimer: plugin author here; versioning was like that to not commit to a forward-compatible configuration, things have been stable for a few versions already)
You're right that you have to explicitly configure the module name (and short name, for staleness checks). The alternative is to put your module at src/main/module.gwt.xml and it'll be renamed (and have rename-to="" appended) to the appropriate name and path.
Did you follow https://tbroyer.github.io/gwt-maven-plugin/migrating.html and set <skipModule>true</skipModule>? Otherwise a dummy module is generated (from src/main/module.gwt.xml actually, which might be absent) and likely overwrites yours. This is actually part of the behaviors that could still change until final release.
I'm developing an Eclipse plugin that scans and modifies the AST of the currently open Java project.
I want to create a Java annotation that will appear as a known annotation in projects that use the plugin. The annotation's RetentionPolicy will be SOURCE (so it is discarded by the compiler), yet the plugin will be able to identify (using the AST) methods marked with this annotation and handle them accordingly.
For example:
#SkipAnalysis
public void foo() {...}
This annotation will be analyzed by the plugin while traversing the AST, yet it holds no value for the compiler.
How can my plugin contribute annotations to an open project in the workspace?
After some research, it turns out that this is impossible since annotations (and other classes or interfaces) can only be contributed via the build path. Eclipse plugins can change the build path, but cannot contribute their own source code to any project.
One of the possibilities is to create a library project containing the annotation, and then use the plugin's ability to modify the build path to add that library to the build path. However, this is cumbersome and adds unneeded dependencies to the project, and if the library is not copied to every other developer working on the project, may lead to compilation errors. An exception to that is if the project uses a build automation system (like Maven or Gradle), and the library is stored in a public repository (like Maven Central), assuring that each user that imports the project on every IDE will download that library. Again - possible, but cumbersome.
I have a large project with many large directory structure. They produce around 90 JARs. The IntelliJ project structure is not the same (or similar) to the one seen by Ant scripts. This creates a lot of problems while editing the code. Main side effect is incorrect dependencies get added. Essentially I am looking to create a one-jar one-module mapping
Is it possible to create Intellij modules programmatically? I can re-use existing set of libraries, created in IntelliJ
Please consider using Maven or Gradle instead, IDEA supports both. Maven support is more mature, Gradle support will improve in the future updates.
Your Maven projects will work with all the major IDEs and command line, not just IntelliJ IDEA.
#CrazyCoder is right using maven would be a better solution, but that conversation may just be a little bit too much to swallow.
The .iml files are just xml and while it isn't documented it is pretty understandable. It shouldn't be the trickest thing to create a template and then use either ant property replacement or a custom task to generate these files for each module.
For reference you may want to look at the source for the maven-idea-plug it generates .iml files for a maven project and may provide you with a hint on how todo this with ant. Note that #CrazyCoder points out the comments that this should only be a reference...don't use this for maven support in Idea.
I downloaded Java source code of some project that works with Maven. After checking out
the code to Eclipse, and then building it from the command line, I followed the instructions
and imported it from Eclipse as: File > Import > Maven Projects. Now I have the core source code and many additional sub projects that seem to have the same thing like the core, just separated.
Could anyone please explain me what are these sub projects? why I need them? and on which code I need to work now if I want to make changes, the core or the new imported Maven ones?
I don't know nothing about Maven besides the fact that it's a tool for building code and managing releases.
Thanks!
In Maven land, these are called modules. There a nice way to further divide a project into very distinct pieces.
People handle Maven differently. I've seen projects where there was the actual project module, then 10 or so implementation modules. Most people use them for the above mentioned separation.
Most likely, your going to need all of the modules in order to work correctly.
To modify the project, your going to need Maven. I don't know if Eclipse has an embedded maven, but at least NetBeans does. With this you can modify anything that you want, then build it with Maven, which should be just a simple click.
In addition to what #Quackstar said:
Eclipse has embedded Maven support provided by the m2eclipse plugin. When you import a Maven project consisting of multiple modules, the default behavior is to map each Maven module as a separate Eclipse project. This allows the Eclipse build paths to be constructed in a way that matches the declared Maven module dependencies.
There is also a way to map a multi-module Maven project into a single Eclipse project that entails enabling m2eclipse's "Nested Module" support. This results in an Eclipse project with a build path that is an amalgam of all of the Maven module dependencies ... and not exactly correct. This approach is not recommended by the m2eclipse developers, and I've heard they are intending to remove the nested module feature entirely in a future release.