catch-22 problem

[jarl-dk]

It is not clear from the documentation what is the intended usage, but I expect is is supposed to generate java files prior to the java compilation task.

However experimenting with https://github.com/Grails-Plugin-Consortium/grails-cxf-client-demo I first wonder why the generated java files are checked in. However when trying to recreate the java files (from wsdl) by first deleting the deletede java files:

rm -rf src/main/java/cxf/client

Then recreate them with:

./gradlew wsdltojava

However causes erros because gradle tries to compile the source code first. Then I try to force a task dependency with

echo "compileJava.dependsOn wsdlToJava" >> build.gradle

But that causes a cyclic task dependency.

To me this plugin seem to have a catch-22 problem: Since it requires the clientInterface java file to be able to create it.

It would be so much convincing if the generated java files was not checked-in in https://github.com/Grails-Plugin-Consortium/grails-cxf-client-demo

[ctoestreich]

There may have been a loss in execution order when moving to grade task from old grails command.  I will look at it this weekend.

Sent from Yahoo Mail on Android

On Fri, Mar 25, 2016 at 15:59, Jarl Friisnotifications@github.com wrote:
It is not clear from the documentation what is the intended usage, but I expect is is supposed to generate java files prior to the java compilation task.

However experimenting with https://github.com/Grails-Plugin-Consortium/grails-cxf-client-demo I first wonder why the java files are checked in. However when trying to recreate the java files (from wsdl) by first deleting the deletede java files: rm -rf src/main/java/cxf/client

Then recreate them with: ./gradlew wsdltojava

However causes erros because gradle tries to compile the source code first. Then I try to force a task dependency with echo "compileJava.dependsOn wsdlToJava" >> build.gradle

But that causes a cyclic task dependency.

To me this plugin seem to have a catch-22 problem: Since it requires the clientInterface java file to be able to create it.

It would be so much convincing if the generated java files was not checked-in in https://github.com/Grails-Plugin-Consortium/grails-cxf-client-demo

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub

[jarl-dk]

Any news here?

[ctoestreich]

I released a new branch for client https://github.com/Grails-Plugin-Consortium/grails-cxf-client-demo/tree/no-cxf-services-only-clients that doesn't depend on any internal services

Also I patched the plugin to 3.0.7 to check the clientInterface param and not to try and wire beans (which is hard error) when the clientInterface doesn't resolve to a class. this will allow the wsdl2java to run when the interface doesn't exist.

Also you will need to make sure you use def fooClient instead of FooClientSoap fooClient when using client where you don't have any code as this static typing will not work until after the soap interface has been created.

Cheers!

[jarl-dk]

The demo (on branch no-cxf-services-only-clients) still compiles the groovy sources before generating the source code for the WSDL, so I get:

$ ./gradlew wsdlToJava
:compileJava UP-TO-DATE
:compileGroovy
startup failed:
/home/jarl/projects/grails-cxf-client-demo/grails-app/controllers/com/cxf/demo/DemoController.groovy: 3: unable to resolve class net.webservicex.ICD9Soap
 @ line 3, column 1.
   import net.webservicex.ICD9Soap
   ^

1 error

:compileGroovy FAILED

Anyway any real-life project will have source code using (importing) the generated classes. I don't understand why you have removed all these files in the no-cxf-services-only-clients branch. It does not reflect any real-life situation. You should only remove src/main/java/cxf/client, that is the directory of the generated sources, right?

The point is: The build-dependencies is buggy and therefore it tries to compile groovy code before it has generated the sources from the wsdl.

[jarl-dk]

Also I patched the plugin to 3.0.7 to check the clientInterface param and not to try and wire beans (which is hard error) when the clientInterface doesn't resolve to a class. this will allow the wsdl2java to run when the interface doesn't exist.

IMHO, this is not optimal use of a build system like gradle. Gradle is good at handling build-dependencies and from that information compute propper build order for those steps that needs to be built. You should exploit these features of gradle more instead of implementing "check the clientInterface param and not to try and wire beans" yourself.

[ctoestreich]

The import was a line that I accidentally left in. It should have been removed. The other issue you feel is buggy is mostly due to how grails leverages the new cross grails-gradle command objects.

Regarding your concern with the client interface change, this is outside the scope of grade as grails will do a bootstrap on the project so as to get all the included plugins loaded and application context wired. The error was coming from grails, not gradle, due to trying to locate the class specified in the client interface config.

Once grails is loaded up the gradle portion fires the WsdlToJava gradle target via the WsdlToJavaCommand class in grails.

If you know of a better way to include this wsdltojava command for the plugin I am happy to take a pull request. This command isn't needed if you want to create a gradle task in your own project to generate your code. I found this one here that looks like it would work great https://github.com/nilsmagnus/wsdl2java

I simply included the script as a convenience to those not wanting to wire up the actual gradle code themselves.