I am using MapStruct to generate the mapping between the JAXB classes and my domain classes.
I am using gradle plugin as described in MapStruct official site. During the compilation process, the classes are generated in "build/generated/sources/apt/main".
How can i change this location? I am not able to find any guide for gradle though there is a compiler flag to change it through ant script, but unfortunately it is not working for gradle
Any help is appreciated.
This is not linked to MapStruct, but to the way the gradle apt plugin works and how it tells the Java compiler to place the generated sources.
To configure the generated sources of the plugin according to the configuration documentation. One needs to extend the aptOptions of the compile. The property controlling the destination of the generated is generatedSourcesDestinationDir
Related
(Gradle version 7.3.3)
I'm following the documentation
regarding the gradle precompiled scripts plugins.
Plugin to use
The groovy-gradle-plugin is used in this case.
I tried with the java-gradle-pluginbut it doesn't seem to generate the plugin classes.
Is this to be expected?
Plugins id's
Following the documentation:
src/main/groovy/my.java-library-convention.gradle would result in a
plugin ID of my.java-library-convention.
I want to prefix my scripts with: com.mycompany.myproject.conventions-java-library
In this case, the generated plugin classes are named with this full name in the default package.
Is this to be expected?
I expected to find a class named JavaLibraryPlugingenerated in the com.mycompany.myproject.conventionspackage
The groovy-gradle-plugin is used in this case. I tried with the java-gradle-plugin but it doesn't seem to generate the plugin classes. Is this to be expected?
Not fully sure what you are asking.
If you meant applying the java-gradle-plugin instead of the groovy-gradle-plugin, this of course will not produce any plugin classes. How should the Java plugin know about Groovy source files?
Why I'm not sure whether that is what you asked is, because the groovy-gradle-plugin already automatically applies the java-gradle-plugin. So if you want to use Groovy DSL precompiled script plugins, just apply the groovy-gradle-plugin as documented.
Plugins id's
For Groovy DSL precompiled script plugins you can only follow that convention if I remember correctly. With Kotlin DSL precompiled script plugins you can either follow that naming convention or you can also use package statements inside the script to "properly model" the plugin id.
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 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.
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 want to autogenerate some java classes from interfaces. My first thought was to write a code generator, and integrate it as a maven plugin.
I was thinking of creating a maven plugin with a codegen goal that is called during the build process.
So if I choose this route, how do I provide the plugin with the interfaces to be processed? And where should the generated files go?
Are there any existing plugins that can be configured to generate default class implementations?
Sources should go in {project.build.directory}/generated-sources/[plugin-id]/
Most plugins take configuration passed through the plugin configuration section in the pom. You can use default values as well, or an annotation and classpath scanning.
A plugin like the maven-jspc-plugin generates code, which you could take a look at. The "Better Builds With Maven" e-book also contains a reasonably comprehensive chapter on writing plugins.
Maybe have a look at the XDoclet Maven plugin- XDoclet is often used for generating sources from doclet-style markup in classes (e.g. autogenerating MBean interfaces from implementations) and that sounds similar to what you're doing.
I have used APT-Jelly to successfully generate java source code from annotated java. You may want to check it out.