Develop Reference

Open API Maven Plugin - Generate only specifc API model classes

I am working on generation of model classes by Open API Maven plugin which I need to use in my business logic. The api is generated by other team and given to us. It has lot of model classes specification but I need only generation of 3 model classes from the api.yaml template
How this can be achieved?
The plugin configuration
<plugin>
<groupId>org.openapitools</groupId>
<artifactId>openapi-generator-maven-plugin</artifactId>
<executions>
<execution>
<id>generate-java-client</id>
<configuration>
<inputSpec>
${project.build.directory}/../../../../../../../../../component/service/app/src/main/resources/api/v1/api-v1.yaml
</inputSpec>
**<modelPackage>com.example.editing.model</modelPackage>**
<generateSupportingFiles>false</generateSupportingFiles>
<generateApis>false</generateApis>
<generateApiTests>false</generateApiTests>
<generateModelTests>false</generateModelTests>
</configuration>
</execution>
</executions>
</plugin>

According to the github readme of the openapi-generator-maven-plugin, there is a configuration option called modelsToGenerate which does exactly what you want:
A comma separated list of models to generate. All models is the default.

How to generate java entity by Graphql schema

I'm a newcomer for graphql java client development. Recently I meet a problem that how to generate a java entity through the graphql schema definition. Since in my side, the schema is always changing by another side, so I want a method to generate the java entity class automatically instead of reading the schema manually then change the code. If there are any practices on such a requirement? Thanks.

You could look into the following maven plugin. It would help you generate Java classes from your .graphqls files.
Assuming you have only one file defining your GraphQL model, named myGraphqls, I would use this plugin as follow:
<build>
<plugins>
<plugin>
<groupId>io.github.kobylynskyi</groupId>
<artifactId>graphql-codegen-maven-plugin</artifactId>
<version>1.2.3</version>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<graphqlSchemaPaths>
<graphqlSchemaPath>${project.basedir}/src/main/resources/graphql/myGraphqls.graphqls</graphqlSchemaPath>
</graphqlSchemaPaths>
<outputDir>${project.build.directory}/generated-sources/graphql</outputDir>
<packageName>com.graphql.model</packageName>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
After running maven, you would be able to find in the generated-sources folder, a folder named graphql with the classes generated under the package com.graphql.model.

How can I generate classes from outside XSD file using JAXB XJC

I have two projects:
A
/src/main/resources/schema.xsd
pom.xml
B
/src/main/gen
pom.xml
I want in B project generate classes from XSD, that exists in A Project
In pom.xml of B project I have:
<dependencies>
<dependency>
<groupId>test</groupId>
<artifactId>A</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxb2-maven-plugin</artifactId>
<executions>
<execution>
<id>xjc</id>
<goals>
<goal>xjc</goal>
</goals>
</execution>
</executions>
<configuration>
<schemaDirectory>src/main/resources</schemaDirectory>
<outputDirectory>src/main/gen</outputDirectory>
</configuration>
</plugin>
</plugins>
</build>
But xsd file is not found in classpath:
Failed to execute goal org.codehaus.mojo:jaxb2-maven-plugin:1.5:xjc (xjc) on project B: No schemas have been found
How can I use xsd from another project?

My maven-jaxb2-plugin supports separate schema compilation.
How to do this:
Add your artifact a as episode.
If a.xsd is imported into b.xsd, you have to make this schema available to JAXB when compiling b:
One way to do this is to extract a.xsd from the artifact a using Maven dependency plugin, for instance.
Another way would be to use a catalog file to rewrite the location of a.xsd into the artifact a
See this test project for example.
The project a is totally unspectacular. Just compiles the schema a.xsd.
The project b is more interesting. Let's take a look.
pom.xml:
<plugin>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
<configuration>
<catalog>src/main/resources/catalog.cat</catalog>
<episodes>
<episode>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin-tests-MAVEN_JAXB2_PLUGIN-82-a</artifactId>
</episode>
</episodes>
</configuration>
</plugin>
The configuration says use the artifact a as episode. So when JAXB/XJC meets classes compiled in a, it will reuse them instead of generating new ones.
By the way, you can use the useDependenciesAsEpisodes instead of configuring individual episodes. In this case all the dependencies will be treated as episodes which is very convenient (less configuration).
The configuration also says to use the catalog file:
REWRITE_SYSTEM "http://www.ab.org" "maven:org.jvnet.jaxb2.maven2:maven-jaxb2-plugin-tests-MAVEN_JAXB2_PLUGIN-82-a:jar::!"
This instructs JAXB/XJC to rewrite all schema URLs starting with http://www.ab.org to start with maven:org.jvnet.jaxb2.maven2:maven-jaxb2-plugin-tests-MAVEN_JAXB2_PLUGIN-82-a:jar::! instead. The latter will be processed by the maven-jaxb2-plugin and finally resolved to the resource in a.
Let's take a closer look. The schema b.xsd imports http://www.ab.org/a.xsd:
<import namespace="urn:a" schemaLocation="http://www.ab.org/a.xsd"/>
This will be rewritten to maven:org.jvnet.jaxb2.maven2:maven-jaxb2-plugin-tests-MAVEN_JAXB2_PLUGIN-82-a:jar::!/a.xsd which will be resolved to the a.xsd inside the JAR of the project a. So, finally, JAXB/XJC will be able to read this schema from the a's JAR artifact.
You can also use PUBLIC instead of REWRITE_SYSTEM to reference a.xsd per namespace URI instead of schema location (which is logically better):
PUBLIC "urn:a" "maven:org.jvnet.jaxb2.maven2:maven-jaxb2-plugin-tests-MAVEN_JAXB2_PLUGIN-82-a:jar::!/a.xsd"
However there's a bug in JAXB/XJC this does not work if you have schemaLocation in your xs:import.
This would work at the moment:
<xsd:import namespace="urn:a"/>
This won't work at the moment:
<xsd:import namespace="urn:a" schemaLocation="a.xsd"/>
I've sent Oracle a pull request which fixes that but it's not applied yet.
The explanation above applies to the maven-jaxb2-plugin and works in versions 0.10.0 and higher.
Your original question is about jaxb2-maven-plugin from Codehaus which is a different Maven plugin. This plugin does not have all the features I've described above, but at least episodes should work via arguments. Catalogs must also work, but I believe, jaxb2-maven-plugin does not support resolving schemas in Maven artifacts. You can use the maven-dependency-plugin to extract a.xsd from artifact a instead.
SO disclaimer: I am the author of the maven-jaxb2-plugin.
Note for reviewers: it is NOT my intention here to push/advertise my plugin, I just want to provide a solution to the asked question. And it appears that my project offers the best/most elegant and full solution.

The problem with this configuration is that <schemaDirectory> expects a File name/path. The thing about File is that it looks for files on the file system, searching from the current working directory. In which case the project root. But the resource from project A is not in the src/main/resources of the project B. It is a classpath resource, of which (when build in maven), the src/main/resources doesn't even exist anymore.
I've never tried to do with with the jaxb2-maven-plugin, so I am not sure if it is possible.
But with the maven-jaxb2-plugin, it allows Compiling a schema from a Maven artifact. You could so something like
<plugin>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
<version>0.9.0</version>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
<configuration>
<schemas>
<schema>
<dependencyResource>
<groupId>projecta.groupid</groupId>
<artifactId>project-a</artifactId>
<version>${project.version}</version>
<resource>/schema.xsd</resource>
</dependencyResource>
</schema>
</schemas>
<generateDirectory>src/main/gen/</generateDirectory>
<generatePackage>mypackage</generatePackage>
</configuration>
</plugin>
In which case, it's resource (schema.xsd) is in the src/main/resources of project A. The plugin will generate the class files to the mypackage package and sources the src/main/gen

We can also use as below in pom.xml file
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxb2-maven-plugin</artifactId>
<version>1.5</version>
<executions>
<execution>
<id>id1</id>
<goals>
<goal>xjc</goal>
</goals>
<configuration>
<outputDirectory>src/main/java</outputDirectory>
<clearOutputDir>false</clearOutputDir>
<packageName>com.subu.xsd.model</packageName>
<schemaDirectory>src/main/java/schemadir</schemaDirectory>
<schemaFiles>XYZ.xsd</schemaFiles>
</configuration>
</execution>
</executions>
</plugin>

Jibx Maven plugin: how to set Java package in xsd -> Java transform when namespace was defined

I use Spring Object-Xml mapping with Jibx to convert some xsd files to Java source files. Jibx is called by jibx-maven-plugin in the build process. My schema files (.xsd) have a namespace "a.b.com" but I want that the generated Java sources are under package "a.com" because the rest of the Java code is organized like that.
I noticed Java packages are determined automatically based on xsd's namespace. Therefore, the question: is it possible to set the java package of output Java source files in xsd->Java transform when using the Jibx Maven plugin when a namespace was defined in the the schema files?
Proposed solutions so far:
1) Use build executions
Proposed below.
Problems:
xsd->Java transform is run every build. I want to manually run it or that is only run when I change xml schemas.
prefer-inline attribute in customization.xml acts differently with this setup, inlining attributes of an object reference
2) Use customization xml to set Java package
Proposed here: Jibx Codegen: customization file - package per schema
Problem: It did not work.
3) modular schema
Proposed here: Jibx Maven plugin: cross-reference among schemas when they are converted in different build executions
Problem: Too complicated to setup one pom for each schema, generating a jar for each schema and importing the jar in other schemas.
Was anybody successful to solve these issues and was able to set custom Java packages in a xsd->Java conversion when namespace is defined in the xml schemas?
Thanks in advance.

Based on the documentation it can be done like the following:
<plugin>
<groupId>org.jibx</groupId>
<artifactId>jibx-maven-plugin</artifactId>
<version>1.2.4.5</version>
<configuration>
<schemaLocation>src/main/conf</schemaLocation>
<includeSchemas>
<includeSchema>myschema.xsd</includeSchema>
</includeSchemas>
<options>
<package>my.package</package>
</options>
</configuration>
<executions>
<execution>
<goals>
<goal>schema-codegen</goal>
</goals>
</execution>
</executions>
</plugin>
But you should be carefull about using the packagename instead of the defaults which are coming from the xsd-namespaces, cause it can happen that you will get clashes within the generated source if you have multiple namespaces.
You can define multiple executions to have different schematas having different package names.
<plugin>
<groupId>org.jibx</groupId>
<artifactId>jibx-maven-plugin</artifactId>
<version>1.2.4.5</version>
<executions>
<execution>
<id>schemata-a</id>
<goals>
<goal>schema-codegen</goal>
</goals>
<configuration>
<schemaLocation>src/main/conf-a</schemaLocation>
<includeSchemas>
<includeSchema>myschema.xsd</includeSchema>
</includeSchemas>
<options>
<package>my.package.a</package>
</options>
</configuration>
</execution>
<execution>
<id>schemata-b</id>
<goals>
<goal>schema-codegen</goal>
</goals>
<configuration>
<schemaLocation>src/main/conf-b</schemaLocation>
<includeSchemas>
<includeSchema>xyz.xsd</includeSchema>
</includeSchemas>
<options>
<package>my.package.b</package>
</options>
</configuration>
</execution>
</executions>
</plugin>
If you can change the namespaces in your xsd files makes life easier.

Difference of Maven JAXB plugins

I have determined that two JAXB plugins for Maven 2 exist, with some different configurations.
The one is from Sun: http://jaxb.dev.java.net/jaxb-maven2-plugin/, the other from Mojohaus: http://mojohaus.org/jaxb2-maven-plugin/
Which of these two plugins can be recommended?
Thanks Matt. On my little research project, I found that there's quite another plugin comming from the sunners:
<groupId>com.sun.tools.xjc.maven2</groupId>
<artifactId>maven-jaxb-plugin</artifactId>
and that one:
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
and still the one from Codehouse.

