Plugin dont work on java 9 #54

ingwarsw · 2017-08-02T21:25:03Z

Because using of unsupported option:
-Xbootclasspath/p is no longer a supported option.

Usage:

jaxws-maven-plugin/src/main/java/org/codehaus/mojo/jaxws/AbstractJaxwsMojo.java

Line 442 in 3f61d07

cmd.createArg().setValue( "-Xbootclasspath/p:" + classpath.ecp );

In java 9 there is option to replace those: https://bugs.openjdk.java.net/browse/JDK-8061972
But it need module name not jar so will be hard to use it.

Is this endorse mechanizm needed?

madduci · 2017-09-22T09:09:10Z

@ingwarsw I was able to compile with JDK9 (Oracle and Eclipse OpenJ9) by using the following maven plugins.
What's missing is the module-info.java file that must be injected into the final compile process.

<finalName>jaxws-fromwsdl-server</finalName>

<plugins>
  <plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>jaxws-maven-plugin</artifactId>
    <version>2.5</version>
    <dependencies>
      <dependency>
        <groupId>org.glassfish.metro</groupId>
        <artifactId>webservices-tools</artifactId>
        <version>2.3.1</version>
      </dependency>
      <dependency>
        <groupId>org.glassfish.metro</groupId>
        <artifactId>webservices-rt</artifactId>
        <version>2.3.1</version>
      </dependency>
    </dependencies>
    <executions>
      <execution>
        <goals>
          <goal>wsimport</goal>
        </goals>
        <configuration>
          <verbose>true</verbose>
          <wsdlDirectory>${project.basedir}/../</wsdlDirectory>
          <packageName>fromwsdl.server</packageName>
          <executable>${tool.wsimport}</executable>
          <useJdkToolchainExecutable>false</useJdkToolchainExecutable>
          <xdebug>true</xdebug>
        </configuration>
      </execution>
    </executions>
  </plugin>
  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <version>3.0.2</version>
    <executions>
      <execution>
        <phase>validate</phase>
        <goals>
          <goal>copy</goal>
        </goals>
        <configuration>
          <outputDirectory>${project.build.directory}/dependencies</outputDirectory>
          <silent>true</silent>
          <artifactItems>
            <artifactItem>
              <groupId>org.glassfish.metro</groupId>
              <artifactId>webservices-api</artifactId>
              <version>2.3.1</version>
              <type>jar</type>
            </artifactItem>
          </artifactItems>
        </configuration>
      </execution>
    </executions>
  </plugin>
  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.7.0</version>
    <configuration>
      <source>9</source>
      <target>9</target>
      <compilerArgs>
        <arg>-p</arg>
        <arg>${project.build.directory}/dependencies:${java.home}/jmods</arg>
        <arg>--add-modules</arg>
        <arg>java.xml.bind,java.xml.ws</arg>
      </compilerArgs>
    </configuration>
  </plugin>
</plugins>

amoscatelli · 2017-10-23T15:59:51Z

It doesn't work.

I tried with madduci configuration but I get the error all the same :

Processing: file:/C:/Users/amoscatelli/Documents/NetBeansProjects/SS730pClient/src/wsdl/InvioTelematicoSpeseSanitarie730p.wsdl
jaxws:wsimport args: [-keep, -s, 'C:\Users\amoscatelli\Documents\NetBeansProjects\SS730pClient\target\generated-sources\wsimport', -d, 'C:\Users\amoscatelli\Documents\NetBeansProjects\SS730pClient\target\classes', -verbose, -encoding, UTF-8, -Xnocompile, -p, fromwsdl.server, -Xdebug, "file:/C:/Users/amoscatelli/Documents/NetBeansProjects/SS730pClient/src/wsdl/InvioTelematicoSpeseSanitarie730p.wsdl"]
Error: Could not create the Java Virtual Machine.
-Xbootclasspath/p is no longer a supported option.
Error: A fatal exception has occurred. Program will exit.

amoscatelli · 2017-10-23T16:17:23Z

