I have a Google App Engine Standard Maven project, which I created with the appengine-standard-archetype archetype.
I want to use the ${project.version} variable as deploy version, but the value is not allowed for certain characters:
May only contain lowercase letters, digits, and hyphens. Must begin
and end with a letter or digit. Must not exceed 63 characters.
The value 0.0.1-SNAPSHOT need to be modified. I then used the build-helper-maven-plugin to obtain the replacement
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<id>version-urlsafe</id>
<goals>
<goal>regex-property</goal>
</goals>
<configuration>
<name>project.version.urlsafe</name>
<value>${project.version}</value>
<regex>\.</regex>
<replacement>-</replacement>
<toLowerCase>true</toLowerCase>
<failIfNoMatch>false</failIfNoMatch>
</configuration>
</execution>
</executions>
</plugin>
And the maven-antrun-plugin to show the value
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<id>regex-replace-echo</id>
<phase>package</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>******** Displaying value of property ********</echo>
<echo>${project.version.urlsafe}</echo>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
At the end I used the new property as version for deploy
<app.deploy.version>${project.version.urlsafe}-urlsafe</app.deploy.version>
Note that I add the -urlsafe at the end of the value only to understand why the value is not considered
Running the deploy with mvn appengine:deploy I'm getting this output
...
[INFO] Executing tasks
main:
[echo] ******** Displaying value of property ********
[echo] 0-0-1-snapshot
...
gcloud.cmd app deploy --version ${project.version.urlsafe}-urlsafe
[INFO] GCLOUD: ERROR: (gcloud.app.deploy) argument --version/-v: Bad value [${project.version.urlsafe}-urlsafe]
Even if the ant-run plugin properly echoed the new version, when the deploy command is built, the variable itself is missing.
I then tried forcing the regex-property goal before the deploy, like follows
mvn build-helper:regex-property appengine:deploy
but I'm getting a missing configuration error in this case:
[ERROR] Failed to execute goal org.codehaus.mojo:build-helper-maven-plugin:3.0.0:regex-property (default-cli) on project maventest: The parameters 'regex', 'name', 'value' for goal org.codehaus.mojo:build-helper-maven-plugin:3.0.0:regex-property are missing or invalid -> [Help 1]
A little digression:
I decided to manually run the build-helper:regex-property as additional goal due to a previous experience with a similar a case: a plugin that inject a new variable, which is properly echoed but when it comes to use the value, is missing. Here is the reference: Unable to obtaing git.branch property
Cooperating with the plugin author we found that adding the plugin goal before the appengine one can solve the issue mvn git-commit-id:revision appengine:deploy. At the end the root cause of this problem was a Maven bug: https://issues.apache.org/jira/browse/MNG-6260
So even the workaround of directly calling the plugin is not suitable in this case due to a plugin configuration error.
How can issue can be solved? How can I obtain the ${project.version.urlsafe} variable properly created when executing the appengine deploy?
I had the same problem using the appengine-maven-plugin. And you're right, you need to first call the goal build-helper:regex-property before deploying on app engine.
But to make this work, you have to move the configuration part outside the executions tag.
Here is the complete configuration I am currently using:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>3.0.0</version>
<configuration>
<name>project.version.urlsafe</name>
<value>${project.version}</value>
<regex>\.</regex>
<replacement>-</replacement>
<toLowerCase>true</toLowerCase>
<failIfNoMatch>false</failIfNoMatch>
<fileSet/>
<source/>
</configuration>
</plugin>
Then when calling mvn build-helper:regex-property appengine:deploy, everything should work as expected.
Related
I use Maven to manage my Java projects build but sometimes I have projects written in C or C++ langage and I would like to use Maven too so it will be easier to manage those projects.
It seems the nar-maven-plugin should do the job. I tried to create an HelloWorld project just to test it. I thought it will be really simple as it is generally with Maven.
My pom.xml
<project
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.sample</groupId>
<artifactId>helloworld-cplusplus-sample</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>nar</packaging>
<name>Helloworld</name>
<build>
<plugins>
<plugin>
<groupId>com.github.maven-nar</groupId>
<artifactId>nar-maven-plugin</artifactId>
<version>3.2.3</version>
<configuration>
<libraries>
<library>
<type>executable</type>
</library>
</libraries>
</configuration>
</plugin>
</plugins>
</build>
</project>
And i have the following error
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[ERROR] Unknown packaging: nar # line 7, column 14
#
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR] The project com.sample:helloworld-cplusplus-sample:0.0.1-SNAPSHOT (D:\local\workspaces\TEST\HelloWorl
dMaven\pom.xml) has 1 error
[ERROR] Unknown packaging: nar # line 7, column 14
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
I'm using Maven 3.3.1.
I forced the download of nar-maven-plugin in my local repository using "mvn dependency:get ..." but it doesn't change anything.
When a plugin adds a new packaging type, you must add <extensions>true</extensions> to its definition:
<plugin>
<groupId>com.github.maven-nar</groupId>
<artifactId>nar-maven-plugin</artifactId>
<version>3.2.3</version>
<extensions>true</extensions> <!-- This needs to be present for a new packaging -->
<configuration>
<libraries>
<library>
<type>executable</type>
</library>
</libraries>
</configuration>
</plugin>
As already answered, ;)
link.exe is part of Microsoft Visual Studio, which is what NAR
typically uses under the hood to compile C++ code on Windows.
Try with
<linker>
<name>g++</name>
</linker>
in your nar plugin configuration if you have MinGW or something other than MSVS.
This is the base class of our unit tests:
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration("/spring/test-context.xml")
public abstract class BaseUnitTest {}
All unit tests extend this class.
When I run the tests locally in eclipse (using Run As > Unit Test) , the tests run in about 5 seconds since the same context is shared by all tests and it is loaded only once.
However, when I run them using the mvn test target it takes about 5 minutes. After looking at the logs, I see that the application context is being loaded for every test.
It takes the same time (5 mins) when we run it on our Jenkins CI server.
Not sure what's going on. In spring docs, it states that the appContext should be reused even with maven, but thats not the case here.
Any help would be appreciated.
UPDATE :
I ran mvn with debug flags on and I see that a new JVM is spawned for each test:
Forking command line: cmd.exe /X /C "java -Xverify:none -jar S:\git\picaxo21\picaxo\picaxoService\target\surefire\surefirebooter8169952914558366417.jar S:\git\picaxo21\picaxo\picaxoService\target\surefire\surefire8550033206398936560tmp S:\git\picaxo21\picaxo\picaxoService\target\surefire\surefire_05655453605766528120tmp"
Forking command line: cmd.exe /X /C "java -Xverify:none -jar S:\git\picaxo21\picaxo\picaxoService\target\surefire\surefirebooter4002024477779069323.jar S:\git\picaxo21\picaxo\picaxoService\target\surefire\surefire6735432532690834115tmp S:\git\picaxo21\picaxo\picaxoService\target\surefire\surefire_17783676008756503456tmp"
Forking command line: cmd.exe /X /C "java -Xverify:none -jar S:\git\picaxo21\picaxo\picaxoService\target\surefire\ 7874269889863176184.jar S:\git\picaxo21\picaxo\picaxoService\target\surefire\surefire2050758518148174678tmp S:\git\picaxo21\picaxo\picaxoService\target\surefire\surefire_27591156970671336255tmp"
I am using forkCount=1 and reuseForks=true so I am not sure why this is happening. any clues?
Parent POM :
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
.....
</parent>
<groupId>...</groupId>
<artifactId>picaxo</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
<name>.....</name>
<description>Build All Modules</description>
<modules>
<module>picaxoService</module>
</modules>
<scm>
....
</scm>
<properties>
<pmd.include.tests>true</pmd.include.tests>
<findbugs.plugin.version>3.0.0</findbugs.plugin.version>
<fb.threshold>Low</fb.threshold>
<fb.includeTests>true</fb.includeTests>
<fb.effort>Max</fb.effort>
<fb.failOnError>false</fb.failOnError>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<skipTests>true</skipTests>
</properties>
<build>
<plugins>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<testFailureIgnore>true</testFailureIgnore>
<skipTests>${skipTests}</skipTests>
<reuseForks>true</reuseForks>
<forkCount>1</forkCount>
<excludes>
<exclude>**/*IntegrationTest.java</exclude>
</excludes>
</configuration>
<executions>
<execution>
<id>integration-test</id>
<goals>
<goal>test</goal>
</goals>
<phase>integration-test</phase>
<configuration>
<excludes>
<exclude>none</exclude>
</excludes>
<includes>
<include>**/*IntegrationTest.java</include>
</includes>
</configuration>
</execution>
</executions>
</plugin>
</build>
Found the problem.
Apparently forkMode for surefire plugin was defaulting to pertest hence was spawning a new JVM for each test. Explicitly Setting it to once in the plugin configuration solved the issue.
When I using the follow structure on our Maven project:
<plugins>
<plugin>
<groupId>org.scala-tools</groupId>
<artifactId>maven-scala-plugin</artifactId>
<version>2.15.2</version>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>testCompile</goal>
</goals>
</execution>
</executions>
<configuration>
<args>
<arg>-g:line</arg>
</args>
</configuration>
</plugin>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.5.8.201207111220</version>
<executions>
<execution>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>report</id>
<phase>prepare-package</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
The tests are executed but the jacoco.exec file is not created. I tried to add this tag destFile to prepare-agent goal but have not success (the file with coverage information is not created).
Anyone have any form to calculate code coverage of unit test for Scala using maven and Jacoco?
Work of Jacoco maven plugin depends on versions of JDK, Scala and plugin itself.
Just added the same config and it works properly: both jacoco.exec and site/jacoco with reports are in the target dir: https://github.com/plokhotnyuk/calculator/commit/e3a84db02dd942b0df71d4fa337df29512e213f6
Then got agent failure when using latest (0.6.2.201302030002) version of Jacoco maven plugin:
Caused by: java.lang.RuntimeException: Class java/util/UUID could not be instrumented.
at org.jacoco.agent.rt.internal_5d10cad.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:138)
at org.jacoco.agent.rt.internal_5d10cad.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:99)
at org.jacoco.agent.rt.internal_5d10cad.PreMain.createRuntime(PreMain.java:51)
at org.jacoco.agent.rt.internal_5d10cad.PreMain.premain(PreMain.java:43)
... 6 more
Caused by: java.lang.NoSuchFieldException: $jacocoAccess
at java.lang.Class.getField(Class.java:1542)
at org.jacoco.agent.rt.internal_5d10cad.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:136)
... 9 more
FATAL ERROR in native method: processing of -javaagent failed
Exception in thread "main"
And then the failure was worked out by switching from JDK8 to JDK7. Coverage report digits didn't changed.
Also after switching to Scala 2.10 source line highlighting started looks different:
Scala 2.9
Scala 2.10
Hoping for some feedback on this issue that has been troubling for a while.
I use maven for building a simple web services client application.
It uses several wsdls ( around 8 ) the wsdls have xsd imports ( roughly 2 per wsdl for each request and response, plus a good amount of additional imports ) to generate the java code using a maven cxf wsdl2java plugin.
I started with the plugin version 2.1.7 tried several 2.2.x and now trying with version 2.3.4 of the plugin.
Here is the plugin section of my pom file:
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>2.3.4</version>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<configuration>
<defaultOptions>
<noAddressBinding>true</noAddressBinding>
</defaultOptions>
<wsdlRoot>${basedir}/src/main/resources/wsdl</wsdlRoot>
<includes>
<include>*.wsdl</include>
</includes>
</configuration>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
I can provide a previous version of how this used to work for me in the past. Basically I had each individual wsdl listed as a < wsdloption > item.
The only thing that I did "environment" related was that for a separate project I deleted everything in my m2 folder. Since then doing the code generation gives me the following error message( using "mvn -e generate-sources" from the command ):
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to generate types.
[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to generate types.
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:584)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:301)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to generate types.
at org.apache.cxf.maven_plugin.WSDL2JavaMojo.callWsdl2Java(WSDL2JavaMojo.java:413)
at org.apache.cxf.maven_plugin.WSDL2JavaMojo.execute(WSDL2JavaMojo.java:362)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
... 16 more
Caused by: org.apache.cxf.tools.common.ToolException: Failed to generate types.
at org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.generate(JAXBDataBinding.java:745)
at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.generateTypes(WSDLToJavaContainer.java:599)
at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:247)
at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:138)
at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:290)
at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:103)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86)
at org.apache.cxf.maven_plugin.WSDL2JavaMojo.callWsdl2Java(WSDL2JavaMojo.java:410)
... 19 more
One thing that I've noticed is that in the target/generated-sources folder it creates the same classes in the \generated-sources\cxf\generated AND \generated-sources\org\opentravel\ota_2003_05. Not exactly sure if there is an error in the XSDs or the wsdl themselves.
I have looked for a good explanation of the error and haven't found a solution yet. I have done my fair share of "googling" for this particular issue. Starting to get desperate and hope I can find a solution soon.
Thanks in advance for any help you can provide.
I see this from time to time, when I am using the cxf java plugin, I think the cxf.maven.wsdl2javaMojo run out of memory.
in this case,
I would recommend you to break the each wsdl generation into sub-modules,
increase the maven memory
if it still stops at the middle try to using the mvn Goals -rf :WhereStops command, so it starts at the sub-module which run out memory, thus you don't have to start all over again.
Note I use Maven 3.2
if you not sure how -rf works google mvn -rf
Not really sure. I just looked at the code at that line number and, unfortunately, just discovered that it's completely swallowing an IOException at that point. Thus, I have no idea how to get the real "cause" of that IOException. I'm going to fix that and get it committed to trunk. If you could retry with the latest snapshots tomorrow or monday (after the nightly deploy builds), it should likely provide a much better/complete error message.
I'm trying to use Hyperjaxb3 with Apache CXF to generate persistence annotations from a WSDL-first web service. I've plugged the Hyperjaxb3-ejb-plugin into the cxf-codegen-plugin, like so.
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>${cxf.version}</version>
<dependencies>
<dependency>
<groupId>org.jvnet.jaxb2_commons</groupId>
<artifactId>jaxb2-basics</artifactId>
<version>0.5.2</version>
</dependency>
<dependency>
<groupId>org.jvnet.hyperjaxb3</groupId>
<artifactId>hyperjaxb3-ejb-plugin</artifactId>
<version>0.5.4</version>
</dependency>
</dependencies>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<configuration>
<sourceRoot>${project.build.directory}/generated/cxf</sourceRoot>
<wsdlOptions>
<wsdlOption>
<wsdl>${basedir}/src/main/resources/wsdl/CDXLEAToCourt.wsdl</wsdl>
<xjcargs>
<xjcarg>-Xequals</xjcarg>
<xjcarg>-XtoString</xjcarg>
<xjcarg>-Xhyperjaxb3-ejb</xjcarg>
</xjcargs>
</wsdlOption>
</wsdlOptions>
</configuration>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
</executions>
</plugin>
When I generate source, I get the following informative stack trace.
Failed to execute goal org.apache.cxf:cxf-codegen-plugin:2.2.7:wsdl2java (generate-sources) on project leaToCourtWS: Failed to generate types. -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.cxf:cxf-codegen-plugin:2.2.7:wsdl2java (generate-sources) on project leaToCourtWS: Failed to generate types.
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:585)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:324)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:247)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:104)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:427)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:157)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:121)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to generate types.
at org.apache.cxf.maven_plugin.WSDL2JavaMojo.callWsdl2Java(WSDL2JavaMojo.java:409)
at org.apache.cxf.maven_plugin.WSDL2JavaMojo.execute(WSDL2JavaMojo.java:361)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:577)
... 14 more
Caused by: org.apache.cxf.tools.common.ToolException: Failed to generate types.
at org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.generate(JAXBDataBinding.java:716)
at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.generateTypes(WSDLToJavaContainer.java:582)
at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:228)
at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:128)
at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:271)
at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:103)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86)
at org.apache.cxf.maven_plugin.WSDL2JavaMojo.callWsdl2Java(WSDL2JavaMojo.java:406)
... 17 more
I've been banging my head against this for a while. I tried to continue the project without Hyperjaxb, but don't want to incur the maintenance costs. Any ideas? A solution to the exception- or an alternative to using Hyperjaxb- would be great.
Found a solution. I emailed Aleksei - the project owner- and he informed me that Hyperjaxb3 CXF integration was introduced in .5.5, which has yet to be released. D'oh!
He suggested I use the snapshot repository. I added the repository to my POM, changed the version of the hyperjaxb3-ejb-plugin to 0.5.5-SNAPSHOT- and so far, everything works beautifully.
It seems the problem comes from your WSDL file.
There is a working example within the source code of Hyperjaxb3 called customerservice-cxf that might help you.