Infinite (?) hang on xsd-dependency-tree phase #20
Comments
|
The exact schema directory I used (a subselect of the complete AdsML distribution): |
|
Did you happen to capture any memory information at the time of the "hang"?
|
|
What version of Gradle are you using? |
|
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). |
|
@rubin55 I was able to duplicate this issue using this plugin. |
|
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 |
|
That is super weird, because all the plugin does effectively is forward on to that same ant task. |
|
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? |
|
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: Note that the above generated about ~600 classes in ~6 seconds (with the AdsML schema previously attached also). |
|
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. |
|
... 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) |
|
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). |
|
@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:
The text was updated successfully, but these errors were encountered: