Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0
    • Component/s: Modularity
    • Labels:
      None
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      This work is designed to push some of the common development support code into it's own module. This code includes test harnesses, lifecycles, embedded jetty, etc. By doing this the rice impl module will decrease it's dependency footprint and will in general make it easier to manage dependencies especially regarding the support of multiple servlet containers.

      The hardest part in regards to creating this module is removing all dependencies on other rice code. Having these dependencies would cause a cycle.

        Attachments

          Activity

          Hide
          tschneeb Travis Schneeberger added a comment -

          whoa! what a rats nest... We will feel some pain with even this relatively simple task. Then again modularity is never easy which is why it usually gets put off till later

          Show
          tschneeb Travis Schneeberger added a comment - whoa! what a rats nest... We will feel some pain with even this relatively simple task. Then again modularity is never easy which is why it usually gets put off till later
          Hide
          ewestfal Eric Westfall added a comment -

          Yes, agreed. Before you get too far down this path, you, Garey, and I should talk. I've been working on putting together a document describing how modules will be broken down in rice so i want to make sure we stay true to form here (or alter our strategy to produce what we need). I haven't had a chance to finish this yet, and my analysis for specific modules has not been integrated here yet, but please take a look at this:

          https://wiki.kuali.org/display/KULRICE/Rice+1.1+-+Modularity+Design

          I believe what we are talking about here is what I am labelling a framework component, in which case it might consist of multiple modules (or just one module if that makes sense, but it seems like we could separate dev tools from the test harness and that seems like a logical separation to me)

          Show
          ewestfal Eric Westfall added a comment - Yes, agreed. Before you get too far down this path, you, Garey, and I should talk. I've been working on putting together a document describing how modules will be broken down in rice so i want to make sure we stay true to form here (or alter our strategy to produce what we need). I haven't had a chance to finish this yet, and my analysis for specific modules has not been integrated here yet, but please take a look at this: https://wiki.kuali.org/display/KULRICE/Rice+1.1+-+Modularity+Design I believe what we are talking about here is what I am labelling a framework component, in which case it might consist of multiple modules (or just one module if that makes sense, but it seems like we could separate dev tools from the test harness and that seems like a logical separation to me)
          Hide
          tschneeb Travis Schneeberger added a comment -

          Eric, this module would consist of the JettyServer components & anything under org.kuali.rice.test.* This would help remove all those pesky compile time dependencies on Jetty, junit, htmlunit, etc. which right now get packaged in a client app's war unless you specifically do something rather hackish to exclude them.

          There are two possible ways I see this working:

          1) this new devsupport module cannot depend on any other rice module. This would allow all rice modules to use devsupport for their test frameworks. This is highly impacting as all the rice references would have to be removed
          2) this new devsupport module would depend on the impl module. This impl module could not then depend on the devsupport module for unit testing purposes. Any existing impl tests that do would have to be either rewritten or moved to another module (maybe kns?). This isn't so impacting so I think this might be the best choice.

          BTW. if we go with option 2) we can still do option 1) at a later date is so desired.

          Thoughts?

          Show
          tschneeb Travis Schneeberger added a comment - Eric, this module would consist of the JettyServer components & anything under org.kuali.rice.test.* This would help remove all those pesky compile time dependencies on Jetty, junit, htmlunit, etc. which right now get packaged in a client app's war unless you specifically do something rather hackish to exclude them. There are two possible ways I see this working: 1) this new devsupport module cannot depend on any other rice module. This would allow all rice modules to use devsupport for their test frameworks. This is highly impacting as all the rice references would have to be removed 2) this new devsupport module would depend on the impl module. This impl module could not then depend on the devsupport module for unit testing purposes. Any existing impl tests that do would have to be either rewritten or moved to another module (maybe kns?). This isn't so impacting so I think this might be the best choice. BTW. if we go with option 2) we can still do option 1) at a later date is so desired. Thoughts?
          Hide
          tschneeb Travis Schneeberger added a comment -

          Oh and btw. How a client app would use this new module is probably for testing purposes in which case they would put this at test scope (ie. no packaging in war, no massive list of excludes from rice dep - all is good

          Show
          tschneeb Travis Schneeberger added a comment - Oh and btw. How a client app would use this new module is probably for testing purposes in which case they would put this at test scope (ie. no packaging in war, no massive list of excludes from rice dep - all is good
          Hide
          tschneeb Travis Schneeberger added a comment - - edited

          some more promising findings related to rice war libraries:

          rice 1.1 as it is now = 129 libraries packaged in war
          rice 1.1 after creating devsupport module = 120 libraries packaged in war

          I have not figured out which libs are no longer being packaged yet. I'm guessing the difference is probably that some of the transitive dependencies only needed by our testing libraries are no longer being packaged.

          A simple (not verified) example: We had code (test harness stuff) in our main impl (non test) codebase that used htmlunit. Htmlunit has a dependency on a javascript library. This javascript library is a transitive dependency of rice (a dependency's dependency). Now we knew that htmlunit should not get packaged in the final rice war so we employed a hack in the war packaging step to exclude htmlunit. What we did not do is exclude htmlunit's transitive dependencies from being packaged. So they got included even though they were not used by rice production code. The other thing these test only dependencies did to complicate things is they could have a negative affect on the way maven resolves dependencies. I won't bother explaining this one in jira but we can talk about it. In addition they also force themselves on client app (just take a look at how complicated KC's pom is because of these types of problems in rice).

          Show
          tschneeb Travis Schneeberger added a comment - - edited some more promising findings related to rice war libraries: rice 1.1 as it is now = 129 libraries packaged in war rice 1.1 after creating devsupport module = 120 libraries packaged in war I have not figured out which libs are no longer being packaged yet. I'm guessing the difference is probably that some of the transitive dependencies only needed by our testing libraries are no longer being packaged. A simple (not verified) example: We had code (test harness stuff) in our main impl (non test) codebase that used htmlunit. Htmlunit has a dependency on a javascript library. This javascript library is a transitive dependency of rice (a dependency's dependency). Now we knew that htmlunit should not get packaged in the final rice war so we employed a hack in the war packaging step to exclude htmlunit. What we did not do is exclude htmlunit's transitive dependencies from being packaged. So they got included even though they were not used by rice production code. The other thing these test only dependencies did to complicate things is they could have a negative affect on the way maven resolves dependencies. I won't bother explaining this one in jira but we can talk about it. In addition they also force themselves on client app (just take a look at how complicated KC's pom is because of these types of problems in rice).
          Hide
          tschneeb Travis Schneeberger added a comment -

          I'm gonna see how easy it would be to create a profile to switch up jetty versions next so we can finally test against different app servers. BTW. If we really wanted the ultimate flexibility in testing with different app servers we would just delete the JettyServer altogether and just use maven plugin's to launch jetty, tomcat, whatever. We are a long way from that and their are downsides to doing that. I look at this effort as a step in the right direction but maybe not the final best solution possible...baby steps

          Show
          tschneeb Travis Schneeberger added a comment - I'm gonna see how easy it would be to create a profile to switch up jetty versions next so we can finally test against different app servers. BTW. If we really wanted the ultimate flexibility in testing with different app servers we would just delete the JettyServer altogether and just use maven plugin's to launch jetty, tomcat, whatever. We are a long way from that and their are downsides to doing that. I look at this effort as a step in the right direction but maybe not the final best solution possible...baby steps
          Hide
          tschneeb Travis Schneeberger added a comment -

          the new module has been created. I'm sure there is more work to be done but separate jiras can be created for this.

          Show
          tschneeb Travis Schneeberger added a comment - the new module has been created. I'm sure there is more work to be done but separate jiras can be created for this.

            People

            • Assignee:
              tschneeb Travis Schneeberger
              Reporter:
              tschneeb Travis Schneeberger
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: