Details

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

      Description

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

        Attachments

          Issue Links

            Activity

            jcoltrin Jessica Coltrin (Inactive) created issue -
            jjhanso Jeremy Hanson made changes -
            Field Original Value New Value
            Assignee Jason Whaley [ jwhaley ]
            Hide
            jwhaley Jason Whaley (Inactive) added a comment -

            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
            Show
            jwhaley Jason Whaley (Inactive) added a comment - 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
            Hide
            jwhaley Jason Whaley (Inactive) added a comment - - edited

            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).

            Show
            jwhaley Jason Whaley (Inactive) added a comment - - edited 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).
            jjhanso Jeremy Hanson made changes -
            Fix Version/s 2.0.0-m6 [ 16287 ]
            jjhanso Jeremy Hanson made changes -
            Start Date
            Fix Date 2012-07-11 [ set to sprint end date ]
            Hide
            riceci Rice-CI User (Inactive) added a comment -

            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

            Show
            riceci Rice-CI User (Inactive) added a comment - 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
            ewestfal Eric Westfall made changes -
            Fix Version/s 2.0.0-m7 [ 16314 ]
            Fix Version/s 2.0.0-m6 [ 16287 ]
            ewestfal Eric Westfall made changes -
            Start Date
            Fix Date 2012-07-11 2011-08-08 [ set to sprint end date ]
            Hide
            jwhaley Jason Whaley (Inactive) added a comment -

            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:

                    <plugin>
                            <groupId>org.apache.cxf</groupId>
                            <artifactId>cxf-codegen-plugin</artifactId>
                            <version>2.4.1</version>
                            <executions>
                                <execution>
                                    <id>generate-sources</id>
                                    <phase>generate-sources</phase>
                                    <configuration>
                                        <wsdlOptions>
                                            <wsdlOption>
                                                <wsdlArtifact>
                                                    <groupId>org.kuali.rice</groupId>
                                                    <artifactId>CampusService.wsdl</artifactId>
                                                    <version>2.0.0-m7-SNAPSHOT</version>
                                                </wsdlArtifact>
                                            </wsdlOption>
                                        </wsdlOptions>
                                    </configuration>
                                    <goals>
                                        <goal>wsdl2java</goal>
                                    </goals>
                                </execution>
                            </executions>
                        </plugin>
            
            Show
            jwhaley Jason Whaley (Inactive) added a comment - 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: <plugin> <groupId> org.apache.cxf </groupId> <artifactId> cxf-codegen-plugin </artifactId> <version> 2.4.1 </version> <executions> <execution> <id> generate-sources </id> <phase> generate-sources </phase> <configuration> <wsdlOptions> <wsdlOption> <wsdlArtifact> <groupId> org.kuali.rice </groupId> <artifactId> CampusService.wsdl </artifactId> <version> 2.0.0-m7-SNAPSHOT </version> </wsdlArtifact> </wsdlOption> </wsdlOptions> </configuration> <goals> <goal> wsdl2java </goal> </goals> </execution> </executions> </plugin>
            Hide
            jwhaley Jason Whaley (Inactive) added a comment -

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

            Show
            jwhaley Jason Whaley (Inactive) added a comment - Assigning to Jeff just for him to take a look at present work and provide feedback. Assign back to me when done.
            jwhaley Jason Whaley (Inactive) made changes -
            Assignee Jason Whaley [ jwhaley ] Jeff Caddel [ jcaddel ]
            Hide
            jcaddel Jeff Caddel (Inactive) added a comment - - edited

            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.

            Show
            jcaddel Jeff Caddel (Inactive) added a comment - - edited 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.
            jcaddel Jeff Caddel (Inactive) made changes -
            Assignee Jeff Caddel [ jcaddel ] Jason Whaley [ jwhaley ]
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Fix Version/s 2.0.0-m8 [ 16326 ]
            Fix Version/s 2.0.0-m7 [ 16314 ]
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Start Date
            Fix Date 2011-08-08 2011-09-05 [ set to sprint end date ]
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Component/s Configuration Management [ 13470 ]
            jjhanso Jeremy Hanson made changes -
            Assignee Jason Whaley [ jwhaley ] Travis Schneeberger [ tschneeb ]
            Hide
            jjhanso Jeremy Hanson added a comment -

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

            Show
            jjhanso Jeremy Hanson added a comment - Jeff, is this something that should be handled by you guys?
            jjhanso Jeremy Hanson made changes -
            Assignee Travis Schneeberger [ tschneeb ] Jeff Caddel [ jcaddel ]
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Fix Version/s 2.0.0-m9 [ 16327 ]
            Fix Version/s 2.0.0-m8 [ 16326 ]
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Start Date
            Fix Date 2011-09-05 2011-10-10 [ set to sprint end date ]
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Summary Determine process to commit generated WSDL Determine WSDL publishing process
            Hide
            jcoltrin Jessica Coltrin (Inactive) added a comment -

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

            Show
            jcoltrin Jessica Coltrin (Inactive) added a comment - Meeting with Jeff on this one and yes, this is something they would do. Assuming this can be done during beta.
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Rice Lead jcaddel
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Rice Lead jcaddel jjhanso
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Rice Lead jjhanso jcaddel
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Fix Version/s 2.0.0-b1 [ 16315 ]
            Fix Version/s 2.0.0-m9 [ 16327 ]
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Start Date
            Fix Date 2011-10-10 2011-11-07 [ set to sprint end date ]
            jjhanso Jeremy Hanson made changes -
            Fix Version/s 2.0.0-b2 [ 16371 ]
            Fix Version/s 2.0.0-b1 [ 16315 ]
            jjhanso Jeremy Hanson made changes -
            Start Date
            Fix Date 2011-11-07 [ set to sprint end date ]
            Hide
            jcoltrin Jessica Coltrin (Inactive) added a comment -

            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.

            Show
            jcoltrin Jessica Coltrin (Inactive) added a comment - 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.
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Fix Version/s 2.0.0-b3 [ 16375 ]
            Fix Version/s 2.0.0-b2 [ 16371 ]
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Start Date
            Fix Date 2011-12-05 [ set to sprint end date ]
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Fix Version/s 2.0.0-b3 [ 16375 ]
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Fix Version/s 2.0.0-b5 [ 16377 ]
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Start Date
            Fix Date 2011-12-05 2012-01-09 [ set to sprint end date ]
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Fix Version/s 2.0.0-rc1 [ 16378 ]
            Fix Version/s 2.0.0-b5 [ 16377 ]
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Start Date
            Fix Date 2012-01-09 2012-01-23 [ set to sprint end date ]
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Priority Major [ 3 ] Critical [ 2 ]
            Hide
            jcaddel Jeff Caddel (Inactive) added a comment - - edited

            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:
            http://s3browse.springsource.com/browse/maven.kuali.org/snapshot/org/kuali/rice/rice-kim-api/2.0.0-rc1-SNAPSHOT/

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

            <dependency>
             <groupId>org.kuali.rice</groupId>
             <artifactId>rice-kim-api</artifactId>
             <version>2.0.0-rc1-SNAPSHOT</version>
             <classifier>IdentityService</classifier>
             <type>wsdl</type>
            </dependency>
            
            Show
            jcaddel Jeff Caddel (Inactive) added a comment - - edited 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: http://s3browse.springsource.com/browse/maven.kuali.org/snapshot/org/kuali/rice/rice-kim-api/2.0.0-rc1-SNAPSHOT/ The wsdl for the KIM API Identity Service can be referenced as a Maven dependency like this: <dependency> <groupId>org.kuali.rice</groupId> <artifactId>rice-kim-api</artifactId> <version>2.0.0-rc1-SNAPSHOT</version> <classifier>IdentityService</classifier> <type>wsdl</type> </dependency>
            jcaddel Jeff Caddel (Inactive) made changes -
            Status Open [ 1 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            Hide
            jcoltrin Jessica Coltrin (Inactive) added a comment -

            Closing since these items are now in the release notes.

            Show
            jcoltrin Jessica Coltrin (Inactive) added a comment - Closing since these items are now in the release notes.
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Status Resolved [ 5 ] Closed [ 6 ]
            spatterson Shem Patterson (Inactive) made changes -
            Workflow custom [ 87141 ] Copy of custom for rice [ 212288 ]
            spatterson Shem Patterson (Inactive) made changes -
            Workflow Copy of custom for rice [ 212288 ] custom [ 222036 ]
            spatterson Shem Patterson (Inactive) made changes -
            Workflow custom [ 222036 ] Rice Workflow [ 231784 ]
            spatterson Shem Patterson (Inactive) made changes -
            Reporter Jessica Coltrin [ jcoltrin ] Matt Sargent [ masargen ]

              People

              • Assignee:
                jcaddel Jeff Caddel (Inactive)
                Reporter:
                masargen Matt Sargent
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - 2 days
                  2d
                  Remaining:
                  Remaining Estimate - 2 days
                  2d
                  Logged:
                  Time Spent - Not Specified
                  Not Specified