Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-9568

After modules have been converted, remove OJB dependency from POM files

    Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 2.6
    • Component/s: Development, JPA, Roadmap
    • Security Level: Public (Public: Anyone can view)
    • Labels:
    • Similar issues:
      KULRICE-9650Remove OJB dependencies from DatabasePlatform
      KULRICE-2617If possible, remove dependencies on tomcat jasper libraries from Rice pom file
      KULRICE-3473merge-module-classpaths ant target doesn't work anymore as groovy files have been removed from scripts/
      KULRICE-3628use provided scope for dependencies where applicable in POM
      KULRICE-11695Run dependency analysis on different rice modules and address any dependency issues
      KULRICE-11287Remove BusinessObjectEntry from converted objects
      KULRICE-3899Fix the xapool jar, pom and classpath issues
      KULRICE-9537Document the approach for conversion to krad-data of the various internal Rice modules
      KULRICE-3722Get rid of the need to have the oracle jdbc driver as a dependency in our pom
      KULRICE-1696Remove the displaytag properties file from the KEW module
    • Sprint:
      2.4.0-rc1 Sprint 2, 2.4.0-rc1 Sprint 3, 2.4.0-rc1 Sprint 4, 2.4.0-rc1 Sprint 5, 2.4.0-rc1 Sprint 6, 2.4.0-rc1 Sprint 7
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      Once the modules are converted, they should no longer require dependencies on OJB.

        Activity

        Hide
        Eric Westfall added a comment -

        I ended up doing some work on this awhile back and had it sitting locally. Merged trunk in and committed to this branch for future work so we don't have to start over:

        https://svn.kuali.org/repos/rice/sandbox/KULRICE-9568

        Show
        Eric Westfall added a comment - I ended up doing some work on this awhile back and had it sitting locally. Merged trunk in and committed to this branch for future work so we don't have to start over: https://svn.kuali.org/repos/rice/sandbox/KULRICE-9568
        Hide
        Eric Westfall added a comment -

        I don't think it's safe to do all of the work required for this right now, and we may actually want to wait anyway until we convert the screens off of the KNS. There are a few reasons why I think we need to defer this to 2.5:

        1) Essentially this project involves anything and everything related to OJB to be moved out to legacy modules. As part of the branch above I created a new core-legacy module to move out the old OJB stuff from the core. I really don't think it's going to be possible to just merge the branch above into trunk when we are ready to reapproach this issue. There were a lot of files moved and I think the general process needs to be started from the beginning to be safest.

        2) PersistableBusinessObjectBase right now implements PersistenceBrokerAware which is a bit of a problem since that class is still in KRAD (not KNS because of compatibility issues with moving it). I implemented a solution to this on the aforementioned branch which essentially involves removing this PersistenceBrokerAware interface, and writing an OJB-specific class which detects if it's a PBOB or implements PersistenceBrokerAware and handles appropriately. On the branch, see JpaLifecycleAwarePersistenceBrokerTemplate and JpaToOjbLifecycleAdapterListener for examples of how I did this. The problem with this solution though is that it's not great because it requires the client application to do something to use it. A better solution would probably be to figure out how to move PersistenceBusinessObjectBase to the KNS (so that it can just go ahead and depend on OJB) or do a patch of some kind to OJB to make a version which is aware of the various JPA persistence annotations (@PrePersist, etc.). If we get rid of the existing KNS-based UI internal to Rice, then it should be easy for us to move PersistableBusinessObjectBase.

        3) We still have a lot of KNS-based screens which have to depend on the KNS. KNS has to depend on OJB. We don't have separate "web" modules for everything and we still have that annoying shared impl module. One way around this would be to make sure that OJB is declared optional everywhere and only include an explicit dependency on it in KNS and the various modules that assemble standalone, etc. together. Better solution would be just to convert everything internal off of KNS for the core modules (I know we want to have at least some sample app behavior around that tests KNS, but with a KNS dependency in only that sample app we should be ok).

        I think the end result here is that the krad sample app and rice standalone wars should not need to have a copy of the OJB jar in there WEB-INF/lib. In order to get there, we have to convert all of the screens. And when we do that, we'll also want to make sure that we remove all Struts dependencies as well (plus any related transitive dependencies like displaytag).

        Show
        Eric Westfall added a comment - I don't think it's safe to do all of the work required for this right now, and we may actually want to wait anyway until we convert the screens off of the KNS. There are a few reasons why I think we need to defer this to 2.5: 1) Essentially this project involves anything and everything related to OJB to be moved out to legacy modules. As part of the branch above I created a new core-legacy module to move out the old OJB stuff from the core. I really don't think it's going to be possible to just merge the branch above into trunk when we are ready to reapproach this issue. There were a lot of files moved and I think the general process needs to be started from the beginning to be safest. 2) PersistableBusinessObjectBase right now implements PersistenceBrokerAware which is a bit of a problem since that class is still in KRAD (not KNS because of compatibility issues with moving it). I implemented a solution to this on the aforementioned branch which essentially involves removing this PersistenceBrokerAware interface, and writing an OJB-specific class which detects if it's a PBOB or implements PersistenceBrokerAware and handles appropriately. On the branch, see JpaLifecycleAwarePersistenceBrokerTemplate and JpaToOjbLifecycleAdapterListener for examples of how I did this. The problem with this solution though is that it's not great because it requires the client application to do something to use it. A better solution would probably be to figure out how to move PersistenceBusinessObjectBase to the KNS (so that it can just go ahead and depend on OJB) or do a patch of some kind to OJB to make a version which is aware of the various JPA persistence annotations (@PrePersist, etc.). If we get rid of the existing KNS-based UI internal to Rice, then it should be easy for us to move PersistableBusinessObjectBase. 3) We still have a lot of KNS-based screens which have to depend on the KNS. KNS has to depend on OJB. We don't have separate "web" modules for everything and we still have that annoying shared impl module. One way around this would be to make sure that OJB is declared optional everywhere and only include an explicit dependency on it in KNS and the various modules that assemble standalone, etc. together. Better solution would be just to convert everything internal off of KNS for the core modules (I know we want to have at least some sample app behavior around that tests KNS, but with a KNS dependency in only that sample app we should be ok). I think the end result here is that the krad sample app and rice standalone wars should not need to have a copy of the OJB jar in there WEB-INF/lib. In order to get there, we have to convert all of the screens. And when we do that, we'll also want to make sure that we remove all Struts dependencies as well (plus any related transitive dependencies like displaytag).
        Hide
        Eric Westfall added a comment -

        Also, forgot to mention the other end result here is that a KRAD-based application should be able to function with 0 dependencies on either KNS or OJB. I think there are perhaps some other issues here right now such that KRAD might not work properly without the KNS jar on the classpath (i.e. the spring beans loaded by KRAD load some classes from the KNS module), but we need to confirm that and, if so, fix that up as well.

        Show
        Eric Westfall added a comment - Also, forgot to mention the other end result here is that a KRAD-based application should be able to function with 0 dependencies on either KNS or OJB. I think there are perhaps some other issues here right now such that KRAD might not work properly without the KNS jar on the classpath (i.e. the spring beans loaded by KRAD load some classes from the KNS module), but we need to confirm that and, if so, fix that up as well.

          People

          • Assignee:
            Eric Westfall
            Reporter:
            Eric Westfall
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Time Tracking

              Estimated:
              Original Estimate - 1 day
              1d
              Remaining:
              Remaining Estimate - 4 hours
              4h
              Logged:
              Time Spent - Not Specified Time Not Required
              Not Specified

                Agile

                  Structure Helper Panel