I'll shoot first ...
Craig L Russell wrote:
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.
I agree that talking about this is good, but I don't think that a branch
is deferring any decisions. That fact remains that big chunks of work
such as this *should* be done in a branch and stabilized there before
moving to the trunk. So regardless of the decision I think that a
branch is the appropriate next step.
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.
I think this has to be the path until it's been fully decided that JPA
is going to be a fully supported backend for Roller.
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.
Definitely -10 from me. I am not willing to officially endorse multiple
backends for the project, no matter how easy it may seem. I think we
definitely need to pick a single solution to endorse and that's it.
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 am a little surprised to hear that, but I guess it was
miscommunication. From the very beginning I think that everyone was in
agreement that we would only officially support a single backend, so if
it was going to be something other than the current Hibernate impl then
that meant replacement
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.
Just because it's working doesn't mean it's time to commit it to the
main src tree and endorse it. Assuming that the community has properly
discussed the issue and come to a decision (which hasn't happened yet)
and assuming all the proper testing and verification has been done
(which hasn't happened yet) then we can talk about how/when to commit it
to the main src tree. IMO your suggestion that it's ready to go into
the main src tree is a bit premature.
For one thing, can the JPA backend work on jdk 1.4? I haven't worked
with any of the JPA stuff myself, but I am assuming that it requires
Java 5 which means that we would be forcing all Roller users onto a new
jdk version. So that's an important decision which will affect the timing.
The second part of the timing issue just has to due with stability and
good practices for releases. IMO swapping out the whole backend on a
minor release such as 3.1 -> 3.2 is not something that mature products
do. A change like this warrants a major release, so assuming it is
ready it should be scheduled for the 4.0 release and not sooner. This
then suggests that we should take all the current code in the trunk and
make a 3.2 release out of it, which would still be premature considering
that 3.1 hasn't even gone out.
So all in all, I'm glad this work is coming along, but I don't think
that the project is ready to assimilate it yet. There are a number of
things to consider before just shoving this code into the src tree and I
don't think we've thought through and discussed all of them.
-- Allen
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 causing
problems 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 like
the best idea to me.
Granted that there are concerns from a technical point of view around
having to change the build process and making sure that code doesn't go
into normal builds/releases, but to a larger degree I think it's just
not 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 on
the 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!
