search

rackerlabs / gradle-jaxb-plugin

Gradle plugin to ease projects that use xsds and the ant jaxb task
GNU General Public License v2.0
34 stars 21 forks source link

Multiple xsd files: Only source code generated for last file present in destination dir #25

Closed christoph-lucas closed 6 years ago

christoph-lucas commented 6 years ago

When compiling more than one xsd file at a time, only the source code generated for the last file is present in the destination directory after the task completes.

More concretely, we have two xsd files, a.xsd and b.xsd, both in the directory configured in xsdDir. Both files are found:

jaxb: attempting to parse '2' nodes in tree, base nodes are '[a.xsd, b.xsd]'
parsing '2' nodes '[a.xsd, b.xsd]'

Then the ant task is started on each of the two nodes (shortened info level log):

node 'a.xsd' depends on a total of '0' namespaces
running ant xjc task on node 'a.xsd'
[ant:xjc] Compiling file:a.xsd
[ant:xjc] Writing output to /src/generated/java

and for the second file:

node 'b.xsd' depends on a total of '0' namespaces
running ant xjc task on node 'b.xsd'
[ant:xjc] Compiling file:b.xsd
[ant:xjc] Writing output to /src/generated/java

When looking at the code, I have the impression that the problem is in JaxbXjc.groovy, line 128. It seems that the destination directory is always deleted in between two nodes.

Looking at the history, this line was introduced on July 18, 2017 with this commit. The reason mentioned there was "Updated the JAXB XJC task to delete the registered output directory when the Up To Date check fails." I have the impression the directory is not only deleted when the check fails, but always.

Why do you need to delete the destination directory? Is that the correct and intended behaviour? If so, how do you parse more than one file, or any collection of files with more than one base node?

Any help would be highly appreciated!

wdschei commented 6 years ago

@christoph-lucas What does your build.gradle look like?

wdschei commented 6 years ago

@christoph-lucas

I created a Short, Self Contained, Correct (Compilable), Example or Minimal, Complete, and Verifiable example here:

It seems to work for me. Am I missing something?

christoph-lucas commented 6 years ago

@wdschei: Thank you very much for your reply and the example code. I checked it out and it works fine.

The problem seems to be with the bindings. As soon as I remove the binding files (*.xjb) from the schema folder in your example, I can reproduce the issue as described above (only the source for the last xsd file is generated, in this case for b.xsd).

In version 2.3.0 of the plugin the issue does not occur, the source for both files is generated even without the binding files. Are binding files mandatory as of version 2.4.1?

wdschei commented 6 years ago

@christoph-lucas We only use JAXB with bindings files as the defaults can provide wonky classnames.

That said, we will look into bringing this capability back in a future version. The intent of always cleaning up (i.e. removing the directory) stems from removing old auto generated classes that may no longer even exist with the schema definitions currently being processed.

The TLDR is that at least v2.4.1 will require a bindings file if multiple schemas are being processed.

We do accept pull requests, so feel free jump in and make the update. The main requirement is that if a.xsd and b.xsd are processed, then b.xsd is removed that the classes produced by b.xsd are also removed.

christoph-lucas commented 6 years ago

@wdschei : Thank you for your reply. With the bindings I could make it work in our project. Yet, it would be great if worked also without :).

I am not very proficient when it comes to Groovy and Gradle Plugins. But of course, if I manage to provide a solution I feel comfortable with, I'll open a PR.

wdschei commented 6 years ago

@christoph-lucas After further evaluation, we saw the stupidity and it should be fixed now in today's v2.5.0 release that also supports the Gradle v4.x UP-TO-DATE checks much better.