We Keep Coding

graphql maven plugin via proxy

for our project we generate graphql source files via the com.expediagroup:graphql-kotlin-maven-plugin:introspect-schema plugin during runtime.
Unfortunately our backend changed and we can no longer reach the graphql endpoint directly. Instead we have to use a proxy.
So the question is how to configure a proxy for this plugin? I checked the documentation but was not successful.
We also configured a http.proxyHost but the plugin seems to ignore it.
Any advice would be much appreciated.
This is the code for the plugin configuration.
<plugin>
<groupId>com.expediagroup</groupId>
<artifactId>graphql-kotlin-maven-plugin</artifactId>
<version>${graphql-kotlin.version}</version>
<executions>
<execution>
<goals>
<goal>introspect-schema</goal>
<goal>generate-client</goal>
</goals>
<configuration>
<endpoint>https://foo.bar.com/graphql</endpoint>
<packageName>com.expediagroup.graphql.generated</packageName>
<schemaFile>${project.build.directory}/schema.graphql</schemaFile>
<allowDeprecatedFields>true</allowDeprecatedFields>
<customScalars>
<customScalar>
<!-- custom scalar Any type -->
<scalar>Any</scalar>
<!-- fully qualified Java class name of a custom scalar type -->
<type>kotlin.Any</type>
<!-- fully qualified Java class name of a custom com.expediagroup.graphql.client.converter.ScalarConverter
used to convert to/from raw JSON and scalar type -->
<converter>example.com.utils.AnyScalarConverter</converter>
</customScalar>
</customScalars>
</configuration>
</execution>
</executions>
</plugin>

How to generate python protobuf from java maven project

I have maven project in which I have defined various .proto files whose corresponding java files are generated through maven plugin. This generated files would be used for implementation [rpc - server implementation], but I want this to be consumed by python client.
Hence need python equivalent to these proto files.
One way is to manually run python protobuf command to these .proto files and generate code, but this would be too manual work. I am looking for some other alternative.
Any help would be appreciated.

You could automate your manual command b running it from Maven. Take a look at the exec-maven-plugin plugin.
You need to add something like that to the plugins part of your pom.xml:
<plugin>
<artifactId>exec-maven-plugin</artifactId>
<groupId>org.codehaus.mojo</groupId>
<executions>
<execution>
<id>Stuff I want done</id>
<phase>generate-sources</phase>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<executable>path/stuff.sh</executable>
</configuration>
</execution>
</executions>
</plugin>
Adapt the phase and the script you want to run.

Worked by adding execution goal as "compile-python" for protobuf-maven-plugin (link) in pom file.

JavaFX application does not start with EclipseLink Moxy

I've added EclipseLink MOXy to my JavaFX-8 application, and since then the application does not start anymore. The error is: Could not find or load main class x.y.z. When I remove MOXy, then the application starts perfectly well. Of course then, the application doesn't use the MOXy implementation of JAXB.
The JavaFX application is packaged as a self executable jar. It includes a Weld implementation of CDI for JavaSE, and a Jersey implementation of jax-rs. I do have a jaxb.properties file in the package that contains my JAXB classes, and it does specify the JAXB context factory of MOXy.
So basically, I don't understand the reason why the application does not start anymore when MOXy is packaged within the application. Any clue?
Edit:
The problem may come from a jar file used as a dependency of MOXy that could be signed.

