Hi Jeff, Thanks for merging in the code! I had some laptop problems today (I will need to send it back for repairs again!) so I did not get a chance to do the merge myself. Working from the git repository is fine with me. I will work on finishing the refactoring of the code and I will get the rest of the unit tests passing again. After that I will take a look at merging in the svn trunk changes as well. Perhaps I will try the git svn rebase command to see if that can help automate some of the merges. I was also thinking about moving the dao-test module into the bpel-test one and then configuring the surefire plugin to run multiple times per dao implementation. This way most of the integration tests are centrally located in one module. What do you think?
Cheers, Aaron ________________________________ From: Jeff Yu <jeff.yuch...@gmail.com> To: dev@ode.apache.org Sent: Tue, March 9, 2010 2:40:29 AM Subject: Re: JPA DAO refactoring. Hi Aaron, comments inline. On Mon, Mar 8, 2010 at 3:28 PM, Aaron Anderson <aaronander...@acm.org>wrote: > Hi Jeff, > > I committed my changes to my github fork at > http://github.com/aaronanderson/ode/tree/jpa Please take a look at it and > let me know what you think. Here are some notes on what I did: > > 1) Moved the bpel-store DAO interfaces, JPA, and hibernate classes into > their respective modules > +1, Now it looks much cleaner when I look into the bpel-store module, also look into the bpel-store's dependency, no more dependencies on the impl, great. > 2) Updated the DAO package names to divide the DAO interfaces in a > consistent fashion > +1 > 3) Introduced the DAOConnectionFactory interface to use a common DAO > factory instantiation pattern across implementations. > > 4) Moved all the DAO test cases to a new single module, dao-test. This > artifact is extracted to each of the three DAO implementation (hibernate, > hibernate JPA, and OpenJPA) at test time. This allows for good test case > coverage for each of the implementations without unit test redundancy. > Instead of introducing a new module these test cases could be moved to > bpel-dao and a maven test classifer used to archive them instead. > I also agreed that we have a new module, as you did. It is cleaner than having it in the bpel-dao module. > 5) All the test cases pass except for a couple of DAO tests for both > hibernate and hibernate JPA. Engine passes all the tests with OpenJPA. I'll > look into the two failed test cases early this week > Great. > 6) I have not run the hibernate DAO implementations with the engine yet but > I did not need to tweak too many of the JPA classes in order for it to load > in Hibernate 3.4.0GA. > 6) I can get started on moving the simple scheduler DAO code into the > implementation modules once the JPA changes stabilize. > +1. I think at this stage, It is better that we make sure all of our changes didn't broke the build, all of tests should passed etc, before we move to refactor the scheduler DAO, it would be easy for us to find the problem, what do you think? As of now, I see following issues or tasks that we need to do. 1. It seems to me that we haven't refactored the axis2-war test case code, as it still refers to the org.apache.ode.bpel.dao.BpelDAOConnection class, which is already been updated into a new package. 2. the dao-hibernate-db module build failed. 3. Need to deploy the distribution into Tomcat, ServiceMix to see if it works or not. Overall, This is a great step forward, I am thinking that can we work on one git repo, so that we can avoid conflicts, and we also need to merge the updates from Apache ode's repo, so it can be applied back to apache ode svn more easily? Regards Jeff -- Cheers, Jeff Yu ---------------- blog: http://jeff.familyyu.net
