I am hoping someone has experienced this issue and can maybe shed some light.
I have an xml schema and an ant build file. The output .java files differ when I run ant on Windows versus Mac, even if I am using the same jaxb-xjc.jar to do the xml-compiling. The Windows side is naming the "getter" methods for attributes as "getX". The Mac side wants to name them "isX". Anyone experience anything like this before and/or have a solution? This is consistent between Windows Vista & 7 doing this the one way and Mac OSX 10.6 & 10.7 (untested on Mac OSX 10.8) doing it the other.
----edit----
I'll attach some of the code from the ant build.xml file.
Telling it what the xjc is.
<taskdef name="xjc" classname="com.sun.tools.xjc.XJCTask">
<classpath refid="classpath"/>
</taskdef>
Here is the 'actual' compiling:
Compiling the automaton schema
<echo>Compiling old automaton schema</echo>
<xjc schema="${oldxml-schema}" destdir="${src.dir}" package="${oldxml.package}">
<produces dir="${oldxml-gen.dir}" includes="**/*.java"/>
</xjc>
<echo>Compiling the plugin schema</echo>
<mkdir dir="${plugin-gen.dir}" />
<xjc schema="${plugin-schema}" destdir="${src.dir}" package="${plugin.package}">
<produces dir="${plugin-gen.dir}" includes="**/*.java"/>
</xjc>
<echo>Compiling the pluginDesumaSide schema</echo>
<mkdir dir="${pluginDesumaSide-gen.dir}" />
<xjc schema="${pluginDesumaSide-schema}" destdir="${src.dir}" package="${pluginDesumaSide.package}">
<produces dir="${pluginDesumaSide-gen.dir}" includes="**/*.java"/>
</xjc>
</target>
All targets (by that I mean anything mentioned like ${}) are defined and every links and compiles right except for Mac naming the 'getter' methods as 'is' methods for variables. They are boolean attributes that do have defaults if non-specified.
From the responses I got I was able to google for a solution. Apparently this naming inconsistency and another (a getter returning a primitive but the setter only accepting objects) was apparent by chance for older xml-compilers due to some inconsistency in the specification.
This was fixed by going to http://jaxb.java.net/ and getting a new jaxb-impl.jar & jaxb-xjc.jar. I downloaded and ran the jaxb.jar file download and it created the needed jars.
Related
There is a WSDL file sent by a third party web service.
Back in February, my teammate converted the WSDL into java (Not sure which tool they used because they are not here any more). Our large-scaled project was built based on that.
Recently the web service party updated the WSDL. I tried to convert the new WSDL using wsimport. Now the problem is the those converted java classes are not compatible with the code base any more due to the package name changes (from upper case to lower case).
For example, import gov.services.food.api.DataCollection.Extensions.CaseClient is now changed to gov.services.food.api.datacollection.extensions.CaseClient
My questions is:
Does the choice of WSDL 2 Java convertor tool cause this kind of lower/upper case changes or even other data structure changes?
Thank you in advance.
Confirmed!
The choice of different convertors does affect the java codes result. For the same convertor tool, different options that you pass in will also affect the result.
In my particular case, I used 'ant' build tool.
the core part in my build.xml is:
<target name="wsdl2java">
<java classname="org.apache.axis.wsdl.WSDL2Java" classpathref="DSSClient.classpath" failonerror="true" fork="true">
<arg value="${wsdl.url}/DEX_august_2015.wsdl" />
<arg line="-v -D -a" />
<arg line="-o ${wsdl.url}/generated" />
<arg line="-O -1" />
</java>
</target>
And of course combined with the necessary jars that WSDL2Java requires.
This should create the java codes with capitalized package names.
I am having some trouble (annoyance really) with ANT editor in Eclipse where it is displaying me a warning "Reference build.classpath not found." on the following block:
<target name="generate" depends="..., mvn-depends">
<taskdef name="xjc" classname="com.sun.tools.xjc.XJCTask">
<classpath refid="build.classpath" />
</taskdef>
...
</target>
With mvn-depends target looking like this:
<target name="mvn-depends">
<artifact:dependencies pathId="build.classpath">
<pom refid="my.pom" />
</artifact:dependencies>
</target>
The rest of the references to build.classpath in the build file are not throwing any warnings and the and build runs just fine without any errors, so it does not seem to be amounting to much.
Still, ignoring a warning makes me feel sort of dirty every time I have to edit that file. Specifically, not knowing if this is a bug in Eclipse ant build file validation code or a potential problem in the way the build file has been structured, that Eclipse has identified.
If anyone has any ideas on why this warning is being shown and whether it is safe to ignore or maybe even disable from preferences and would care to share that knowledge, I would definitely be grateful for the knowledge.
Edit:
As requested, here is an example of a reference to build.classpath that does not cause any warnings:
<javac deprecation="off" debug="on" source="1.7" target="1.7" encoding="UTF-8"
includeantruntime="false" memoryMaximumSize="512M" fork="true">
<classpath refid="build.classpath" />
</javac>
As the editor could recognize refids and other elements that Ant specifies, I guess that the editor does something similar to Ant's build file parsing process.
That is, parse this ant build file into a Project object, and references in <taskdef> may be checked, while <javac> may not.
Since the build.classpath is set during runtime and it is set by something other than things like <classpath>, Eclipse may not find it.
I don't have strong prove about this. But something can be done to make us know more.
First, copy the <javac> to the same target where the warned
<taskdef> exists, to see if the <javac> gets a warning;
Then, copy the <taskdef> to the same target where the presetdefed
<javac> exists, to see if the <taskdef> still gets a warning;
Third, in target "generate", comment out the <taskdef> part, and
check if the <xjc ... /> call gets a warning.
For the first one, I expect "NO", while for the other two, I expect "YES". Otherwise, my guess is wrong.
And it makes sense that it is just a warning -- things Eclipse can't find in editing time could exist during runtime.
Make sure you have given the path element location correctly as bellow.
<property name="dependencyfinder.home" value="C:/DependencyFinder"/>
<path id="dependencyfinder">
<pathelement location="${dependencyfinder.home}/lib/aaa.jar"/>
</path>
<taskdef classname="com.sun.tools.xjc.XJCTask">
<classpath refid="dependencyfinder"/>
</taskdef>
Note: DependencyFinder has a folder lib and lib has aaa.jar
Please check the bellow link for more information
Click here
We got a GWT project in Eclipse, that otherwise works.
Now I want to have a script that runs on the server, which pulls the latest version from source control and compiles it on the server and deploys it.
This will save us a lot of manual work and allow us to deploy new version when on a connection with limited bandwidth (since we won't have to upload the application to the server).
After pulling the latest version of the source code, the script tries to compile the code using the following command:
java -cp "/path/eclipse/plugins/com.google.gwt.eclipse.sdkbundle_2.5.0.v201211121240-rel-r42/gwt-2.5.0/*:/path/company/projects/pull-compile-deploy/X/X/src:/path/company/projects/pull-compile-deploy/X/X/war/WEB-INF/lib/*" com.google.gwt.dev.Compiler nl.company.projects.X
Compiling module nl.company.projects.X
Finding entry point classes
[ERROR] Unable to find type 'nl.company.projects.X.client.XMain'
[ERROR] Hint: Previous compiler errors may have made this type unavailable
[ERROR] Hint: Check the inheritance chain from your module; it may not be inheriting a required module or a module may not be adding its source path entries properly
All source code is in /path/company/projects/pull-compile-deploy/X/X/src and all used .jars (except for the GWT stuff) are in /path/company/projects/pull-compile-deploy/X/X/war/WEB-INF/lib/. Obviously something goes wrong.
Questions: The file /path/company/projects/pull-compile-deploy/X/X/src/nl/company/projects/X/client/XMain.java does exist and should imho be in the classpath?!
Anyone Any idea what might go wrong here?
Is it maybe possible to see in some log exactly the commands that eclipse executes for compilation? I looked at the build.xml that eclipse can export, but it seems that does not contain a target to compile for production.
something else: apperantly GWT expects the X.gwt.xml to be at /path/company/projects/pull-compile-deploy/X/X/src/nl/company/project/X.gwt.xml, whereas eclipse put it in /path/company/projects/pull-compile-deploy/X/X/src/nl/company/project/X/X.gwt.xml (i.e. nested one directory deeper), I fixed this by creating a symbolic link.
Further Edit:
Since one answer focused on how I invoked the compilation tools, I have rewritten that in Ant, see below.
The problem remains of course.
<!-- Compile the source using javac. -->
<target name="compile" depends="init">
<javac srcdir="src/" destdir="bin/">
<classpath refid="project.classpath"/>
</javac>
</target>
<!-- Use the GWT-compiler. -->
<target name="gwt-compile" depends="compile">
<java failonerror="true" fork="true" classname="com.google.gwt.dev.Compiler">
<classpath>
<path refid="project.classpath"/>
<pathelement location="src/"/>
<pathelement location="bin/"/>
</classpath>
<jvmarg value="-Xmx512M"/>
<arg value="${module.name}"/>
</java>
</target>
Anything wrong with the above Ant-script?
module.name = nl.company.projects.X and the path with refid="project.classpath" contains all used libraries aswell as the GWT libraries (gwt-user.jar, gwt-dev.jar and validation-api-1.0.0.GA(-source).jar).
The XMain class inherits nothing (other than from Object) and only implements EntryPoint (which is included in the gwt-user.jar). So I do not think the problem is related to the second hint that the compiler gives.
Any ideas?
GWT requires you to javac your classes, it needs both the *.java and the *.class files.
This has not always been the case, and should change back in the future (see https://code.google.com/p/google-web-toolkit/issues/detail?id=7602 for instance), but for now that's the state of affair: you need to javac before you can com.google.gwt.dev.Compiler.
javac -cp "/path/eclipse/plugins/com.google.gwt.eclipse.sdkbundle_2.5.0.v201211121240-rel-r42/gwt-2.5.0/*:/path/company/projects/pull-compile-deploy/X/X/war/WEB-INF/lib/*" -sourcepath /path/company/projects/pull-compile-deploy/X/X/src /path/company/projects/pull-compile-deploy/X/X/src/nl/company/projects/X.java -d /path/company/projects/pull-compile-deploy/X/X/bin
java -cp "/path/eclipse/plugins/com.google.gwt.eclipse.sdkbundle_2.5.0.v201211121240-rel-r42/gwt-2.5.0/*:/path/company/projects/pull-compile-deploy/X/X/src:/path/company/projects/pull-compile-deploy/X/X/bin:/path/company/projects/pull-compile-deploy/X/X/war/WEB-INF/lib/*" com.google.gwt.dev.Compiler nl.company.projects.X
(please double-check the above commands before use)
EDIT: (in response to your "question" re. the X.gwt.xml): GWT expects the X.gwt.xml at nl/company/projects/X.gwt.xml because that's what you told it to use: module.name = nl.company.projects.x. If the file is at nl/company/projects/X/X.gt.xml then use nl.company.projects.X.X as the module name. Using a symbolic link here is likely to be the problem: the source path for the module (search for <source at https://developers.google.com/web-toolkit/doc/latest/DevGuideOrganizingProjects#DevGuideModuleXml) will then be nl/company/projects/client and thus won't include nl/company/projects/X/client where your XMain class lives; it's this unavailable to the GWT compiler.
That said, I totally agree with SSR: use a decent build tool: Ant, Maven, Gradle, Make, whatever, it'll make your life so much easier. A build tool that manages dependencies (Ant+Ivy, Maven, Gradle) is even better IMO.
Why would you put yourself through such non-standard build exercise like this.
If it is non-academic project then USE maven. If you find maven difficult then use ant.
Examples for both type are provided by GWT team - http://code.google.com/p/google-web-toolkit/source/browse/#svn%2Ftrunk%2Fsamples.
Note - maven has plugins to do most of the stuff you are trying in standardized way.
I'm writing an ANT task that is behaving very oddly. I've tried a variety of google searches with no clear answer.
I have a compile target in ANT that calls the javac command:
<target name="compile">
<mkdir dir="${classes.dir}" />
<javac srcdir="${src.dir}:${unittest.src.dir}" destdir="${classes.dir}">
<classpath refid="classpath" />
<exclude name="**/plugins/**" />
<exclude name="**/outbound/**" />
</javac>
</target>
That generates no errors, but when I run ant with the -verbose and -debug tags I get the following in my logs:
[javac] package/MyClass.java added as package/MyClass.class doesn't exist
So it's not erroring out, but it is giving me this odd result (with the "doesn't exist" appended at the end). Obviously this causes later targets to fail when it tries to run the classes (in this case, my junit target).
Web searches seem to indicate that I'm either missing a java_home env variable or that there is a versioning issue somewhere along the line (this error tended to occur when the source attribute on javac was set, but I removed that and am still getting the odd result). I believe we've got those possibilities covered.
Any thoughts or advice on this would be wonderful. Thanks.
I don't know too much about ant, but I would almost guess this error message is a red herring. I think it's just reporting that MyClass.java was added to the list of files to compile, because the compiled version of the class was not found on the class path. This seems to be supported by the fact that the task does not fail.
What are the later errors you are getting?
I need to generate an apk file using an Ant script, but I'm having problems with the compile target. To automatically generate the Ant script, I've used the Android tool with the command android update project. The problem is that this project depends on another project, so I need to use a custom compile task.
For that reason, I've overridden that target: I've copied the compiled task from ant_rules_r3.xml and I've changed the javac task like this (see comments for what I changed):
<!--I've changed the target 1.5 to target 1.6 -->
<javac encoding="UTF8" target="1.6" debug="true" extdirs=""
destdir="${out.classes.absolute.dir}"
bootclasspathref="android.target.classpath"
verbose="${verbose}"
classpath="${extensible.classpath}"
classpathref="android.libraries.jars">
<src path="${source.absolute.dir}" />
<!--My project has two src directories -->
<src path="${source2.absolute.dir}" />
<src path="${gen.absolute.dir}" />
<src refid="android.libraries.src" />
<!--I've added here the src dir of the other project -->
<src path="${dep1.source.absolute.dir}"/>
<classpath>
<!--I've added here the lib dir of the other project -->
<fileset dir="${dep1.external.libs.absolute.dir}" includes="*.jar" />
<fileset dir="${external.libs.absolute.dir}" includes="*.jar" />
<fileset dir="${extensible.libs.classpath}" includes="*.jar" />
</classpath>
</javac>
The problem is that when I compile with ant compile, I get the following error:
[javac].... cannot find symbol
[javac] symbol : constructor IOException(java.lang.String,java.security.NoSuchAlgorithmException)
[javac] location: class java.io.IOException
[javac] throw new IOException("Algorithm not found", e);
It seems as though it's been compiled with JDK 1.5 instead of 1.6 even though I have set the target property to 1.6. My computer is using Java version 1.6.0_20.
I've tried using javac compiler="javac1.6", but I get the same error.
I've also set in my build.properties:
ant.build.javac.target=1.6
ant.build.javac.source=1.6
but it doesn't solve the problem either. Setting it to 1.3 instead of 1.6 causes more errors, so it seems it is using the JDK I'm setting here.
How can I get this to compile correctly?
Because you've specified the bootclasspath to use the Android SDK classes, these will probably be the ones that contain the IOException class that does not implement the two-arg constructor with a Throwable second arg. That constructor was new in Java 6, but according to recent Android (2.2) docs, the Android version only has Java-1.5 style constructors, and doesn't implement the two newer constructors that take Throwable args.
You didn't mention whether you'd got this to build successfully before bringing in the second project - so I'd recommend checking your local Android boot classes to see what constructors IOException offers.