JPA 2.0 Development Kickoff

[Kevin Sutter <kw...@gmail.com>]

Hi,
With the recent posting of Public Review Draft of the JPA 2.0 specification
[1], we need to publicly kick off the development of JPA 2.0 within the
OpenJPA development team.  There have been a few other related postings to
the dev mailing list [2].  This shows the team's interest in pursuing this
goal of delivering JPA 2.0.  To that end, we're going to borrow a few ideas
from our brethern over at the OpenEJB project [3] and other Agile-like
practices.

One of these ideas is to outline short iterations (or sprints) that will
constitute various pieces of runnable function.  For example, our first
iteration has to include the JPA 2.0 API (JIRA issue OPENJPA-773).  With
this code drop, developers will be able to compile and build with the new
enhanced API.  Not all of the function will be implemented in the first
iteration, but hopefully a customer application written against the JPA 2.0
spec should be buildable.  I'm sure the first iteration will have additional
functionality, but the JPA 2.0 API is an example of what to expect.

Every iteration will need to be self-contained.  Not only will a given
function need be implemented, but it also needs corresponding test cases and
documentation.  This doesn't mean that a given feature of JPA 2.0 has to be
100% complete in a single iteration.  For example, the Criteria API would be
difficult to contain within a single iteration.  But, the Criteria API could
be broken down into smaller bite-size pieces and spread across 2 or more
iterations.  Each of these bite-size pieces still need to be complete from a
functional, test, and documentation perspective.

To that end, we will need several different types of participation:

Developers:  People interested in accepting responsibility for developing
(design, implementation, and unit test) any particular function.
ID:  People interested in helping out with the documentation of a particular
function.
Testers:  People interested in actively testing, especially from a customer
viewpoint.

In many cases, the same people will be involved in all three aspects.  But,
depending on time commitments, some people will only be able to sign up for
one aspect.  For example, I would guess (hope) that we have several people
interested in testing out the new function available in JPA 2.0.  As each
iteration is defined and the JIRA issues are opened up, it would be great to
have these people indicate a desire to help test the various functions
defined.  Since the actual design and implementation of a new function may
require more dedicated time, the pool of people to select from may be
smaller.  We will welcome all interested in participating!

Another area that OpenJPA needs some help is with Samples.  As we start on
our JPA 2.0 implementation, I would really like to grow our Samples base.
Starting off extremely simple and growing to more complex would be ideal.
If any of you have ideas on how to organize and expand on our Samples, they
would be appreciated.

The other thing to keep in mind is that just like the JPA 2.0 spec itself,
the OpenJPA implementation will go through some growth spurts and pains.
Since the spec isn't final yet, there will undoubtedly be some features that
need to be re-worked over time.  This is normal with the iterative
development process.  Just be flexible and eventually we will get an
implementation that is JPA 2.0 compliant.

Given all of this introduction, I would like to propose the following JPA
2.0 Roadmap:


   - http://cwiki.apache.org/confluence/display/openjpa/JPA+2.0+Roadmap


You will notice that it is far from complete.  A couple of reasons for
that...

1)  This is meant to be iterative and we don't want to plan too far in
advance.  Some work items will fall out of a iteration 1, while others may
still get added.  Flexibility is key.

2)  This is not meant to be an edict.  Although I am taking the lead to get
the troops in line for JPA 2.0 development, I would assume and expect some
feedback from this proposal.  Why plan out the whole release if it's going
to be blown to shreds in the first week?  :-)

Take a look and please provide some feedback.  Like I mentioned, we're very
interested in getting additional participation.  So, don't feel like you
have to be an expert to participate.  We're looking for all kinds of
personnel (development, id, testing, customers, etc).  You can volunteer via
the Dev mailing list (dev@openjpa.apache.org), any of the active committers
(http://openjpa.apache.org/committers.html), or you can contact me directly
(kwsutter@gmail.com).  We welcome your participation!

Thanks,
Kevin Sutter

==============================
[1]  http://jcp.org/aboutJava/communityprocess/pr/jsr317/index.html
[2]
http://n2.nabble.com/JPA-2.0-development-plans...-td1129341.html#a1129341,
http://n2.nabble.com/Updating-the-JPA-spec-jar-for-JPA-2.0-td1482013.html#a1482013,
http://n2.nabble.com/Upgrade-to-JPA-2.0-td1511981.html#a1511981
[3]  http://openejb.apache.org/

Re: JPA 2.0 Development Kickoff

[Robert Burrell Donkin <ro...@gmail.com>]

On Tue, Nov 25, 2008 at 5:54 PM, Kevin Sutter <kw...@gmail.com> wrote:
> Hi,
> With the recent posting of Public Review Draft of the JPA 2.0 specification
> [1], we need to publicly kick off the development of JPA 2.0 within the
> OpenJPA development team.  There have been a few other related postings to
> the dev mailing list [2].  This shows the team's interest in pursuing this
> goal of delivering JPA 2.0.  To that end, we're going to borrow a few ideas
> from our brethern over at the OpenEJB project [3] and other Agile-like
> practices.

sounds interesting :-)

> One of these ideas is to outline short iterations (or sprints) that will
> constitute various pieces of runnable function.  For example, our first
> iteration has to include the JPA 2.0 API (JIRA issue OPENJPA-773).  With
> this code drop, developers will be able to compile and build with the new
> enhanced API.  Not all of the function will be implemented in the first
> iteration, but hopefully a customer application written against the JPA 2.0
> spec should be buildable.  I'm sure the first iteration will have additional
> functionality, but the JPA 2.0 API is an example of what to expect.
>
> Every iteration will need to be self-contained.  Not only will a given
> function need be implemented, but it also needs corresponding test cases and
> documentation.  This doesn't mean that a given feature of JPA 2.0 has to be
> 100% complete in a single iteration.  For example, the Criteria API would be
> difficult to contain within a single iteration.  But, the Criteria API could
> be broken down into smaller bite-size pieces and spread across 2 or more
> iterations.  Each of these bite-size pieces still need to be complete from a
> functional, test, and documentation perspective.

cool

> To that end, we will need several different types of participation:
>
> Developers:  People interested in accepting responsibility for developing
> (design, implementation, and unit test) any particular function.
> ID:  People interested in helping out with the documentation of a particular
> function.
> Testers:  People interested in actively testing, especially from a customer
> viewpoint.
>
> In many cases, the same people will be involved in all three aspects.  But,
> depending on time commitments, some people will only be able to sign up for
> one aspect.  For example, I would guess (hope) that we have several people
> interested in testing out the new function available in JPA 2.0.  As each
> iteration is defined and the JIRA issues are opened up, it would be great to
> have these people indicate a desire to help test the various functions
> defined.  Since the actual design and implementation of a new function may
> require more dedicated time, the pool of people to select from may be
> smaller.  We will welcome all interested in participating!
>
> Another area that OpenJPA needs some help is with Samples.  As we start on
> our JPA 2.0 implementation, I would really like to grow our Samples base.
> Starting off extremely simple and growing to more complex would be ideal.
> If any of you have ideas on how to organize and expand on our Samples, they
> would be appreciated.

perhaps it might be possible to base some samples on usage in other
open source projects

- robert