Hi Aaron, Thanks for this, one thing we also need to keep in mind is that we need to update the buildr's build file to make it build successfully as well in order to get this patch applied. So I was thinking not to make the build system too complicated. :) But lets do as what you think now, and then we will try to figure out how to do this in the buildr.
Regards Jeff On Sat, Mar 13, 2010 at 2:37 AM, Aaron Anderson <aaronander...@acm.org>wrote: > Hi Jeff, > > I am still working on the refactoring but have hit a speed bump with > getting all the DAO tests to pass. For the BPEL DAO I tried to use HSQL but > gave up on it since it did not support BLOB s that dao-hibernate uses and I > came across a weird issue where hibernate was not getting a valid generated > ID from the HSQL call Identity() procedure in a JTA transaction. I switched > to derby which now with the latest release has an in memory only backend. > After that I am still having a single issue with the ScopeDAOImpl > _childScopes where both openjpa and hibernate are not properly populating > that field even though I have confirmed the data is in the db. I hope to > finish all my changes over the weekend. > > Another change I made was to push up the begin/commit/rollback/close > features from the store dao connection to a top level connection interface > for all dao connections to provide. This made sense to me since the > underlying dao implementation requires transactional state be it JDBC, JPA, > or JTA. > > As for the tests, my idea was to move all the integration level tests to > one place in bpel-test and then run multiple surefire plugin executions for > each dao impl. Hopefully this would provide the exact same test coverage per > dao impl while eliminating the need for redundant test code per dao impl > module. > > On Tue Mar 9th, 2010 11:02 PM CST Jeff Yu wrote: > > >Hi Aaron, > > > >If we move the dao-test into bpel-test module, will we also run the > >bpel-test test cases multiple times with different dao implementation? > > > >With regard to the svn trunk change, I think we are good with it, as > Apache > >ODE also has a git repository, we pull changes from it into our own git > repo > >from time to time, and do the merge between branch. So it is not a lot of > >work there. > > > >Regards > >Jeff > > > >Regards > >Jeff > > > >On Wed, Mar 10, 2010 at 10:23 AM, Aaron Anderson <aaronander...@acm.org > >wrote: > > > >> 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 > >> > >> > >> > >> > >> > >> > > > >-- > >Cheers, > >Jeff Yu > > > >---------------- > >blog: http://jeff.familyyu.net > > -- Cheers, Jeff Yu ---------------- blog: http://jeff.familyyu.net
