I like the high level concept here. Since the "source" for Kuali Rice is the java code checked into SCM and the WSDL's are a "secondary" generated artifact, keeping the java source code checked into SCM and deploying WSDL's as an artifact to a Maven repository would be considered a better CM concept than checking generated WSDL's into SCM.
There are WSDL's currently being published as part of the build process http://s3browse.springsource.com/browse/maven.kuali.org/snapshot/org/kuali/rice/rice-core-api/2.0.0-m7-SNAPSHOT/
What we want to try and do here is take better advantage of the Maven build lifecycle. The maven-s3-wagon (that is already integrated into the the Rice pom) can handle transport layer duties for getting build artifacts into an s3 backed Maven repository. There is also already build logic in place to correctly select SNAPSHOT vs RELEASE repositories.
Maven needs to be informed that WSDL's should be formally attached as artifacts of the build process. Once Maven has been informed of that, transporting the WSDL artifacts to the correct Maven repository will be handled automatically for us (just like .jars or .wars).
One thing to look at would be the "attachWsdl" flag from the cxf-codegen-plugin and/or the build-helper-maven-plugin (http://mojo.codehaus.org/build-helper-maven-plugin/attach-artifact-mojo.html). Taking advantage of one (or both?) of those would be a more correct build concept than using Groovy to shell out to the command line to iteratively invoke the maven-deploy plugin.