Is there any way to specify multiple schema directories?

[c4milo]

I have several segregated folders that I would like to generate Java code from, using the same gradle script as they belong to the same project. Is there any way to achieve this?

[scubacabra]

Unless they are nested under a common parent directory, it is not possible to do that. :(

[EmteeW]

This is very necessary and a common feature that is maybe quite a bit more important than you realize. Schema versions are common for SOAP services, and the different schema versions will produce classes by the SAME NAME (i.e. conflict) so they cannot end up in the same package. But it is pretty typical to want one client to support different versions of "protocol".

I am so poor with Gradle though, I am not sure how one can create multiple closures and then multiple Ant tasks needed for this.

Perhaps you can use a container, and each element will constitute a configuration, and a single jaxb task will iterate and call wsimport with each of these configurations. Although multiple, separate gradle tasks would be ideal.

[cleankod]

I'm having the same issue as @EmteeW so +1.

[wdschei]

I believe this is fixed in https://github.com/jacobono/gradle-jaxb-plugin/pull/47

[bpillai]

is there an example for how we would configure a xjc task with multiple xsdDir and multiple destinationDir

[wdschei]

There is not an example anywhere, but it could only ever have a single destinationDir. The content in the bindings files would define the structure under the destinationDir. The xsdDir and bindingsDir are the lowest common parents of the XSD's and XJB's respectively. These can be fine tuned using the xsdIncludes and bindings values in order to more explicitly define exactly which files are used. So, here is an example of using the defaults of all XSD's and XJB's in the src/main/resources/schema directory with the output being in the generated-sources/xjc directory.

jaxb {
  xsdDir = "${project.projectDir}/src/main/resources/schema"
  xsdIncludes = ['**/*.xsd']
  bindingsDir = "${project.projectDir}/src/main/resources/schema"
  bindings = ['**/*.xjb']
  xjc {
    destinationDir = "${project.buildDir}/generated-sources/xjc"
  }
}

Keep in mind this only works with the fixes in https://github.com/jacobono/gradle-jaxb-plugin/pull/47 or with the version published at https://maven.research.rackspacecloud.com/content/repositories/public/ and brought in with dependency classpath 'org.openrepose:gradle-jaxb-plugin:2.2.1'. This can be seen in the test located at: https://github.com/wdschei/gradle-jaxb-plugin-test/

[bpillai]

Thanks for this . This works only if i use java 8 to run . My project is in Java 7 . This doesnt seen to support java 7

[wdschei]

@bpillai,

You would be correct. The new version we have published only supports Java 8+.

Kindest regards, Bill

[bpillai]

Is there a git hub repo where you have your source code , so that i can recompile it to java 1.7 ?. Or has this plugin used features that is specific to Java 8 . If that's the case is there any option for ppl using a java version other than 8 ? .

[wdschei]

Our updated version is located here: https://github.com/rackerlabs/gradle-jaxb-plugin

We started updating some of the docs, but were hoping that it would get merged into this main trunk so we stopped.

[wdschei]

Nothing in it should be Java 8 specific, so you should be able to compile it and use it with Java 7 or even 6 if needed. We are just discouraging the use of anything less than Java 8 since they are all EOL'd.

[bpillai]

One last question , the git hub code says it is version 2.2.0 where as the one in openrepose is 2.2.1 , does both of them have the latest changes that you were talking about earlier ?.

[wdschei]

That was my mistake I had forgot to push it. I had updated the default XJC Task from XJCTask to XJC2Task and backed out the locking mechanism since the new one is multi-process safe. The discussion for this is here. The latest v2.2.1 code is available on GitHub now.

[wdschei]

@c4milo , @EmteeW , @cleankod , & @bpillai

The OpenRepose.org updated version of this plugin is now available in the Gradle Plugins repository and is compatible with JSE7.

[aplatypus]

Hello,

I just found this discussion and I agree with all those describing this as a Necessary requirement.

We need to support existing code and I wanted more or less a way to to the following from the build.gradle file.

We need to pick-up sub-folder and put the generated code in existing packages matching the existing calling code import commands.

We need to pick-up schemas from two folders and generate two packages

• schemas/response/_.xsd --> ...schema.request._ package
• schemas/response/_.xsd --> ...schema.response._ package

Going to the relevant sub-folder under the generated/ folder sub-tree.

This xjc actually worked once, but it must have been accidental. I stopped happening when we tried to move the generated code from src/java to generated/java

I accept the example is syntacticly not-good, I want to convey the outcome we need:

jaxb
{
     destinationDir="src/main/generated/java"

    xjc    //  first pairing
    {
        xsdDir = "ManifestLibrary/src/main/resources/schemas/response"
        generatePackage = "lib.manifest.schema.response"
    }        
    xjc    //  a second pairing
    {
        xsdDir = "ManifestLibrary/src/main/resources/schemas/request"
        generatePackage = "lib.manifest.schema.request"
    }

There doesn't seem to be any way to pair-up xsdDir-s and destination generatedPackage-s for emitting code. I tried using the example shown above but we need to satisfy a use-case that is the inverse of the example shown above.

Can any one point me to an example resembling what we're trying to do?

Many thanks,

will

[wdschei]

@aplatypus,

This project you are commenting on appears to be abandonware. My team and I have had open Pull Requests here some time. Since we could not wait any longer and felt the community needed the modifications that have been talked about in these threads, we forked it and started maintaining it. The latest v2.2.1 code is available on GitHub and binaries are available from the Gradle Plugins repository. If the new version doesn't support your use case, the please file an issue over there and we'll take a look.

Thanks, Bill