As far as I understand, it is better to use Spring versionless xsd.
However, when using Intellij the validation is done based on a random xsd file.
When adding the version to the xsd file everything works as expected.
As you can see I use Spring 4.2.1 but Intellij chooses 3.1 version.
Is it a bug (or not yet implemented feature) in Intellij?
Is there a workaround?
If there is no place with version specification, then
yes, it is random, you can try the following test: add space in front of line (make some simple change) with xsd specification), after each change it jumps to another random xsd version
If you want to lock it on the latest lib version and don't specify it, you can use gradle build.
//use latest version of library with gradle:
compile 'org.springframework:spring-orm:+'
after that idea always points to latest version of xsd for schemaLocation
Related
My RCP application makes calls to SOAP web services and has been using the built-in JAXB/JEE components in Java 1.8. I have set up the build process to force the use of Java 1.8 and this had been working well.
Recently, the build stopped working because the builder (Tycho) now has a component which only works with later Java versions. If I compile with the later version I get 100's of JEE-related errors such as JaxbElement not found or #WebMethod not found.
At some point we will have to move away from Java 1.8 and use a Java version which does not provide those JEE components, so forcing the use of 1.8 can only be a short-term solution.
Is there an eclipse plugin which already provides those missing components? (I have searched but not found anything) Or do I need to create my own helper plugin which contains the necessary libraries? Is there perhaps a JAXB alternative which I could use for the SOAP calls?
The JAXB plugins/bundles are available on Eclipse Orbit: the plugins/bundles starting with javax..
In the plugins/bundles where they are needed, add the dependency in the MANIFEST.MF file via Import-Package (using Require-Bundle would require that these plugins/bundles are available even when using Java 8).
See also this answer.
I've created a one-off of a public domain library to use for testing. I built it and copied it to a server so the rest of my group can use it also. Unfortunately when I run ./gradlew build it's picking up the original version.
I set the compile line in build.gradle to have '+' for the version
How does gradle decide which version to include and how would I force it to use my updated copy?
Assuming the original version is 2.0, and your version is 2.1, and the dependency spec refers to "2.0.+" (or some variation of that), it's going to take the FIRST artifact that matches that version expression. You may think it means to find the "largest", or somehow to know that it should get your version, but that's not what's happening here.
In short, set the dependency to a specific version.
If you have non-standard repositories, read the "Repositories" section of the Gradle User Guide for information on how to configure that: https://docs.gradle.org/current/userguide/dependency_management.html#sec:repositories .
Hi I wanted to upgrade android-apt in my project from version 1.4 to 1.7
Currently I'm using Google auto-service 1.0-rc2, so all what I had to do is putting #AutoService(Processor.class) annotation in my annotation processor class.
After updating android-apt to 1.7 version my annotation processor stopped working. It seem it is not called during build.
I thought that auto-service may be the issue. So I made resources/META-INF/services/javax.annotation.processing.Processor file with content
pl.edu.radomski.navigator.NavigatorAnnotationProcessor
Sadly it didn't helped at all.
If you want to see the code with android-apt 1.4 and auto-service 1.0-rc2 it is available here
Is there any simple way to upgrade android-apt and keep the processor working?
Is this auto-service 1.0-rc2 fault or something is wrong with android-apt?
In 1.7 a change was made to not automatically build a dependent project that is set as apt, due to unwanted side effects affecting build order.
In 1.8 I'll probably have a better way to support it, but in the mean time you can configure the apt block to specify that your processor should be run like this:
apt {
processor "pl.edu.radomski.navigator.NavigatorAnnotationProcessor"
}
Note that is only needed in the case your processor is in the same project as your app or library. The reason is that the file in META-INF/services is not read by javac in this setup because the project isn't packaged at that point. Explicitly adding a processor statement will add the processor that javac otherwise would not discover.
Years ago I wrote an application that used JAXB to generate Java bindings for an XML schema. The application code and the schema have been updated quite a lot over the years, but the JAXB jars remained the same since 2008, which was when I started using JAXB for this application. I've been using Ant to build the application, including generating and compiling bindings, and everything worked fine on at least two XP Pro development machines. I made some changes to the schema and never had to think about JAXB.
Recently I tried to rebuild the application from scratch on a new laptop, and the build keeps failing. The new 64-bit laptop is running windows 7 Pro, it had a newer JDK (1.7.0_45) and a new version of Ant (1.9.3). I was able to get around some weird problems by switching to a yet newer version of ant (1.9.4) and switching to latest JAXB jars. At this point, I don't even remember what those issues were (but I can recreate them by reverting to older JAXB jars in SVN).
After upgrading JAXB, I ran into new problems. First of all, the xjc task in ant seems to be interpreting the target attribute differently; it threw some error and apparently the destdir has the semantic meaning that target used to have.
Second, this task no longer generates the impl package with the implementation classes whose names were supposed to end with Type, so the rest of my code fails with a bunch of compilation problems.
Is there a way to make the new JAXB version backward-compatible? My other options are try updating the code to work with the new bindings, which seems like a lot of unnecessary work, or reverting to old JDK and Ant.
This is a late reply to the original post. But should be good as a reference for other folks. I met the same problem. Here is what worked for me after going through much of the same struggles trying to rebuild JAXB 1.0 scheme/binding using later JDKs (8 and 7).
My goal is to build with latest JDKs without the hassle of upgrading JAXB, if possible.
JDK 7&8 failed building with JAXB 1.0 due to ClassCastException thrown from <xjc> possibly due to incompatible language features. JDK 5&6 work, however.
I went through several attempts trying to upgrade to the latest JAXB 2.11.12,
Update ant build file <xjc> task to replace target attribute with deskdir
Change binding files syntax - bindingStyle attribute was removed in <jxb:globalBindings> in the latest JAXB - we use modelGroupBinding
Adjust binding class files suffix to avoid name conflicts. Update sources for the new type names generated.
There were still remaining name conflicts and source upgrades required.
I decided to stop going further down the rabbit hole making all these changes and focus on finding just one version of JAXB that generates JDK 7&8 compatible sources but still support JAXB 1.0 schema and binding.
Newer <xjc> task supports version specification by source attribute. However, as the original poster found out, support of "1.0" was removed in later JAXB distributions
The "Illgal version 1.0" error message when using <xjc> is due to support for version 1.0 was removed in since JAXB 2.2.7 (https://jaxb.java.net/nonav/2.2.11/docs/ch02.html#a-2-2-7)
However, JAXB 2.2.6 doesn't work either. There seems to be a bug in that "jaxb-xjc.jar" version not generating sources correctly based on the attribute, resulting in the certain ClassNotFoundException during build.
I read reports on JAXB 2.1.18 failing to respect "1.0" source as well
Eventually I found JAXB 2.0.5 is to be one version that can generate JDK 7&8 compatible sources using JAXB 1.0 source schema and binding.
Drop in the JAXB-RI 2.0.5 libs and remove old jaxb-libs.jar
Add source="1.0" attribute the <xjc> task
No need to convert <xjc> "target" attribute to "deskdir" in this version
I have not tested more versions beyond 2.0.5 but it's possible there are higher versions that does the same
Your old project seems to use JAXB 1 whereas all the tools now have JAXB 2.x by default.
Try the following in the XJC task:
source="1.0"
target="1.0"
See these documents:
https://jaxb.java.net/2.2.4/docs/xjcTask.html
https://jaxb.java.net/2.2.4/docs/jaxb-1_0.html
I'm suffering from the same error as this question, but I can't use that answer since I'm not using Maven, so I'm stuck on how to specify what version of jaxb to use with wsgen. I'm downloaded the 2.2.7 jars and added them to my classpath, but my generated files still say that they've been generated using 2.2.4b1, which I presume was included in the JDK.
Anybody know how to specify to wsgen what jaxb version I want to use?