Ok, that's indeed a signature mismatch in the produced application JAR file.
I'm using maven to build the JavaFX application. In the build process, all the dependencies are unpacked during the package phase, and are then packed again in a single JAR file containing my application.
The unpack step is done with the maven dependency plugin. I had to add the following configuration to exclude all the signature files:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack-dependencies</id>
<phase>package</phase>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<configuration>
<excludes>META-INF/*.SF</excludes>
<excludes>META-INF/*.DSA</excludes>
<excludes>META-INF/*.RSA</excludes>
<excludeScope>system</excludeScope>
<excludeGroupIds>junit,org.mockito,org.hamcrest</excludeGroupIds>
<outputDirectory>${project.build.directory}/classes</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
Now it works.

maven-soapui-pro-plugin: parameterize WSDl location

I am trying to start an embbeded soapui mock webservice using the maven-soapui-pro-plugin plugin.
This works perfectly on my local machine but will obviously crash on the continuous integration plateforme as the project file references a wsdl on the local filesystem.
Therefore I have four options:
1/ Find a way to pass the wsdl file location as a parameter.
2/ Change this reference to an HTTP (which means I have to install an Apache server)
3/ Manualy change the references to the wsdl in the project file.
4/ Replace that plugin by an other one
<plugin>
<groupId>eviware</groupId>
<artifactId>maven-soapui-pro-plugin</artifactId>
<version>4.5.0</version>
<dependencies>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.6</version>
</dependency>
</dependencies>
<executions>
<execution>
<phase>process-test-resources</phase>
<goals>
<goal>mock</goal>
</goals>
<configuration>
<projectFile>D:\Documents and Settings\jhagai\Bureau\Toto-soapui-project.xml</projectFile>
<mockService>MockService</mockService>
<port>8888</port>
<path>/test</path>
<noBlock>true</noBlock>
</configuration>
</execution>
</executions>
</plugin>
I feel like I am the only person facing this issue is it possible?

First off you don't actually need the wsdl file on the CI server. There are several tests in on our CI server that do not point to a wsdl file. SoapUI uses the wsdl file to generate the project and sample requests, but if you run the test without it and your test is configured properly, it shouldn't fail. We have implemented number 2 that you have listed, but this is so testers don't need to generate the wsdls themselves.
The problem I see above is the hard coded project file. You should be able to handle this by saving your project in your maven project and pointing to it there (map to it based on the location of the POM).

Which is the best maven's plugin to generate a Web Service Client?

I have to generate a WS Client and I can't decide which plugin to use. Until now my options are: jaxb2-maven-plugin, axistools-maven-plugin and jaxws-maven-plugin.

I have to generate a WS Client and I can't decide wich plugin to use. Until now my options are: jaxb2-maven-plugin, axistools-maven-plugin and jaxws-maven-plugin.
First, the jaxb2-maven-plugin is not really intended to generate WS clients. ELIMINATED.
Second, personally I wouldn't use Axis even for client development only so I won't recommend using the axistools-maven-plugin. ELIMINATED.
This leaves us with the JAX-WS RI and the Apache CXF stacks, and their respective Maven plugins: the JAX-WS Maven Plugin (instructions to use the JAX-WS Maven Plugin can be found on the Usage page) and the cxf-codegen-plugin.
Regarding the pros and cons, I would summarize them like this:
JAX-WS RI is included in Java 6, but the documentation is more "rough" (although you'll find plenty of tutorials about JAX-WS RI too).
Apache CXF is better documentated and provide more flexibility if you want to go beyond the spec.
At the end, both choices are decent so I suggest to browse the links a bit and to make your own opinion.

I use jaxws-maven-plugin. In my opinion, JAX-WS is the de-facto standard implementation for WS. It has much better generated code than AXIS, and easier to config and implement. It has Maven and Spring support.
Generating client-side code from wsdl file, in pom.xml:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<executions>
<execution>
<id>generate-reports-ws-code</id>
<phase>generate-sources</phase>
<goals>
<goal>wsimport</goal>
</goals>
<configuration>
<!-- This property is used to support having multiple <execution> elements. The plugin has, from some reason, only one timestamp file per the all executions, thus if you have two executions, it doesn't know exactly when to recompile the code. Here we tell it explicitly to have one timestamp file per each execution --> <staleFile>${project.build.directory}/jaxws/stale/.staleFlag.reports</staleFile>
<packageName>com.acme.reports.ws.api</packageName>
<wsdlDirectory>${project.build.directory}/wsdl</wsdlDirectory>
<wsdlFiles>
<wsdlFile>InternalReportsAPIService.wsdl</wsdlFile>
</wsdlFiles>
<verbose>true</verbose>
<sourceDestDir>${wsdl.generated.source.files.dir}</sourceDestDir>
</configuration>
</execution>
</executions>
</plugin>
An interface to create the client service bean (this is not auto generated):
public interface InternalReportsAPIServiceFactory {
public InternalReportsAPIService createInternalReportsAPIService();
}
Its Bean implementation:
public class InternalReportsAPIServiceFactoryBean implements InternalReportsAPIServiceFactory {
private URL acmeReportsWsdlURL;
private final static QName V1_QNAME = new QName("http://internal.reports.api.acme.net/v1","InternalReportsAPIService");
#Override
public InternalReportsAPIService createInternalReportsAPIService() {
return new InternalReportsAPIService(acmeReportsWsdlURL, V1_QNAME);
}
public void setAcmeReportsWsdlUrl(String acmeReportsWsdlUrl) {
try {
this.acmeReportsWsdlURL = new URL(acmeReportsWsdlUrl);
} catch (MalformedURLException ex) {
throw new RuntimeException("Acme Reports WSDL URL is bad: "+ex.getMessage(), ex);
}
}
}
The idea in this bean (used as Spring bean) is to have a singleton for generating a client service code. It requires two inputs: The WSDL url - that is, the actual URL of the server which implements the WSDL. The client service code, upon construction, send a get request for the WSDL at the supplied URL. It then creates the WSDL based on the annotations residing in the auto generated code, and it compares it. I believe this is done to make sure you're running against the correct server version.
So, I've placed the url in a property file accessible to my application, thus I initialize in my Spring application context file.
Here's an example of using the factory to generate a service and then using it:
InternalReportsAPIService internalReportsAPIService = acmeReportsWSFactory.createInternalReportsAPIService();
InternalReportsAPI port = internalReportsAPIService.getInternalReportsAPIPort();
From here, just use the port variable to call any operation available on the wsdl.

Maven plugins required:
cxf-java2ws-plugin (JAX-WS to WSDL)
cxf-codegen-plugin (WSDL to Java)
JAX-WS to WSDL
To generate the WSDL document from the JAX-WS annotated class by configuring cxf-java2ws-plugin with the ‘java2ws’ goal.
Add the cxf-rt-frontend-jaxws dependency and project dependencies required for the JAX-WS annotated class as plugin dependencies.
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-java2ws-plugin</artifactId>
<version>2.5.1</version>
<dependencies>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-jaxws</artifactId>
<version>2.5.1</version>
</dependency>
<dependency>
<groupId>com.medici.app</groupId>
<artifactId>services</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
</dependencies>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<configuration>
<className>com.medici.app.services.WebServiceBean</className>
<genWsdl>true</genWsdl>
</configuration>
<goals>
<goal>java2ws</goal>
</goals>
</execution>
</executions>
</plugin>
WSDL 2 Java
To generate the Java client from the WSDL document by configuring cxf-codegen-plugin with ‘wsdl2java’ goal.
The ‘-p’ argument specifies the package classes .
The generated classes will be placed in the target/generated-sources/cxf folder.
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>2.5.1</version>
<executions>
<execution>
<id>process-sources</id>
<phase>generate-sources</phase>
<configuration>
<wsdlOptions>
<wsdlOption>
<wsdl>${project.build.directory}/wsdl/WebService.wsdl</wsdl>
<extraargs>
<extraarg>-p</extraarg>
<extraarg>com.medici.app.client.model</extraarg>
</extraargs>
</wsdlOption>
</wsdlOptions>
</configuration>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
</executions>
</plugin>