> 1) we have to explicitly call out the dependencies (i.e. impl on api) > so that if we mistakenly introduce a circular dependency (like the > UIData thing this morning) we can catch it easily.
I think we can achieve this by reworking the build script. We can have different classpaths and then specify them in the build.properties of the subproject. I think we should do this no matter what because most of us will be building using current and we don't want to accidentally introduce dependencies as you point out. > 2) Small chunk of stuff to bite off for new developers. Someone > joining the dev team (or thinking about it) could just grab the api > code to start with and once groked could move onto the impl code. I guess I can see some advantage to working on just api but I still think share + impl are pretty much inseparable. > 3) Testing, if we could build each project independently we could > have tests focused on that particular subproject. Agreed that we are > not getting around the impl->api dependency so api would have to be > available in some form (the classes dir mentioned above would be one > way) but the developer of the test could focus just on the impl > project and test that in relative isolation. > > Most if no all this could also be done with the 'current' project as > well so its no that big of a deal. But I like to try to minimize > things so that newbies can get started quicker and easier. I think that depends on how you test the subprojects. What kinds of tests do we envision writing for api for example? So far I've heard a suggestion of writing a test to "click" on all of the examples. That's a great idea but that's really a test of several subprojects combined. I'm not really opposed to your suggestion, just curious. I will try to work on item#1 this weekend. That should bring us closer to what you are trying to achieve. > And we also have a huge task to get unit testing in place, the easier > that is the better. If we could get consensus on consolidating the examples that would also be good. I'd say we should do this and a few other steps (nightly builds, website enhancements) before deploying the unit tests. > BTW: what is the general consensus among us regarding tests? I'd love > to see a set of automated integration tests that at least clicked > through the whole sample/simple example tree as a starter and then > build from that. I'm willing to start it but its very hard to > maintain if we are not all committed to running the tests before we > commit. Tests are great but I am not particularly creative at implementing web-based tests. I like the idea of compiling and deploying the webapps and clicking through the application. Even if people do not run the tests before commiting, we can at least run them nightly and report failures to the dev list. It would be interesting to see how Maven could help here. I'm not sure about how Maven is going to fit into all of this but it seems to have nice testing and reporting features. If we write cactus and junit tests and use ant can they be ported over to Maven? > Anyway sorry for the long message and thanks again Sean for all the > hard work. Your welcome. Thank you for your interest in testing ;-) I'm definitely looking forward to seeing your test ideas come to life. There are some legacy tests that I didn't really know how to deal with. You can check the "before_svn_reorg" tag and find them if you're interested. We'll also have to figure out how we're going to automate the tests and from which machine. > -bd- sean
