rubin55
commented
7 years ago The exact schema directory I used (a subselect of the complete AdsML distribution): schema.zip
Open rubin55 opened 7 years ago
rubin55
commented
7 years ago The exact schema directory I used (a subselect of the complete AdsML distribution): schema.zip
wdschei
commented
7 years ago Did you happen to capture any memory information at the time of the "hang"?
wdschei
commented
7 years ago What version of Gradle are you using?
rubin55
commented
7 years ago Gradle 4.0.1. I did run top, java process was never using more than 1.51gb of memory, 100% cpu usage (on one core, not all).
wdschei
commented
7 years ago @rubin55 I was able to duplicate this issue using this plugin. I'm curious if this is run manually against the XJC Ant Task if it has the same result. If so, then this would be a bug upstream from us and we would need to post it with them.
rubin55
commented
7 years ago I've created a build.xml with equivalent libs in a lib dir. I can confirm that this setup works and does not indefinitely hangs like this plugin. See attached: works-with-ant.zip
adrianjgeorge
commented
7 years ago That is super weird, because all the plugin does effectively is forward on to that same ant task.
zubri
commented
7 years ago I'm experiencing the same issue with another set of XSDs.
I've got a circular dependency in the imports; A.xsd importing B.xsd and B.xsd importing A.xsd. Is this harmless? Or could be part of the cause?
rubin55
commented
7 years ago I initially worked arround this by having a build.xml (see previously attached works-with-ant.zip) and a static lib folder. I have since then been able to solve this as a gradle ant-task, like so:
configurations {
jaxb
}
jar {
baseName = "adsml-model"
}
dependencies {
// See github.com/jacobono/gradle-jaxb-plugin/issues/15
jaxb("org.glassfish.jaxb:jaxb-runtime:2.2.11")
jaxb("org.glassfish.jaxb:jaxb-xjc:2.2.11")
jaxb("javax.xml.bind:jaxb-api:2.2.11")
// Required for ant task parts.
jaxb("org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.11.1")
jaxb("org.jvnet.jaxb2_commons:jaxb2-basics:0.11.1")
jaxb("org.jvnet.jaxb2_commons:jaxb2-basics-annotate:1.0.2")
// For xjc logging output with gradle xjc --info.
jaxb("org.slf4j:slf4j-api:1.7.5")
jaxb("org.slf4j:slf4j-simple:1.7.5")
}
task genJaxb {
doLast() {
ext.schemaDir = "${project.projectDir}/src/main/resources/schema"
ext.outputDir = "${project.projectDir}/src/main/java"
project.ant {
taskdef name: "xjc", classname: "org.jvnet.jaxb2_commons.xjc.XJC2Task",
classpath: configurations.jaxb.asPath
xjc (destdir: outputDir, extension: true) {
arg line: "-enableIntrospection -mark-generated -npa -Xannotate -XautoInheritance -XsimpleEquals -XsimpleHashCode -Xinheritance -Xsetters -Xsetters-mode=direct"
schema dir: schemaDir, includes: "**/*.xsd"
produces dir: outputDir, includes: "**/*.java"
}
}
}
Note that the above generated about ~600 classes in ~6 seconds (with the AdsML schema previously attached also).
zubri
commented
7 years ago Thanks for the feedback, you are not using the plugin though.
I have a lot of issues related to ObjectFactory name collisions and the circular XSD imports. I was expecting this plugin with the dependency tree and episode handling would be able to generate the code.
rubin55
commented
7 years ago ... I know I'm not using the plugin in the last comment I posted, which details a workaround; I initially filed this issue because this Gradle Plugin hangs when trying to create a set of java files from a set of XSD files. My before-last comment details using a gradle ant-task to do the same thing that this plugin (imho should) do.
By the by, that name collision issue is usually due to specifying a package name.. package name flattens the entire namespace (i.e, it's not a prefix or sth like that); that means that FooBar in namespace A will conflict with FooBar in namespace B if you specify a package name (-p on xjc command line). I ran into this only a few days ago when I was trying to give our JAXB generated packages a bit nicer names instead of the (in my case at least) very ugly generated ones.
Also note, afaik: the ObjectFactory classes are something particular to JAXB2; in my experience they are created for each subpackage, helping in the creation of more involved object trees; specifying a package name (and thus flattening the namespace) will conflict with those for sure (kinda silly, because that means you don't even need to have two same-named entities in your xsd to have a conflict that way)
tresat
commented
7 years ago I am seeing the same thing, migrating from an existing Ant build which runs the com.sun.tools.xjc.XJCTask just fine. Specifying (I believe) the same set of arguments via the plugin as I was supplying to the ant task results in the xsd-dependency-tree task, when run with --info outputting all my xsd filenames, then "jaxb: generating xsd namespace dependency tree", then "creating baseNamespaces '1' as tree nodes" and then hanging forever (I let it go 16 hours overnight, no luck).
dhanusathya
commented
6 years ago @rubin55 Thanks for ant task
Java 8, r144 on macOS, x64, 16gb ram, 8gb heap.
I've succesfully used the following gradle config before to build java classes (with other XSD files):
However, when trying to use the above configuration on a selection of XSDs in the AdsML XSD distribution (full distribution available here), The process seems to hang forever (I tried waiting for 2 hours, after that I lost faith, especially because nothing is logged except for the gradle memory process logger). The debug log: