Closed pschyska closed 3 years ago
Thanks for the proposal. This PR does quite a bit more than what #13 is for. I do think there is value programmatically inspecting additional inputs, however, such implementation I think is for more advanced use cases where tracking the file itself is not sufficient enough. The extension changes I'm not particularly for, currently. The extension is meant to model what the Maven plugin has (<wsdlOptions />
) without any additional work/configuration.
The extension changes where just to be able to set the JavaExec args earlier (at a time where they will "count" as inputs, i.e. before executing the task). The recursive resolution of the WSDL is just a nice-to-have. Right now, nothing is an input, making the task always up to date (I added a test for this), and also leading to gradle considering any output for any instance of the task as a valid build cache entry for any other (if the user enables caching). Please reconsider, or find an alternative fix for #7 that allows the plugin to set the arguments before executing (IOW: so they are considered to be inputs by gradle).
@ciscoo to be clear: nothing in terms of the api of wsdl2java
changed.
@pschyska it has been reverted and gh-7 reopened. The test you added to check for the tasks inputs always being up to date, could you raise a separate PR just for that test?
Hey, that's my attempt for #13 The tests now run and I added 2 new tests (incremental builds for any input, e.g. WSDLOption properties, for changes in the WSDL and for changes just in referenced XSDs).
I pulled task registration and sourceSet modification in the extension to be able to remove the setArgs extra task action, while hopefully preventing #7. As I mentioned earlier, I couldn't get
wsdl2java.configure
creating aWSDLOption
element to work properly in the Groovy DSL. Likewise, in manual testingwsdl2java.configureAll
doesn't work correctly, however e.g.wsdl2java.all { markGenerated = true }
does work. I never used the Groovy DSL though, so I don't know what's idiomatic. I think that belongs together as otherwise, the task would react just on changes in the WSDLs. Changing any other options would not trigger an incremental rebuild, and the cache key for the build cache will still be wrong (e.g. markGenerated = false and markGenerated = true would have the same cache key, so if the build cache is used you always get the same code, depending on the option set during the first build).Please take a look.