Hi Jeff, Thanks for the feedback!
1. I will do a checkout and a clean build and install on a different machine to make sure I don t have any maven modules cached on my dev machine. The SQLNonTransientConnectionException class was added in JDK 1.6. Since Sun EOL d 1.5 last fall so I assumed the trunk was dependent on 1.6. I will make the needed changes to make sure 1.5 works as well. 2. That is strange. A top level mvn clean install worked for me and should have caught this. Maybe it was a problem with my windows git client. I ll fix this. 3. That makes sense. Il-common is a better place for it. 4. I haven t tried H2 yet, just Hsql and derby. I had a couple of problems with hsql and blobs and sequences so I switched to derby. H2 might be a better choice since it is lighter weight and has a more mature in memory implementation. Sorry about the build problems, I will make sure the branch builds on another machine besides my workstation. Cheers, Aaron On Mon Mar 15th, 2010 9:54 AM CDT Jeff Yu wrote: >Hi Aaron, > >When I checked out the latest code from trunk, I have following >observations: > >1. When I run the 'mvn clean install', I've got following exception: (in the >bpel-dao) > >/local/works/gitode/ode/bpel-dao/src/main/java/org/apache/ode/dao/DerbyJDBCContext.java:[8,16] >cannot find symbol >symbol : class SQLNonTransientConnectionException >location: package java.sql > >/local/works/gitode/ode/bpel-dao/src/main/java/org/apache/ode/dao/DerbyJDBCContext.java:[57,13] >cannot find symbol >symbol : class SQLNonTransientConnectionException >location: class org.apache.ode.dao.DerbyJDBCContext > >/local/works/gitode/ode/bpel-dao/src/main/java/org/apache/ode/dao/DerbyJDBCContext.java:[66,14] >cannot find symbol >symbol : constructor SQLException(java.lang.Exception) >location: class java.sql.SQLException > >2. I've found the >dao-jpa/src/main/java/org/apache/ode/dao/jpa/JPAConnection.java 's name is >not as same as the class name. > >3. With regard to the DerbyJDBContext, I believe we use this class for our >tests, can we move this class out of bpel-dao module, as in the bpel-dao >module, it is db agnostic, what do you think? > >4. I have a concern that we are using the derby database as our defaut mem >db, afaik, we are trying to move away derby to H2. ( >https://issues.apache.org/jira/browse/ODE-666), any ideas that could we use >the H2 to make all tests passed? > >Also, I am curious on how do you run the tests, as I tried to do the 'mvn >clean install' from top-level, it always throw errors.. any other ways for >you to work around? ;) > >Regards >Jeff > >On Mon, Mar 15, 2010 at 10:25 AM, Aaron Anderson <aaronander...@acm.org>wrote: > >> Hi Jeff, >> >> I committed my changes to the JPA branch. Now all the unit tests are >> passing and I believe I have the hibernate, Hibernate JPA, and OpenJPA DAO >> modules working properly. I selected OpenJPA as the default DAO >> implementation and also updated all the unit tests to remove HSQL and use an >> in memory Derby DB. I moved the few tests that were in dao-test into >> bpel-test and then added a couple of extra rounds of surefire tests to >> re-run DAO tests against the hibernate DAO modules. Please take a look and >> let me know what you think. I will begin to introduce the DAO pattern into >> the scheduler module this week. I will add scheduler implementations to the >> three DAO modules and probably just refactor the existing JDBC code and >> leave it in the module. >> >> Regards, >> >> Aaron >> >> > >-- >Cheers, >Jeff Yu > >---------------- >blog: http://jeff.familyyu.net
