incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <>
Subject RE: [PROPOSAL] Open JPA
Date Wed, 08 Mar 2006 02:11:47 GMT
See comments inline.

> > :Core Developers:
> > Fourteen of the initial committers are BEA employees. One 
> of those is 
> > a committer on the Apache JDO project. We anticipate that five of 
> > these fourteen will be involved in the core code 
> development, and the 
> > other nine will be involved in documentation and ongoing QA 
> for the project.
> Must the other 9 have commit privileges?  If they're doing 
> docs and QA, most of what they'll be doing is available via 
> JIRA or whatever issue tracker is set up.

I think that having commit privileges would certainly make it easier for
them to do their jobs, yeah. Clearly, it would be possible for them to
pass their changes through others on the team to get committed. But I
expect that the work they'll do won't just be issue-tracking-related;
the plan is for the docs people to be directly mutating the
documentation, and the QA folks to directly create test cases (and
potentially solutions, depending on the scope of particular issues).

But frankly, I don't have much of a clue about exactly how such
specialized roles are usually handled at Apache; I was hoping that this
would come up in the proposal process so that we could work out what the
best strategy all around is.

> > JPA is for use in any Java application, not just J2EE. 
> Therefore, any 
> > application that needs to do data persistence in the 
> object/relational 
> > style (including any application that currently uses 
> Hibernate) will 
> > benefit from Open JPA.
> Would it make sense for this to go in DB or Jakarta, then?  

Certainly Jakarta's Java-catch-all nature makes it a natural place for
Open JPA. DB makes some sense too, given that Open JPA is about talking
to databases.

The thing that seems a bit out-of-place for DB (to me) is that Open JPA
does not actually manage data directly; it merely provides a mechanism
to access some other data management system. Clearly, there are other
database-access frameworks in the DB project, so it could fit there too.

> The Geronimo association implies a J2EE container in my mind.

It does, and I want to be careful with this. I don't think that Geronimo
is the right place for Open JPA, as it's useful and currently used both
in and out of a J2EE container. I think that making Open JPA a
subprojcet of Geronimo would probably hurt the long-term success of Open
JPA, since such an association would probably enforce the impression
that a J2EE container was required to use Open JPA.

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message