SS730pClient.zip

This a pom project you can use for testing the issue.

Please let me know if you can help

madduci · 2017-10-23T20:21:11Z

@amoscatelli you can disable the compilation of WSDL files and let maven-compiler-plugin do the job for you. You will need to use jdeps to generate a module-info.java based on what jaxws-plugin generates. it works perfectly

amoscatelli · 2017-10-23T20:46:00Z

Do you mean this ?

http://www.mojohaus.org/jaxws-maven-plugin/wsimport-mojo.html#xnocompile

I am already using xnocompile true, as you can see in the attachment.
And true is the default value btw.

So what do you mean ?

strmer15 · 2017-10-26T18:36:00Z

Ran into this issue today - seems like if you add in an explicit executable to the JDK 9 wsimport, you can get it to work:

<executable>${java.home}/bin/wsimport</executable>

It's annoying, but at least seems like a plausible workaround until this bug gets fixed.

tuxtor · 2017-11-02T00:54:34Z

I can confirm that @strmer15 workaround works for me.

For future reference, the executable tag goes into plugin configuration section.

Davio · 2017-11-05T19:58:01Z

I used this:

  <!-- Set wsimport for Windows/Linux -->
  <profiles>
    <profile>
      <id>win</id>
      <activation>
        <os>
          <family>windows</family>
        </os>
      </activation>
      <properties>
        <tool.wsimport>${java.home}/bin/wsimport.exe</tool.wsimport>
      </properties>
    </profile>
    <profile>
      <id>nix</id>
      <activation>
        <os>
          <family>!windows</family>
        </os>
      </activation>
      <properties>
        <tool.wsimport>${java.home}/bin/wsimport</tool.wsimport>
      </properties>
    </profile>
  </profiles>

And then in the plugin:

<plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>jaxws-maven-plugin</artifactId>
        <version>${jaxws-maven-plugin.version}</version>
        <configuration>
          <wsdlDirectory>src/main/webapp/WEB-INF/wsdl/</wsdlDirectory>
          <wsdlFiles>
            <wsdlFile>foo.wsdl</wsdlFile>
          </wsdlFiles>
          <vmArgs>
            <vmArg>-Djavax.xml.accessExternalSchema=all</vmArg>
          </vmArgs>
          <extension>true</extension>
          <keep>true</keep>
          <quiet>true</quiet>
        </configuration>
        <executions>
          <execution>
            <id>wsimport-from-jdk</id>
            <goals>
              <goal>wsimport</goal>
            </goals>
            <configuration>
              <executable>${tool.wsimport}</executable>
            </configuration>
          </execution>
        </executions>
      </plugin>

highsource · 2018-06-04T09:28:38Z

I have the same problem.
Here's a reproducing project.

jaxb2-basics-sample-jaxws-maven.zip

byrash · 2018-06-15T09:26:46Z

@highsource Add <executable>${java.home}/bin/wsimport</executable> to plugins configurations in your pom. That will do the Job

highsource · 2018-06-15T09:30:38Z

@byrash No. ${java.home}/bin/wsimport does not work with XJC plugins.

madduci · 2018-06-15T11:35:03Z

@highsource yes it works, with both Oracle JDK 9 and 10

highsource · 2018-06-15T14:49:08Z

@madduci Could you please point me to an example of using jaxws-maven-plugin with XJC plugins which would work under JDK 9?

highsource · 2018-06-15T15:04:25Z

@madduci @byrash Here's my example:

jaxb2-basics-sample-jaxws-maven-with-xjc-plugins.zip

Which does not work due to:

[INFO] jaxws:wsimport args: [-keep, -s, 'C:\Projects\workspaces\jaxb2-basics\jaxb2-basics-sample-jaxws-maven\target\generated-sources\jaxws', -d, 'C:\Projects\workspaces\jaxb2-basics\jaxb2-basics-sample-jaxws-maven\target\classes', -verbose, -extension, -Xnocompile, -B-Xequals, -B-XtoString, -b, 'file:/C:/Projects/workspaces/jaxb2-basics/jaxb2-basics-sample-jaxws-maven/src/main/resources/bindings.xjb', -b, 'file:/C:/Projects/workspaces/jaxb2-basics/jaxb2-basics-sample-jaxws-maven/src/main/resources/wsdl-bindings.xjb', "file:/C:/Projects/workspaces/jaxb2-basics/jaxb2-basics-sample-jaxws-maven/src/main/resources/main.wsdl"]
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8
no such JAXB option: -Xequals

The problem is explained here:

https://stackoverflow.com/questions/50669567/unrecognized-parameter-xsomeplugin-error-when-using-jaxb-xjc-plugins

With <executable>${java.home}/bin/wsimport.exe</executable> this simply calls wsimport from the JDK. Which uses "internal" XJC and is not compatible with "normal" XJC plugins.

So from my point of view this does not work.

But if it does, it must be very easy to prove. Just show an example of jaxws-maven-plugin using, say, JAXB2 Basics 0.12.0 buildable under Java 9 and I'll be more than happy.

zhivko · 2018-06-19T12:42:56Z

I am getting:

Exception in thread "main" java.lang.NoClassDefFoundError: java/sql/Connection at java.base/java.lang.Class.getDeclaredMethods0(Native Method) at java.base/java.lang.Class.privateGetDeclaredMethods(Class.java:3119) at java.base/java.lang.Class.getMethodsRecursive(Class.java:3260) at java.base/java.lang.Class.getMethod0(Class.java:3246) at java.base/java.lang.Class.getMethod(Class.java:2065) at [email protected]/com.sun.xml.internal.ws.model.RuntimeModeler.processMethod(RuntimeModeler.java:637) at [email protected]/com.sun.xml.internal.ws.model.RuntimeModeler.processClass(RuntimeModeler.java:476) at [email protected]/com.sun.xml.internal.ws.model.RuntimeModeler.buildRuntimeModel(RuntimeModeler.java:305) at [email protected]/com.sun.xml.internal.ws.db.DatabindingImpl.<init>(DatabindingImpl.java:85) at [email protected]/com.sun.xml.internal.ws.db.DatabindingProviderImpl.create(DatabindingProviderImpl.java:59) at [email protected]/com.sun.xml.internal.ws.db.DatabindingProviderImpl.create(DatabindingProviderImpl.java:43) at [email protected]/com.sun.xml.internal.ws.db.DatabindingFactoryImpl.createRuntime(DatabindingFactoryImpl.java:105) at [email protected]/com.sun.tools.internal.ws.wscompile.WsgenTool.buildModel(WsgenTool.java:243) at [email protected]/com.sun.tools.internal.ws.wscompile.WsgenTool.run(WsgenTool.java:113) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at [email protected]/com.sun.tools.internal.ws.Invoker.invoke(Invoker.java:138) at [email protected]/com.sun.tools.internal.ws.WsGen.main(WsGen.java:41) Caused by: java.lang.ClassNotFoundException: java.sql.Connection at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:466) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:566) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:499) ... 20 more
while wsgen is executed. I also used executable:

