[KULRICE-4660] Determine WSDL publishing process Created: 06/Oct/10  Updated: 06/Jun/14  Resolved: 20/Jan/12

Status: Closed
Project: Kuali Rice Development
Component/s: Configuration Management, Version Compatibility
Affects Version/s: None
Fix Version/s: 2.0.0-rc1, 2.0

Type: Task Priority: Critical
Reporter: Matt Sargent Assignee: Jeff Caddel (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 2 days
Time Spent: Not Specified
Original Estimate: 2 days

KAI Review Status: Not Required
KTI Review Status: Not Required


Decide if we will commit generated WSDL to source control, and if so, come up with a process for it

Comment by Jason Whaley (Inactive) [ 30/Mar/11 ]

Adding a couple of potential requirements to this if we decide to do it:

  • This should be done as part of final releases only
  • The process for committing the wsdls with a relase should be fully automated (e.g. something that is invoked alongside the maven release plugin
Comment by Jason Whaley (Inactive) [ 14/Jun/11 ]

One thought on this - instead of committing to source control, why not deploy an archive of .wsdls as well as each individual .wsdl for each final release to the rice maven repository.

With CXF's codegen plugin for maven - you can pull .wsdls down from a maven repository directly (see http://cxf.apache.org/docs/maven-cxf-codegen-plugin-wsdl-to-java.html and the section named "Loading a wsdl from the maven repository).

Comment by Rice-CI User (Inactive) [ 14/Jul/11 ]

Integrated in rice-trunk-nightly #117 (See http://ci.rice.kuali.org/job/rice-trunk-nightly/117/)
KULRICE-4660: .wsdl files included in jars for api modules

Comment by Jason Whaley (Inactive) [ 18/Jul/11 ]

The HEAD of https://test.kuali.org/svn/rice/sandbox/KULRICE-4660 has a working module that deploys all wsdl files to an s3 backed maven repository. The name of that module is dist-wsdl. When the deploy goal is ran on this module, it looks for all wsdls found in the project's API modules and runs `mvn deploy:deploy-file` on each of them individually.

This allows each wsdl file for each version of rice to be stored in maven and implicitly published, versioned, and archived (since it is on s3).

Also, the wsdl files can be pulled down by the cxf codegen plugin by doing the following in another pom that wishes to implement the client side or server side of that wsdl:

Comment by Jason Whaley (Inactive) [ 18/Jul/11 ]

Assigning to Jeff just for him to take a look at present work and provide feedback. Assign back to me when done.

Comment by Jeff Caddel (Inactive) [ 18/Jul/11 ]

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.

Comment by Jeremy Hanson [ 23/Aug/11 ]

Jeff, is this something that should be handled by you guys?

Comment by Jessica Coltrin (Inactive) [ 03/Oct/11 ]

Meeting with Jeff on this one and yes, this is something they would do. Assuming this can be done during beta.

Comment by Jessica Coltrin (Inactive) [ 08/Nov/11 ]

moving all non-critical or blocker jiras from 2.0.0-b2 to 2.0.0-b3 due to the short time frame for b2 & KD taking up one of the two weeks.

Comment by Jeff Caddel (Inactive) [ 20/Jan/12 ]

Added build-helper-maven-plugin executions that attach the wsdl's generated by the cxf plugin as official build artifacts.

The wsdl's are now published and versioned just like any other build artifact and can be referenced via Maven's dependency mechanism.

For example the wsdl's for Rice KIM API get published here:

The wsdl for the KIM API Identity Service can be referenced as a Maven dependency like this:

Comment by Jessica Coltrin (Inactive) [ 23/Feb/12 ]

Closing since these items are now in the release notes.

Generated at Mon Apr 12 08:44:14 CDT 2021 using JIRA 7.0.11#70121-sha1:19d24976997c1d95f06f3e327e087be0b71f28d4.