Hi Dave,I'm afraid that we're rolling over a cliff here. I'd like to have a discussion and resolution on the future of the JPA sandbox work, and IMHO putting it into a branch just defers the real decision that we need to make.
There are advantages and disadvantages with using JPA instead of Hibernate native APIs, and we need to resolve whether Roller will support a single back end or multiple back ends.
I think there are three end results:1. Stay the course. JPA continues as a second class citizen, remains in the sandbox, and might not work, subject to feature development in the main line. "Someone" will have to come along after a checkin to make sure that the sandbox code continues to work.
2. Switch out Hibernate API and use JPA API as the one API that is supported by Roller. Note that since Hibernate has a JPA implementation, current users of Roller could continue to use Hibernate but with a different API.
3. Support both JPA and Hibernate native APIs in Roller. New feature development would have to test in both JPA and Hibernate modes before checking in.
When I started working on this project, I anticipated outcome 3. I'm used to implementing and using pluggable back ends and this applies equally to hardware platforms, Java VMs, persistence APIs, and databases. It was a bit of a surprise to me that this was not the expectation of the rest of the team, but it was rather late in the cycle when I discovered this would be an issue.
I understand that in the early stages of the project, there was some skepticism in the team that the JPA API would be suitable for production. I would say that we should be past discussion on this point. We're down to fine points in the implementation.
From Allen's and Dave's comments, we are ready to have the discussion on the outcome.
Craig On Jan 24, 2007, at 9:48 AM, Dave wrote:
On 1/24/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:> Anybody have other objections to moving JPA/JDO code out of the sandbox?Yes, I know it's a little annoying, but I am against moving that code into the main src tree. If working out of the sandbox is causingproblems then I think the other option is a branch, but moving the code into the main src tree, both for Weblogger and Planet does not seem likethe best idea to me. Granted that there are concerns from a technical point of view aroundhaving to change the build process and making sure that code doesn't gointo normal builds/releases, but to a larger degree I think it's justnot a practice we should endorse. We can't set a precedence of allowing experimental code to go into the main src tree just to make it easier onthe people working on that code, that's specifically why we have a sandbox and can provide different branches in the repository.I believe I have sufficiently addressed your specific concerns and I don't have any problem with allowing experimental code under the src directory as long as it is clearly marked and does not affect production code, but... That said, I do not object to doing the remaining JPA work in a branch and it sounds like now might be a good time to create that branch. So, I propose that we create a roller_jpa branch and within that branch move JPA from sandbox to src and apps/planet/src. Once JPA is solid and supportable, we'll merge back. Any objections to that plan? - Dave
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
