I have a maven project where java stubs are generated from wsdl files using axistools-maven-plugin.
Within pom we have following:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>axistools-maven-plugin</artifactId>
<version>${axistools-maven-plugin.version}</version>
<configuration>
<mappings>
<mapping>
<namespace>xyz</namespace>
<targetPackage>x.y.z</targetPackage>
</mapping>
<mapping>
<namespace>http://time.joda.org</namespace>
<targetPackage>com.org.joda.time</targetPackage>
</mapping>
<mapping>
<namespace>abc</namespace>
<targetPackage>a.b.c</targetPackage>
</mapping>
</mappings>
<testCases>false</testCases>
<serverSide>false</serverSide>
<subPackageByFileName>true</subPackageByFileName>
</configuration>
<executions>
<execution>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
</executions>
</plugin>
Now in above setting we just have namespaces mapped to package. I am just not able to get how this setting is able to track where does wsdl reside in order generate stubs?
Maven documentation is not very clear on this. Any ideas on this?
EDIT:
I did some testing on this:
I removed all the mappings of namespaces and packages but still wsdl gets picked up.
Even if i change the wsdl name, it still gets picked up.
This is very surprising to me, it seems axis plugin knows about wsdl location. but how i dont knw.
So finally i solved the mystery.
I ran maven build in debug mode : mvn -X clean insatll
I noticed that maven-axistools-plugin checks the default directory as ${basedir}/src/main/wsdl to search for wsdl and hence it was always able to locate my wsdls.
Related
I'm trying to revive a legacy project for my client. The project is pretty old and it uses the jaxb2-maven-plugin to generate some java classes from an xsd schema file.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxb2-maven-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<goals>
<goal>xjc</goal>
</goals>
</execution>
</executions>
<configuration>
<sources>
<source>src/main/resources/custom-api.xsd</source>
</sources>
<packageName>com.client</packageName>
<catalog>src/main/resources/catalog.cat</catalog>
</configuration>
</plugin>
The problem is the company doesn't allow any internet access - hence when I generate the code I get errors such as java.net.UnknownHostException saying that it cannot find www.springframework.org.
So I understand that the solution for this problem is to provide the xsd files locally - which I did, extracting them in a folder named import and I created also a catalog.cat file to rewrite the access to those xsd files to the import folder.
The catalog.cat file looks like this:
REWRITE_SYSTEM "http://www.springframework.org/schema/beans/spring-beans-3.1.xsd" "import/spring-beans-3.1.xsd"
REWRITE_SYSTEM "http://www.mulesoft.org/schema/mule/core/3.4/mule.xsd" "import/mule.xsd"
REWRITE_SYSTEM "http://www.mulesoft.org/schema/mule/schemadoc/3.4/mule-schemadoc.xsd" "import/mule-schemadoc.xsd"
REWRITE_SYSTEM "http://www.mulesoft.org/schema/mule/jms/current/mule-jms.xsd" "import/mule-jms.xsd"
REWRITE_SYSTEM "http://www.springframework.org/schema/context/spring-context-3.1.xsd" "import/spring-context-3.1.xsd"
REWRITE_SYSTEM "http://www.springframework.org/schema/tool/spring-tool-3.1.xsd" "import/spring-tool-3.1.xsd"
Unfortunately I get some conflicts in spring-beans.xsd:
com.sun.istack.SAXParseException2publicId: http://www.springframework.org/schema/beans; systemId: http://www.springframework.org/schema/beans/spring-beans-3.1.xsd; lineNumber: 566; columnNumber: 30; Property "Ref" is already defined. Use <jaxb:property> to resolve this conflict.
at com.sun.tools.xjc.ErrorReceiver.error(ErrorReceiver.java:56)
I suspect that this happens because the xsd is loaded multiple times - probably being referenced by other xsd files. The usual way to get rid of such conflicts is to use a binding file, but I don't think this is the right thing to do considering that this is a third party xsd file.
An example of a sample project has been provided here: https://github.com/scutaru/sample-xjc
Anybody knows how I can get rid of these conflicts ?
The EU VIES VAT validation from WSDL is not working when running via java code. But the same is working from some soap API testing tools.
Eg, https://wsdlbrowser.com/soapclient?wsdl_url=https%3A%2F%2Fec.europa.eu%2Ftaxation_customs%2Fvies%2FcheckVatService.wsdl and https://app.boomerangapi.com/?ext
Even its not working when I trid to get source code from wsimport. (C:\Program Files\Java\jdk1.8.0_151\bin>wsimport -keep -verbose http://ec.europa.eu/taxation_customs/vies/checkVatService.wsdl)
Error is “The element type "BR" must be terminated by the matching end-tag "".” The same error is coming when trying to access SOAP service via java code.
Any suggestions on how to use this EU wsdl for validating VAT nos?
Solved this using 'JAX-WS' Maven plugin to parse a WSDL file to generate java classes.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<version>1.12</version>
<execution>
<id>wsimportb-from-jdk</id>
<goals>
<goal>wsimport</goal>
</goals>
<configuration>
<wsdlUrls>
<wsdlUrl>
https://ec.europa.eu/taxation_customs/vies/checkVatService.wsdl
</wsdlUrl>
</wsdlUrls>
<keep>true</keep>
<packageName>com.vies</packageName>
<sourceDestDir>target/generatedclasses</sourceDestDir>
</configuration>
</execution>
Then export your com.vies custom package under maven <Export-Package>
Change protocol http:// to https:// in the WSDL URL
I have a Maven project with 3 modules: schema, gml and adress. schema contains two XSDs: gmlprofil-1.1.xsd - a simple GML profile and adress.xsd which imports the GML schema using a relative schemaLocation, like so:
<import schemaLocation="../gml/gmlprofil-1.1.xsd" namespace="http://www.opengis.net/gml/3.2"/>
In both the gml module and the adress module, I use maven-jaxb2-plugin with jaxb2-basics in order to generate classes with equals() and hashCode(). The gml module works fine, but when running adress, I get this error:
com.sun.istack.SAXParseException2; IOException thrown when processing "../gml/gmlprofil-1.1.xsd". Exception: java.io.FileNotFoundException: C:\code\gml\gmlprofil-1.1.xsd
Fine. A catalog file to the rescue!
REWRITE_SYSTEM "../gml/gmlprofil-1.1.xsd" "maven:com.test:schema:jar::!/com/test/schemas/gml/gmlprofil-1.1.xsd"
It looks like the absolute path is resolved OK, but then a MalformedURLException occurs.
[DEBUG] Parent resolver has resolved publicId [null], systemId [../gml/gmlprofil-1.1.xsd] to [maven:com.test:schema:jar::!/com/test/schemas/gml/gmlprofil-1.1.xsd].
[DEBUG] Resolving systemId [maven:com.test:schema:jar::!/com/test/schemas/gml/gmlprofil-1.1.xsd] as Maven dependency resource.
[DEBUG] Resolved dependency resource [Dependency {groupId=com.test, artifactId=schema, version=1.0-SNAPSHOT, type=jar, classifier=null, resource=com/test/schemas/gml/gmlprofil-1.1.xsd}] to resource URL [jar:file:/C:/code/jaxb-test/schema/target/schema-1.0-SNAPSHOT.jar!/com/test/schemas/gml/gmlprofil-1.1.xsd].
[DEBUG] Resolved systemId [maven:com.test:schema:jar::!/com/test/schemas/gml/gmlprofil-1.1.xsd] to [jar:file:/C:/code/jaxb-test/schema/target/schema-1.0-SNAPSHOT.jar!/com/test/schemas/gml/gmlprofil-1.1.xsd].
[ERROR] Error while parsing schema(s).Location [ maven:com.test:schema:jar::!/com/test/schemas/adress/adress.xsd{8,97}].
org.xml.sax.SAXParseException; systemId: maven:com.test:schema:jar::!/com/test/schemas/adress/adress.xsd; lineNumber: 8; columnNumber: 97; unknown protocol: maven
...
Caused by: java.net.MalformedURLException: unknown protocol: maven
This is my pom for adress:
<plugin>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
<version>0.13.0</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
<configuration>
<bindingDirectory>src/main/resources</bindingDirectory>
<episode>true</episode>
<useDependenciesAsEpisodes>true</useDependenciesAsEpisodes>
<extension>true</extension>
<forceRegenerate>false</forceRegenerate>
<schemaLanguage>XMLSCHEMA</schemaLanguage>
<strict>false</strict>
<verbose>false</verbose>
<catalog>src/main/resources/catalog.cat</catalog>
<args>
<arg>-npa</arg>
<arg>-XsimpleEquals</arg>
<arg>-XsimpleHashCode</arg>
</args>
<plugins>
<plugin>
<groupId>org.jvnet.jaxb2_commons</groupId>
<artifactId>jaxb2-basics</artifactId>
<version>0.9.5</version>
</plugin>
</plugins>
<schemas>
<schema>
<dependencyResource>
<groupId>com.test</groupId>
<artifactId>schema</artifactId>
<resource>com/test/schemas/adress/adress.xsd</resource>
</dependencyResource>
</schema>
</schemas>
</configuration>
</plugin>
I have tried some solutions:
Setting the Maven URL as the schemaLocation:
<import schemaLocation="maven:com.test:schema:jar::!/com/test/schemas/gml/gmlprofil-1.1.xsd" namespace="http://www.opengis.net/gml/3.2"/>
Setting an absolute schemaLocation and updating the catalog file accordingly:
<import schemaLocation="http://test.com/schemas/gml/gmlprofil-1.1.xsd" namespace="http://www.opengis.net/gml/3.2"/>
REWRITE_SYSTEM "http://test.com/schemas" "maven:com.test:schema:jar::!/com/test/schemas"
Lowering the maven-jaxb2-plugin version to 0.9.1. Using this method, I don't even need a catalog file, however I get this error instead:
[ERROR] Failed to execute goal org.jvnet.jaxb2.maven2:maven-jaxb2-plugin:0.9.1:generate (default) on project adress: Execution default of goal org.jvnet.jaxb2.maven2:maven-jaxb2-plugin:0.9.1:generate failed: A required class was missing while executing org.jvnet.jaxb2.maven2:maven-jaxb2-plugin:0.9.1:generate: com/sun/tools/xjc/model/Aspect
This can be resolved by swapping in -Xequals and -XhashCode instead of -XsimpleEquals and -XsimpleHashCode.
All three solutions work, but none is perfect. The first two require manipulating the schema, while the third introduces an unwanted dependency on jaxb2-basics-runtime in the generated classes. The latter is acceptable but I would greatly appreciate it if anyone knows how to run simpleEquals with my setup.
Well, welcome to my world of pain.
You're surely aware of the ogc-schema project, right?
The interesting part is actually that catalog even seems to resolved correctly. Not sure what's happening there but here's the solution I've finally found out to work best:
Compile the absolute URL:
<schemas>
<schema>
<url>http://test.com/schemas/adres/adres.xsd</url>
</schema>
</schemas>
Use a catalog to rewrite
REWRITE_SYSTEM "http://test.com/schemas" "maven:com.test:schema:jar::!/com/test/schemas"
This is basicallyyour third solution but you don't have to change the schema. Just start from an absolute URL, it will be rewritten by the catalog.
Ah, yes:
DISCLAIMER I'm the author of maven-jaxb2-plugin, jaxb2-basics as well as the ogc-schema project mentioned above.
By the way, what's so bad about the jaxb2-basics-runtime dependency?
I have a problem related to installing a UIMA PEAR package containing an Annotator component. I am using PearPackageMavenPlugin for the job with the following setup:
<plugin>
<groupId>org.apache.uima</groupId>
<artifactId>PearPackagingMavenPlugin</artifactId>
<version>2.6.0</version>
<extensions>true</extensions>
<executions>
<execution>
<phase>package</phase>
<configuration>
<!-- PEAR file component classpath settings -->
<classpath>$main_root/bin</classpath>
<!-- PEAR file main component descriptor -->
<mainComponentDesc>desc/S4DocumentUimaAnnotator.xml</mainComponentDesc>
<!-- PEAR file component ID -->
<componentId>S4DocumentAnnotator</componentId>
<!-- PEAR file UIMA datapath settings -->
<datapath>$main_root/resources</datapath>
</configuration>
<goals>
<goal>package</goal>
</goals>
</execution>
</executions>
</plugin>
`
I have constructed a special maven profile building the project in a bin directory instead of target so all my compiled classes are there that is why I have pointed the classpath setting of the plugin at $main_root/bin.
Finally when I load the built pear package I get the following error:
Verification of S4DocumentAnnotator failed =>
org.apache.uima.resource.ResourceInitializationException: The class com.ontotext.s4.api.components.uima.S4DocumentUimaAnnotator is not a valid Analysis Component. You must specify an Annotator, CAS Consumer, Collection Reader, or CAS Multiplier. If you are calling ResourceManager.setExtensionClassPath, this error can also be caused if you have put UIMA framework jar files on the extension classpath, which is not allowed. (Descriptor: file:/home/ceco/s4_stuff/my_pear/S4DocumentAnnotator/desc/S4DocumentUimaAnnotator.xml)
at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.initializeAnalysisComponent(PrimitiveAnalysisEngine_impl.java:228)
at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.initialize(PrimitiveAnalysisEngine_impl.java:170)
at org.apache.uima.impl.AnalysisEngineFactory_impl.produceResource(AnalysisEngineFactory_impl.java:94)
at org.apache.uima.impl.CompositeResourceFactory_impl.produceResource(CompositeResourceFactory_impl.java:62)
at org.apache.uima.UIMAFramework.produceResource(UIMAFramework.java:279)
at org.apache.uima.UIMAFramework.produceResource(UIMAFramework.java:331)
at org.apache.uima.UIMAFramework.produceAnalysisEngine(UIMAFramework.java:448)
at org.apache.uima.pear.tools.InstallationTester.testAnalysisEngine(InstallationTester.java:218)
at org.apache.uima.pear.tools.InstallationTester.doTest(InstallationTester.java:113)
at org.apache.uima.pear.tools.InstallationController.verifyComponentInstallation(InstallationController.java:1110)
at org.apache.uima.pear.tools.InstallationController.verifyComponent(InstallationController.java:1993)
at org.apache.uima.tools.pear.install.InstallPear.installPear(InstallPear.java:389)
at org.apache.uima.tools.pear.install.InstallPear.access$000(InstallPear.java:80)
at org.apache.uima.tools.pear.install.InstallPear$RunInstallation.run(InstallPear.java:109)
at java.lang.Thread.run(Thread.java:744)
I do not understand why the UIMA jars are not supposed to be packaged when the idea of the PEAR package is to be self-contained and not depend on the system it is ran on?
This is what I would try:
The class com.ontotext.s4.api.components.uima.S4DocumentUimaAnnotator is not a valid Analysis Component
Check that S4DocumentUimaAnnotator is valid. Unzip the PEAR and check the xml.
If you are calling ResourceManager.setExtensionClassPath, this error can also be caused if you have put UIMA framework jar files on the extension classpath, which is not allowed.
Did you try to print the extension classpath?
Else you could try to use a plain java version of the PEAR, meaning: manually unzip it and create a normal java project with it.
One common issue I ran into several times and which creates exactly this error message is that my PEAR contains uimaj-common.jar in the lib folder. Have you checked this?
I know this one is old but what I think you should do is set the scope of the uima dependencies to provided. The PEAR needs only it's dependencies to run, the enviroment it'll be used should have the uima dependencies set to use all the uima features and pears
Provided dependencies won't be copied to the lib folder of the PEAR
There are a couple of things that could be going on, but going by your error message, the first thing I would determine is whether or not the uimaj-core jar file is being excluded from the build of the PEAR file. It should be. (Take a look at the error message above.) I just ran into this problem myself, and I got around it by adding this to my POM:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<!-- Copy the dependencies to the lib folder for the PEAR to copy. -->
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<stripVersion>true</stripVersion>
<outputDirectory>${basedir}/lib</outputDirectory>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>true</overWriteSnapshots>
<includeScope>runtime</includeScope>
<!-- An exception happens when using a PEAR if the archive includes this jar. -->
<excludeArtifactIds>uimaj-core</excludeArtifactIds>
</configuration>
</execution>
</executions>
</plugin>
I recently posted a parent POM file and a project-specific POM file to my Gist. You're welcome to take a look at what I'm doing. (One of the things I'm doing is copying over my desc directory, which contains my AE's descriptor XML file, to the root of my project directory, so that the maven-pear plugin can copy it into the PEAR archive properly.)
Parent POM:
https://gist.github.com/software-mariodiana/d46e10fca53dc6e6c0f16e20563476b8
Project-specific POM:
https://gist.github.com/software-mariodiana/e9a0f0f03a49d33dcc32655170fd4841
Good luck!
Our project uses XJC to generate Java classes from an XSD. I'm using JAVA EE 6.
When all the XSDs we have are re-generated, the generated classes include this comment at the top of the file:
// Generated on: 2011.02.23 at 02:17:06 PM GMT
Is it possible to suppress this comment? The reason is that we use SVN for version control, and every time we regenerate our classes, every single file shows as being changed in SVN, even though the only thing that differs is this comment. So I'd like to remove the comment altogether if possible.
There is a -no-header directive, but I don't want to remove the entire header, so that future generations know that it's a file generated from a tool, and that modifications will be overwritten. I only want to remove the timestamp. (Or alternatively, I'd remove the inbuilt header and then insert my own header somehow.)
I am using this Maven plugin which replaces the // Generated on: 2011.02.23 at 02:17:06 PM GMT line:
<plugin>
<groupId>com.google.code.maven-replacer-plugin</groupId>
<artifactId>maven-replacer-plugin</artifactId>
<version>1.3.8</version>
<executions>
<execution>
<phase>prepare-package</phase>
<goals>
<goal>replace</goal>
</goals>
</execution>
</executions>
<configuration>
<includes>
<include>src/main/java/jaxb/*.java</include>
</includes>
<token>^// Generated on.*$</token>
<value>// Generated on: [TEXT REMOVED by maven-replacer-plugin]</value>
<regexFlags>
<regexFlag>MULTILINE</regexFlag>
</regexFlags>
</configuration>
</plugin>
I'm late to the party, but since version 2.0 of the jaxb2-maven-plugin, there's a noGeneratedHeaderComments configuration option. (see the JAXB-2 Maven Plugin Docs)
You can use it like this:
...
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxb2-maven-plugin</artifactId>
<version>2.3.1</version>
<executions>
<execution>
<id>xjc</id>
<goals>
<goal>xjc</goal>
</goals>
</execution>
</executions>
<configuration>
<target>2.1</target>
<sources>
<source>FirstXSD.xsd</source>
<source>SecondXSD.xsd</source>
</sources>
<xjbSources>
<xjbSource>OptionalBindings.xjb</xjbSource>
</xjbSources>
<noGeneratedHeaderComments>true</noGeneratedHeaderComments>
</configuration>
<dependencies>
<dependency>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-xjc</artifactId>
<version>${jaxb.version}</version>
</dependency>
</dependencies>
</plugin>
</plugins>
...
So no need for another plugin or script to run.
If you want to keep a disclaimer, you can use one of the techniques already mentioned to inject it where wanted.
If you use ant, the following snippet may be useful for replacing the comments:
<replaceregexp
match="^// Generated on:.*$"
replace="// Generated on: [date removed]"
byline="true">
<fileset dir="src">
<include name="**/*.java"/>
</fileset>
</replaceregexp>
I know this is 2 years after the fact, but because the classes are generated they aren't necessarily needed in SVN. What needs to be in SVN is the schema or whatever file you use for source to generate the classes. As long as you have the source and the tools to generate the classes, the classes in SVN are redundant and as you saw, problematic in SVN or any SCCS. So put the schema file in SVN and avoid the issue altogether.
If it's not possible using an option you can post-process the generated files yourself.
For a very specific use-case we had to do it that way on our project...
We use Maven and we execute a specific script after the Java classes have been generated and before we compile and package them to a distriuable JAR.
To build on cata's answer (upvoted) the maven-replacer-plugin is the way to go. I've come up with the following that strips out the entire comment (not just the timestamp) which you can replace with your file comment (license etc.).
<plugin>
<groupId>com.google.code.maven-replacer-plugin</groupId>
<artifactId>maven-replacer-plugin</artifactId>
<executions>
<execution>
<phase>prepare-package</phase>
<goals>
<goal>replace</goal>
</goals>
</execution>
</executions>
<configuration>
<!-- assumes your xjc is putting source code here -->
<includes>
<include>src/main/java/**/*.java</include>
</includes>
<regex>true</regex>
<regexFlags>
<regexFlag>MULTILINE</regexFlag>
</regexFlags>
<replacements>
<replacement>
<token>(^//.*\u000a|^\u000a)*^package</token>
<value>// your new comment
package</value>
</replacement>
</replacements>
</configuration>
</plugin>
The one gotcha to watch out for is that the <value> element treats the text literally. So if you want a line break in your replacement text you need to put a line break in your pom.xml file (as I've demonstrated above).
What you should you :
Generate your classes in target :
${project.build.directory}/generated-sources
If you add target to ignore list (svn), that's all.
I also want to have text header with warning about classes was auto-generated and should not be modified manually, but because I place such files into git I do not want there always changed date of generation.
That header generated in com.sun.tools.xjc.Options#getPrologComment method. So essentially it call:
return Messages.format(
Messages.FILE_PROLOG_COMMENT,
dateFormat.format(new Date()));
Messages.FILE_PROLOG_COMMENT defined as Driver.FilePrologComment. With futher debugging I found it use standard Java localization bundles.
So, to change header format we just may provide our properties override for their values from MessageBundle.properties.
We can do it in two way:
Just copy that file (from repo by link, or just from jar of appropriate version what you are using) into src/main/resources/com/sun/tools/xjc/MessageBundle.properties in your project and change key Driver.FilePrologComment as you wish.
But first case have some drawbacks - first you copy-paste many code which you do not change, second you should update it when you update XJC dependency. So better I recommend place it as src/main/resources/com/sun/tools/xjc/MessageBundle_en.properties (note _en suffix in filename) file and place there only properties you really want to change. Something like:
# We want header, but do NOT willing there `Generated on: {0}` part because want commit them into git!
Driver.FilePrologComment = \
This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, v2.4.0-b180830.0438 \n\
See https://javaee.github.io/jaxb-v2/ \n\
Any modifications to this file will be lost upon recompilation of the source schema. \n
Ensure that file in compiler classpath, especially if you call it from some plugins.
That is common mechanism for translation. See related answer: JAXB english comments in generated file
If you are using maven-jaxb2-plugin there is an tag noFileHeader set it to true. It will prevent jaxb to generate the header that includes that date line on it.
<noFileHeader>true</noFileHeader>