This one time, at band camp, Michael Colbert said: MC>Cool. I was thinking the existing JUnit tests would be a good place to start, MC>too. They'll give us an idea of what each feature does already from the MC>developers' perspective. We may need to expand coverage in some areas, and MC>some of the more demanding/complex requirements will require some functional MC>tests that encompass several classes and/or features. I haven't looked at the MC>Castor tests in a while. I'll take a look sometime today or tomorrow and see MC>how much of this stuff is already in there. MC> MC>The mailing list will definitely give us useful information from the users' MC>perspective.
Mike, Daniel, I was actually going to suggest that this list should be tightly coupled with the JDO tests (CTF-JDO). This is a great idea, Mike. This will also help the CTF-JDO to move forward faster. Currently, I don't check in any code fixes without a test case proving it. However, this is not to say that the test cases are comprehensive. But this effort would certainly move them in that direction. The idea for a simple doc using a table to establish a matrix of features is also a good idea. This is exactly how I'm laying out the project page right now. I suggest that you use one of the other docs in src/docs as a template to begin. I suggest that the doc be called jdo-features.xml and that it include a column indicating whether a test case has been written yet. This column would need to work in conjunction with the project doc on which I'm currently working. The best thing that you can do is start the doc and send all updates to me for checkin to CVS. Bruce MC>--- Daniel Honig <[EMAIL PROTECTED]> wrote: MC>> I would be willing to assist Michael in this effort. MC>> MC>> I would suppose that the J-Unit test cases are a good starting point. MC>> MC>> We could use the mailing list to get an idea of what alot of MC>> the big questions are and ensure they are clearly outlined MC>> in the matrix. MC>> MC>> MC>> -Daniel MC>> MC>> -----Original Message----- MC>> From: Michael Colbert [mailto:[EMAIL PROTECTED]] MC>> Sent: Monday, October 07, 2002 3:01 PM MC>> To: [EMAIL PROTECTED] MC>> Subject: Re: [castor-dev] Adding new dependent objects to an exiting MC>> persistent object MC>> MC>> MC>> Hi Bruce, MC>> MC>> What I have in mind is a document targeted at Castor JDO users (and MC>> prospective MC>> users) that very concisely indicates the development status of each feature. MC>> Perhaps something as simple as a three column table, with: FEATURE NAME, MC>> TO-DO, MC>> and COMPLETED. MC>> MC>> The TO-DO column would contain a bullet list of planned functions/abilities. MC>> MC>> The COMPLETED column would contain a bullet list of completed MC>> functions/abilities. MC>> MC>> This document would be a quick reference, not an exhaustive resource. MC>> MC>> Seems simple enough. And that's the point. How to get there is another MC>> question, I suppose. Initially, I guess it could be as easy as writing down MC>> the list of features and then for each one asking, "What should it do?" And MC>> then asking, "What does it do now?" But, the answers would have to be MC>> specific, accurate, and provable. This may mean writing some functional MC>> tests MC>> to validate the answers. MC>> MC>> A step forward? MC>> MC>> Mike Colbert MC>> MC>> MC>> MC>> --- Bruce Snyder <[EMAIL PROTECTED]> wrote: MC>> > This one time, at band camp, Michael Colbert said: MC>> > MC>> > MC>Would it be possible to get someone from the JDO team to assist in MC>> > creating a MC>> > MC>status sheet on all the different JDO features (caching, extends, MC>> depends, MC>> > long MC>> > MC>transactions, lazy loading, etc.) and their respective implementation MC>> > status? MC>> > MC> MC>> > MC>I believe this would be helpful to all, since due to the high learning MC>> > curve MC>> > MC>associated with figuring out proper castor JDO usage (esp. the MC>> mapping), MC>> > it's MC>> > MC>incredibly difficult to tell whether or not problems like this are due MC>> to MC>> > MC>improper usage, or "not quite done" features. MC>> > MC> MC>> > MC>I am predicting that Bruce Snyder will have absolutely no reply to Ryan MC>> > MC>McDonough's question here, other than "This one time at band camp ... MC>> > please MC>> > MC>send your client code and mapping." On the other hand, if Ryan had a MC>> > place to MC>> > MC>quickly and painlessly look up the status of a particular feature (in MC>> this MC>> > MC>case, dependent objects), he may never resort to such "probing" MC>> questions. MC>> > (I MC>> > MC>assume he is probing, trying to quickly find out if this is a MC>> well-known MC>> > issue, MC>> > MC>because otherwise he would have sent all his code.) The mailing list MC>> > archive MC>> > MC>is not entirely helpful in this regard, nor is the bugzilla database. MC>> > What I MC>> > MC>have in mind is a one page list of all the major features and their MC>> status MC>> > MC>("not implemented", "partially implemented", "mostly implemented", MC>> "fully MC>> > MC>implemented and tested", etc. along with helpful footnotes along the MC>> lines MC>> > of MC>> > MC>"works while caching is turned off"). MC>> > MC> MC>> > MC>If there is some way to find this information, quickly, please advise. MC>> If MC>> > not, MC>> > MC>I hereby volunteer to collect and publish in one place all MC>> authoritative MC>> > MC>responses to this request as to the status of the JDO features present MC>> and MC>> > MC>future. MC>> > MC>> > Mike, MC>> > MC>> > My apologies for missing your message previously. Currently, there MC>> > is only one other active developer on Castor JDO and he is somewhat MC>> > indisposed recently. MC>> > MC>> > I think that this is a good idea. Can you elaborate on this further? I'm MC>> > currently working on a project plan doc for Castor JDO and your idea MC>> > could definitely influence and supplement this doc. MC>> > MC>> > Bruce -- perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");' ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
