generate to other dir than 'src/main/java'

[rburgst]

Currently the plugin assumes that the files are generated into the src/main/java folder. If you want to use something else, you end up having to code quite a lot in the main build.gradle file.
There are multiple reasons for wanting the wsdl code not in the main source directory

• if package names are very similar it might be difficult to delete the individual classes once a new wsdl version comes along
• it troubles me to check in generated sources
  ...

the result is a build file that looks something like this

def genSrcDir = "$rootDir/src/generated/java"

wsdl {
    wsimport {
        sourceDestinationDirectory = genSrcDir
    }
}

sourceSets {
    main {
        java {
            srcDir 'src/main/java'
            srcDir genSrcDir
        }
    }
}

task cleanGenerated(type: Delete, group: "Build", description: "deletes the generated files") {
    delete genSrcDir
}

clean.dependsOn('cleanGenerated')
compileJava.dependsOn('wsimport')

Note that it took me multiple attempts to come up with any solution but all the others were even more complicated (create a new source set, add it to the main build cycle, etc).
Therefore, it would be good if the plugin would support such workflows by possibly checking whether the generated source dir is outside of src/main/java. This would make it far more user friendly IMHO.

[Daniel Mijares]

I think the assumption to go in src/main/java is a valid one.

• You can always change the package name through the targetNamespace fields in the schema, or indeed with your last pull request.
• It shouldn't trouble you to check in generated source. It's a web service. The generated portions are necessary so that you can derive the implementation class that actually does the work.

My whole idea for this was to separate everything into separate projects, and keep the generated files so that with schema changes, their are diffs to the generated files as well.

I could see that argument that xsd can be generated on the fly (although I disagree), but jax-ws generated code is necessary for the service to actually be written, because it generates the interface class from the .wsdl.

As I developed more services I started separating them more until I had separate projects for jaxb sources, jaxws sources, and I separated common logic into -ejb projects as well.

[rburgst]

I would say it depends ;)

We do have a contract first approach so I start with a wsdl file. This is the single source of truth. In the development phase it will be that the wsdl gets updated. Then having generated source files hanging around is inconvenient. Obviously it would be possible to split the project in multiple modules but this needlessly complicates the whole setup and slows down the builds.

[Daniel Mijares]

I guess everything depends 😄

So, I guess help me understand what the problem is.

Creating an extra sourceSet is pretty much the same thing as creating another project.

I also don't see how splitting into mulitple projects slows builds. Gradle has incremental builds, if nothing has changed in a project you only need to build it once.

I still don't understand why you don't check in your generated files from wsimport. At the very least, one of those files something you need. That gives you the interface for the service.

Sometimes the different version of jaxws and jaxb can give different results from file gneerations, and I like to keep track of that. Even if the changes are a timestamp, I like saving those because it basically tells you when everything was last generated.

Even then, sometimes a small change in the wsdl or xsd can yield a drastically different generated file, maybe it is just me, but I like to know when that is changing.

For this plugin especially, I have left the parsing with wsimport as manual task in the build process, nothing depends on that task. So that you can save time on builds by not generating everything over and over. The only time you should generate is when you physically change the file.

Separate projects are merely a separation of concerns at that point unless a schema said project depends on changes. A dependency on a project that uses the incremental build engine is all that is left to worry about, and that doesn't leave a whole lot to worry about.

[rburgst]

Lets agree to disagree.
I am a fan of DRY. Our WSDLs are hand coded and everything else is basically generated.
Ad build time:
I have projects with 60+ sub-projects. I do feel every module that I add in build time. Granted gradle does a superb job of incremental builds but if I can avoid it (especially for simple projects) then I choose to do that.
I can see your side for sure, its just that my requirements differ. So I guess we can close this issue and leave it at that.