<snip: confluence> OK - I'll put a link to the apt generated html :-)
It opens directly from subversion anyways. As soon as I find those extra 36 hours in the day, I'm going to make an Eclipse plugin that is pulls xsd template schemas from a (Maven like) repository and automatically produces sample instance documents for documenting in a standardized template format. Then I need another mojo that produces corresponding eclipse plugin documentation in a larger context. Then we can keep documentation tied tightly to a project, subversion it, and gain all the benefits I put in the Eclipse Help System proposal. <snip:testing> The 100% method will be very straight forward once the tooling is done. I'll hold off on discussing anymore, because I want the paper to be the context for it. The main thing I want comitters to understand is the methodology. Doing the methodology by hand could be a little tricky :-), The other benefit is that there will be a clearly defined unambiguous doable unit testing goal for the project. <snip: following in other's footsteps:> Yeah - the unit testing lines to total code lines ratio is slightly skewed right now :-) So I would think of the checklist as reflecting the goal and approach of where we want to be. Personally I would also expect us to come together and review and agree on a set of standards so that we all do them. That said the primary criteria should be for these to make us more efficient, ofcoarse. If you would like a hint besides the JUnit discussion around the testing automation, check out: www.agitar.com www.junitfactory.com These guys were also in the JUnit discssion btw :-) Cheers, - Ole ____________________________________________________________________________________ Have a burning question? Go to www.Answers.yahoo.com and get answers from real people who know.