Let's summarize. We have/had:
the maven-jaxb2-plugin (https://github.com/highsource/maven-jaxb2-plugin)
the maven-jaxb-plugin (https://jaxb.dev.java.net/jaxb-maven2-plugin/)
the jaxb2-maven-plugin (https://github.com/mojohaus/jaxb2-maven-plugin)
Based on the comments of this thread, I've always used the maven-jaxb2-plugin (i.e. plugin #1):
Concerning the
org.jvnet.jaxb2.maven2:maven-jaxb2-plugin
versus
com.sun.tools.xjc.maven2:maven-jaxb-plugin,
from my point of view it's definitely
the first one
(http://maven-jaxb2-plugin.java.net/).
This plugin has much more features
than
com.sun.tools.xjc.maven2:maven-jaxb-plugin,
the development is active. Finally,
I'm one of the authors :) and I'd say
we keep in touch with JAXB developers
and users and react to the latests
features/requests.
And indeed, the plugin #2 is dead. And because I've always been happy with #1, I've never used plugin #3 so can't really say anything about it. Just in case, here is a working configuration for plugin #1:
<project>
...
<build>
<plugins>
<plugin>
<inherited>true</inherited>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
<plugin>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>

I have recently tried the three plug-ins mentioned above (included here as well):
the maven-jaxb2-plugin (http://maven-jaxb2-plugin.java.net/)
the maven-jaxb-plugin (https://jaxb.dev.java.net/jaxb-maven2-plugin/)
the jaxb2-maven-plugin (http://mojo.codehaus.org/jaxb2-maven-plugin/)
I ended up using a fourth option: The CXF XJC Maven Plugin http://cxf.apache.org/cxf-xjc-plugin.html
If I am missing something I would like to know, but the configuration seemed more straightforward for what I was trying to do and more easily allowed me to to deal with duplicate class generation within the same namespace -- similar to this question: Is there a way to deal with duplicate element definitions across multiple .xsd files in JAXB?.
I now have granular control over each incoming XSD and corresponding java package; here is a sample configuration close to the one I am using.
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-xjc-plugin</artifactId>
<version>2.3.0</version>
<configuration>
<extensions>
<extension>org.apache.cxf.xjcplugins:cxf-xjc-dv:2.3.0</extension>
</extensions>
</configuration>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<goals>
<goal>xsdtojava</goal>
</goals>
<configuration>
<sourceRoot>${basedir}/target/generated-sources/src/main/java</sourceRoot>
<xsdOptions>
<xsdOption>
<xsd>src/main/resources/schema/commands.xsd</xsd> <!--shares a common.xsd file causing the conflicts-->
<packagename>com.foo.bar.commands</packagename>
</xsdOption>
<xsdOption>
<xsd>src/main/resources/schema/responses.xsd</xsd>
<packagename>com.foo.bar.responses</packagename>
</xsdOption>
</xsdOptions>
</configuration>
</execution>
</executions>
</plugin>

I am the author of maven-jaxb2-plugin.
The maven-jaxb2-plugin currently uses JAXB 2.1. In the next versions we'll also provide JAXB 2.0 and JAXB 2.2 versions.
As for "which plugin is better" discussion, check the features, decide yourself. Let me know if you miss some functionality.

maven-jaxb2-plugin uses the JAXB reference implementation by Oracle/Sun
cxf and jaxb2-maven-plugin use Apache Xerces

On a slight tangent: there was a problem with use of maven-jaxb2-plugin with Eclipse Indigo that I posted here. A fix (extension) has recently become available.
This is not meant to disagree, at all, with the recommendation of maven-jaxb2-plugin over maven2-jaxb-plugin. I don't know, but I expect that maven2-jaxb-plugin has the same problem, probably unresolved.

I would guess that one is for the original JAXB specification and the codehaus one is for the JAXB 2.1 specification (and if the dev.java.net would load some time this century, I'd be able to say for sure).