Daniel, Cool. I was thinking the existing JUnit tests would be a good place to start, too. They'll give us an idea of what each feature does already from the developers' perspective. We may need to expand coverage in some areas, and some of the more demanding/complex requirements will require some functional tests that encompass several classes and/or features. I haven't looked at the Castor tests in a while. I'll take a look sometime today or tomorrow and see how much of this stuff is already in there.
The mailing list will definitely give us useful information from the users' perspective. Mike Colbert --- Daniel Honig <[EMAIL PROTECTED]> wrote: > I would be willing to assist Michael in this effort. > > I would suppose that the J-Unit test cases are a good starting point. > > We could use the mailing list to get an idea of what alot of > the big questions are and ensure they are clearly outlined > in the matrix. > > > -Daniel > > -----Original Message----- > From: Michael Colbert [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 07, 2002 3:01 PM > To: [EMAIL PROTECTED] > Subject: Re: [castor-dev] Adding new dependent objects to an exiting > persistent object > > > Hi Bruce, > > What I have in mind is a document targeted at Castor JDO users (and > prospective > users) that very concisely indicates the development status of each feature. > Perhaps something as simple as a three column table, with: FEATURE NAME, > TO-DO, > and COMPLETED. > > The TO-DO column would contain a bullet list of planned functions/abilities. > > The COMPLETED column would contain a bullet list of completed > functions/abilities. > > This document would be a quick reference, not an exhaustive resource. > > Seems simple enough. And that's the point. How to get there is another > question, I suppose. Initially, I guess it could be as easy as writing down > the list of features and then for each one asking, "What should it do?" And > then asking, "What does it do now?" But, the answers would have to be > specific, accurate, and provable. This may mean writing some functional > tests > to validate the answers. > > A step forward? > > Mike Colbert > > > > --- Bruce Snyder <[EMAIL PROTECTED]> wrote: > > This one time, at band camp, Michael Colbert said: > > > > MC>Would it be possible to get someone from the JDO team to assist in > > creating a > > MC>status sheet on all the different JDO features (caching, extends, > depends, > > long > > MC>transactions, lazy loading, etc.) and their respective implementation > > status? > > MC> > > MC>I believe this would be helpful to all, since due to the high learning > > curve > > MC>associated with figuring out proper castor JDO usage (esp. the > mapping), > > it's > > MC>incredibly difficult to tell whether or not problems like this are due > to > > MC>improper usage, or "not quite done" features. > > MC> > > MC>I am predicting that Bruce Snyder will have absolutely no reply to Ryan > > MC>McDonough's question here, other than "This one time at band camp ... > > please > > MC>send your client code and mapping." On the other hand, if Ryan had a > > place to > > MC>quickly and painlessly look up the status of a particular feature (in > this > > MC>case, dependent objects), he may never resort to such "probing" > questions. > > (I > > MC>assume he is probing, trying to quickly find out if this is a > well-known > > issue, > > MC>because otherwise he would have sent all his code.) The mailing list > > archive > > MC>is not entirely helpful in this regard, nor is the bugzilla database. > > What I > > MC>have in mind is a one page list of all the major features and their > status > > MC>("not implemented", "partially implemented", "mostly implemented", > "fully > > MC>implemented and tested", etc. along with helpful footnotes along the > lines > > of > > MC>"works while caching is turned off"). > > MC> > > MC>If there is some way to find this information, quickly, please advise. > If > > not, > > MC>I hereby volunteer to collect and publish in one place all > authoritative > > MC>responses to this request as to the status of the JDO features present > and > > MC>future. > > > > Mike, > > > > My apologies for missing your message previously. Currently, there > > is only one other active developer on Castor JDO and he is somewhat > > indisposed recently. > > > > I think that this is a good idea. Can you elaborate on this further? I'm > > currently working on a project plan doc for Castor JDO and your idea > > could definitely influence and supplement this doc. > > > > 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 > > > > > __________________________________________________ > Do you Yahoo!? > New DSL Internet Access from SBC & Yahoo! > http://sbc.yahoo.com > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
