[KULRICE-9568] After modules have been converted, remove OJB dependency from POM files Created: 17/May/13  Updated: 16/Jan/15

Status: Open
Project: Kuali Rice Development
Component/s: Development, JPA, Roadmap
Affects Version/s: None
Fix Version/s: 2.6
Security Level: Public (Public: Anyone can view)

Type: Improvement Priority: Critical
Reporter: Eric Westfall Assignee: Eric Westfall
Resolution: Unresolved Votes: 0
Labels: Old
Remaining Estimate: 4 hours
Time Spent: Not Specified
Original Estimate: 1 day

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.



 Comments   
Comment by Eric Westfall [ 12/Feb/14 ]

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

Comment by Eric Westfall [ 08/Apr/14 ]

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

Comment by Eric Westfall [ 08/Apr/14 ]

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.

Generated at Tue Sep 22 19:43:07 CDT 2020 using JIRA 7.0.11#70121-sha1:19d24976997c1d95f06f3e327e087be0b71f28d4.