<execution> <id>generate-wsdl</id> <phase>prepare-package</phase> <goals> <goal>wsgen</goal> </goals> <configuration> <encoding>UTF-8</encoding> <resourceDestDir>${basedir}/src/wsdl</resourceDestDir> <inlineSchemas>true</inlineSchemas> <keep>false</keep> <wsdl>DctmService.wsdl</wsdl> <portname>{http://generic.documentum.telekom.si/}DcmtServiceImplPort</portname> <protocol>soap1.1</protocol> <sei>si.telekom.documentum.generic.DcmtServiceImpl</sei> <genWsdl>true</genWsdl> <verbose>true</verbose> <useJdkToolchainExecutable>false</useJdkToolchainExecutable> <executable>${java.home}/bin/wsgen</executable>  <xdebug>true</xdebug> <xnocompile>false</xnocompile> </configuration> </execution>

.. like classes that are part of jre 10 are missing that is really strange.

jonnybecker · 2018-06-20T06:24:25Z

Since JDK11 is lacking of wsimport: Is a JDK11 capable version of this plugin planned in the future?

tuxtor · 2018-06-20T21:50:27Z

Indeed wsimport is already removed http://openjdk.java.net/jeps/320

Maybe is possible to add wsimport from another source? AFAIK wsimport was the only option for top-down (WSDL to Java Code) web service generation

jonnybecker · 2018-06-21T05:19:13Z

There is jaxws-ri which comes with wsimport bundled and all this stuff. I guess this is the way to go for a plug-in to use it as a dependency.
com.sun.xml.ws:jaxws-ri 2.3.0.1

highsource · 2018-06-21T06:51:05Z

Just don't call wsimport from JDK via command-line. JAXB/XJC plugins won't work this way.

highsource · 2018-06-21T06:53:39Z

In the maven-jaxb2-plugin I'm using XJC APIs to invoke XJC to generate code. I'm using dependencies like:

		<dependency>
			<groupId>org.glassfish.jaxb</groupId>
			<artifactId>jaxb-xjc</artifactId>
			<version>${jaxb.version}</version>
		</dependency>
		<dependency>
			<groupId>org.glassfish.jaxb</groupId>
			<artifactId>jaxb-xjc-jdk9</artifactId>
			<version>${jaxb.version}</version>
		</dependency>

Thus I'm always sure which XJC I'm invoking and there are no problems with XJC plugins.

Calling xjc via command-line would be a dead end for many reasons.

madduci · 2018-06-21T10:33:42Z

this works on both JDK 9 and JDK 10 under Linux:

tool.wsimport points to JDK_HOME/bin/wsimport

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>jaxws-maven-plugin</artifactId>
  <executions>
    <execution>
      <id>wsdl-to-java</id>
      <phase>validate</phase>
      <goals>
        <goal>wsimport</goal>
      </goals>
      <configuration>
        <executable>${tool.wsimport}</executable>
        <wsdlDirectory>${wsdl.directory}</wsdlDirectory>
        <wsdlFiles>
          <wsdlFile>file1.wsdl</wsdlFile>
          <wsdlFile>file2.wsdl</wsdlFile>
          <wsdlFile>file3.wsdl</wsdlFile>
        </wsdlFiles>
        <destDir>${project.build.directory}/generated-sources</destDir>
        <sourceDestDir>${wsdl.generated.sources}</sourceDestDir>
        <destDir>${wsdl.generated.compiled}</destDir>
        <target>${jaxws.version}</target>
        <useJdkToolchainExecutable>false</useJdkToolchainExecutable>
        <xnocompile>false</xnocompile>
        <encoding>${encoding}</encoding>
        <verbose>false</verbose>
        <quiet>true</quiet>
        <!-- Enable access to local DTD files -->
        <args>
          <arg>-J-Djavax.xml.accessExternalDTD=file</arg>
        </args>
      </configuration>
    </execution>
  </executions>
</plugin>

highsource · 2018-06-21T10:35:37Z

@madduci This does not work with XJC plugins like JAXB2 Basics.

madduci · 2018-06-21T10:56:21Z

@highsource i do not use them

highsource · 2018-06-21T11:01:31Z

@madduci A lot of people do. And this is advertised as a feature of jaxws-maven-plugin:

https://www.mojohaus.org/jaxws-maven-plugin/examples/using-jaxb-plugins.html

Which effectively does not work with Java 9 then.

RangaSamudrala · 2018-07-26T00:01:40Z

Any updates on support for this OpenJDK v11 ?

Knut-Fjellheim · 2018-07-27T08:03:49Z

Just to mention it...
The proposed workaround for JDK9/10 would be for Linux
${java.home}/bin/wsimport
and for windows
${java.home}/bin/wsimport.exe
We have both Win/Mac/Linux in our developer environments, so this workaround is not a very practical solution for us.

madduci · 2018-07-27T08:10:28Z

@Knut-Fjellheim
you can work with maven profiles, that trigger the right path to wsimport based on system

mickaelbaron · 2018-08-18T09:28:12Z

Hi @Knut-Fjellheim,

http://www.mojohaus.org/jaxws-maven-plugin/examples/using-wstools-from-jdk.html

Please check this web page to solve your heterogenous developer environnements problem.

Mickael

RobotWizard93 · 2018-09-07T13:32:43Z

@jonnybecker
Did you solve the problem with JDK 11? I tried adding the dependency and it didn't work

jonnybecker · 2018-09-10T15:56:22Z

@RobotWizard93
No haven't, but i didn't look into it yet. Just adding it as a dependency won't do the trick, since the plugin will still look for the wsimport from the JDK.

airudah2000 · 2018-10-30T14:14:03Z

Has anyone found a workaround for this?

mickaelbaron · 2018-10-30T14:30:36Z

Hi,

Did you know this plugin is available in the official repository of JAXWS => https://github.com/eclipse-ee4j/metro-jax-ws?

As you can see, the jaxws-maven-plugin is proposed with the JAXWS implementation => https://github.com/eclipse-ee4j/metro-jax-ws/tree/master/jaxws-ri/jaxws-maven-plugin

However, two dependencies are missing com.sun.xml.ws:jaxws-tools-bundle:jar:2.3.1 and com.sun.xml.ws:jaxws-tools-bundle:jar:sources:2.3.1. To fix this problem follow this issue => javaee/metro-jax-ws#1251 (comment)

Mickael

phax · 2018-11-21T09:36:58Z

Hi,

I created a fork at https://github.com/phax/jaxws-maven-plugin that contains the changes from #71 and works with Java 8 and 11 (hopefully also 9 and 10).

It is also available on Maven Central at http://repo2.maven.org/maven2/com/helger/maven/jaxws-maven-plugin/2.6/jaxws-maven-plugin-2.6.pom and acts as a drop-in replacement. Please note the changed Maven group, so it's easy to switch back, once this plugin gets updated.

hth,

Edit: here are the Maven coordinates in a nicer way:

<plugin>
  <groupId>com.helger.maven</groupId>
  <artifactId>jaxws-maven-plugin</artifactId>
  <version>2.6</version>
  <configuration>
    ...
  </configuration>
</plugin>

Stephan202 · 2018-12-16T15:17:39Z

@phax thanks for your work! Just gave the fork a spin and it seems to behave as advertised 👍

…ndles mojohaus/jaxws-maven-plugin#54

…tched: com.helger.maven) to silently moved, but maintained com.sun.xml.ws.jaxws-maven-plugin - which also runs on all major JDKs. This also resolves mojohaus/jaxws-maven-plugin#54 completely

