openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <>
Subject RE: State of OpenJPA code drop
Date Tue, 08 Aug 2006 23:24:34 GMT
> On Jul 28, 2006, at 1:14 PM, Patrick Linskey wrote:
> >
> > Feature-wise, I'm sure we'll see some more code come out with
> > interesting features, but what you see now is substantially all of
> > what's currently in plan.
> I'm sure you have some ideas for features that are not 
> currently part  
> of the code drop that you think might be good candidates for the  
> community; e.g. someone had an idea to add the PU name to logging  
> messages. I'd like to suggest that for better transparency, each of  
> these things should be put into JIRA with some suggestion what the  
> implementation might look like and what kind of unit testing 
> might be  
> done. Then, if someone wants to work on it, they assign it to  
> themselves in JIRA and if they need help, post on the dev alias for  
> support.

Agreed, and the PU name logging thing was exactly such an idea. Sadly, the
day job is keeping me awfully busy right now....

> I'd suggest that to start, all JPA TCK test failures should be  
> analyzed and a small test case be developed to demonstrate the  
> problem. Then, the issue can be logged and tracked in JIRA. Without  
> jeopardizing confidentiality, the community can be involved 
> in fixing  
> the issues.

Kodo 4.0 passes 100% of the JPA TCK. Current builds of Kodo 4.1 (based on
occasional OpenJPA snapshots) passes all but 1 of the JPA TCK tests, and the
one failure is something that might need a challenge. So I don't think that
we'll need to be creating any unit tests for TCK failures any time soon.

> By the way, we should have a place to put new unit tests that fail.  
> We don't want them in the main line, because then the build is  
> broken. But we don't want them in JIRA issues either. Is there some  
> place that we could put tests that don't work yet?

Interesting dilemma. How does Maven usually deal with this? Historically on
the Kodo team, we hacked our test framework to have a concept of a "bug".
Essentially, a non-successful test could be a failure, an error, or a bug.
If it was a bug *and* the bug was still open in the bug database, then the
unit test didn't trigger a failure, since the feature worked as expected. I
wonder if we could reprise a similar architecture again.

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.

View raw message