jonashackt · 2019-06-21T08:13:03Z

Thanks @phax for your work on the drop-in replacement. For me it worked on JDK 9, 11 & 12 - but sadly not on JDK 8. But throughout digging deeper into the problem I realized, what was already clear somehow: this plugin here is simply NOT maintained anymore - and many thanks to @mickaelbaron for pointing that out: the sources moved over to the JAX-WS reference implementation inside the eclipse-ee4j/metro-jax-ws project under:

https://github.com/eclipse-ee4j/metro-jax-ws/tree/master/jaxws-ri/jaxws-maven-plugin

To use the maintained version of this plugin, simply replace the old dependency in your pom.xml by the new one:

OLD!

<dependency>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>jaxws-maven-plugin</artifactId>
    <version>2.5</version>
</dependency>

NEW!

<dependency>
    <groupId>com.sun.xml.ws</groupId>
    <artifactId>jaxws-maven-plugin</artifactId>
    <version>2.3.2</version>
</dependency>

Nevermind the 'lower' version number, the sources have a newer date and adhere to the rest of the JAX-WS sourcecode.

phax · 2019-06-21T12:14:07Z

Hi,
I can confirm that

<dependency>
    <groupId>com.sun.xml.ws</groupId>
    <artifactId>jaxws-maven-plugin</artifactId>
    <version>2.3.2</version>
</dependency>

works in Java 8 to 12 for my projects. It seems like the plugin follows the versioning scheme of JAX-WS itself.
Nevertheless please elaborate on the problems you have with Java 8 and

<dependency>
    <groupId>com.helger.maven</groupId>
    <artifactId>jaxws-maven-plugin</artifactId>
    <version>2.6.1</version>
</dependency>

since I'm running it without issues on OpenJDK. Do you eventually have something in your endorsed path?

jonashackt · 2019-06-21T12:39:52Z

I'am using the jaxws-maven-plugin inside the wrapper project called https://github.com/codecentric/cxf-spring-boot-starter-maven-plugin - there I execute the plugin with the help of the https://github.com/TimMoore/mojo-executor, which isn't kind of a standard way I guess. Inside the BootCxfMojo.java class (not inside the current version though, since I switched to com.sun.xml.ws.jaxws-maven-plugin) I use execute the jaxws-maven-plugin with:

plugin(
                    groupId("com.helger.maven"),
                    artifactId("jaxws-maven-plugin"),
                    version("2.6"),
                    dependencies(
                            dependency(
                                    "org.jvnet.jaxb2_commons",
                                    "jaxb2-namespace-prefix",
                                    "1.3"),
                            dependency(
                                    "com.sun.xml.ws",
                                    "jaxws-tools",
                                    "2.3.2"))
                    ),

Here's the build log: https://travis-ci.org/codecentric/cxf-spring-boot-starter-maven-plugin/builds/548073656?utm_source=github_status&utm_medium=notification

For me I sounds like that adding jaxws-tools was not enough (I had an error regarding that one on JDK8), but after having another error I luckily found the maintainence problem with the current plugin and didn't go any further there, since I think this is kind of a dead end.

phax · 2019-06-21T13:42:07Z

Ah okay - Gradle is tricky here, because it doesn't support JDK version based profile activation. Since jaxws-tools 2.3.2 requires Java 9 or later this doesn't work.
See https://github.com/phax/ph-jaxws-pom/#gradle-usage for the different artefacts needed for Java 1.8 and Java 9+

amoscatelli · 2019-06-21T15:37:18Z

I don't understand.
If I try to use:

com.sun.xml.ws jaxws-maven-plugin 2.3.2

I get this error :

Error injecting: private org.eclipse.aether.spi.log.Logger org.apache.maven.repository.internal.DefaultVersionRangeResolver.logger

phax · 2019-06-21T15:54:50Z

Well, maybe your Eclipse version is too old - no idea. Nevertheless if com.helger.maven jaxws-maven-plugin 2.6.1 works for you - use it. I will have an eye on it anyway

amoscatelli · 2019-06-21T15:56:50Z

I am not using Eclipse, I am using Netbeans what's why I can't understand where this dependency comes from. Something requires that logger and the version is not aligned correctly ...

amoscatelli · 2019-06-21T16:21:44Z

I managed to have this working.
You have to force using newer version of Maven:

Tested with:

<prerequisites>
    <maven>3.5.4</maven>
</prerequisites>

Now everything works with:

            <plugin>
                <groupId>com.sun.xml.ws</groupId>
                <artifactId>jaxws-maven-plugin</artifactId>
                <version>2.3.2</version>
            </plugin>

… incompatibilty with old JDK8 versions (see mojohaus/jaxws-maven-plugin#54 (comment) and http://www.rultor.com/t/19307-1). So let's try to use yegor256/rultor as a workaround, until we shift away from rultor somewhere in the future.

theit · 2019-09-12T19:22:52Z

See pull request #71 for a solution of this issue

GabrielBB · 2019-09-20T15:22:54Z

Just use this fork: https://github.com/phax/jaxws-maven-plugin. It works with Java 9-13. I'm using it with Java 13 right now and is all good!

… incompatibilty with old JDK8 versions (see mojohaus/jaxws-maven-plugin#54 (comment) and http://www.rultor.com/t/19307-1). So let's try to use yegor256/rultor as a workaround, until we shift away from rultor somewhere in the future.

theit mentioned this issue Oct 12, 2018

Java 9 support #71

Merged

highsource mentioned this issue Dec 6, 2018

How can I use the annotation plugin to enhance classes generated with jaxws-maven-plugin? highsource/jaxb2-annotate-plugin#17

Open

stIncMale mentioned this issue Jan 3, 2019

wsimport and wsgen tools removed from Java 11 javaee/metro-jax-ws#1251

Closed

CauchyPeano mentioned this issue Jun 11, 2019

Doesn't work with Java 11 codecentric/cxf-spring-boot-starter-maven-plugin#27

Closed

jonashackt added a commit to codecentric/cxf-spring-boot-starter-maven-plugin that referenced this issue Jun 13, 2019

#27 switching to drop-in replacement for jaxws-maven-plugin, which ha…

fe70127

…ndles mojohaus/jaxws-maven-plugin#54

andham closed this as completed in #71 Dec 30, 2019

Plugin dont work on java 9 #54

Plugin dont work on java 9 #54

Comments

ingwarsw commented Aug 2, 2017

madduci commented Sep 22, 2017 • edited Loading

amoscatelli commented Oct 23, 2017 • edited Loading

amoscatelli commented Oct 23, 2017

madduci commented Oct 23, 2017

amoscatelli commented Oct 23, 2017

strmer15 commented Oct 26, 2017

tuxtor commented Nov 2, 2017

Davio commented Nov 5, 2017 • edited Loading

highsource commented Jun 4, 2018

byrash commented Jun 15, 2018 • edited Loading

highsource commented Jun 15, 2018

madduci commented Jun 15, 2018

highsource commented Jun 15, 2018

highsource commented Jun 15, 2018

zhivko commented Jun 19, 2018 • edited Loading

jonnybecker commented Jun 20, 2018 • edited Loading

tuxtor commented Jun 20, 2018

jonnybecker commented Jun 21, 2018 • edited Loading

highsource commented Jun 21, 2018

highsource commented Jun 21, 2018

madduci commented Jun 21, 2018

highsource commented Jun 21, 2018

madduci commented Jun 21, 2018

highsource commented Jun 21, 2018

RangaSamudrala commented Jul 26, 2018

Knut-Fjellheim commented Jul 27, 2018

madduci commented Jul 27, 2018

mickaelbaron commented Aug 18, 2018

RobotWizard93 commented Sep 7, 2018

jonnybecker commented Sep 10, 2018 • edited Loading

airudah2000 commented Oct 30, 2018

mickaelbaron commented Oct 30, 2018

phax commented Nov 21, 2018 • edited Loading

Stephan202 commented Dec 16, 2018

jonashackt commented Jun 21, 2019 • edited Loading

phax commented Jun 21, 2019

jonashackt commented Jun 21, 2019 • edited Loading

phax commented Jun 21, 2019

amoscatelli commented Jun 21, 2019

phax commented Jun 21, 2019

amoscatelli commented Jun 21, 2019

amoscatelli commented Jun 21, 2019

theit commented Sep 12, 2019

GabrielBB commented Sep 20, 2019 • edited Loading

madduci commented Sep 22, 2017 •

edited

Loading

amoscatelli commented Oct 23, 2017 •

edited

Loading

Davio commented Nov 5, 2017 •

edited

Loading

byrash commented Jun 15, 2018 •

edited

Loading

zhivko commented Jun 19, 2018 •

edited

Loading

jonnybecker commented Jun 20, 2018 •

edited

Loading

jonnybecker commented Jun 21, 2018 •

edited

Loading

jonnybecker commented Sep 10, 2018 •

edited

Loading

phax commented Nov 21, 2018 •

edited

Loading

jonashackt commented Jun 21, 2019 •

edited

Loading

jonashackt commented Jun 21, 2019 •

edited

Loading

GabrielBB commented Sep 20, 2019 •

edited

Loading