On Wed, May 20, 2015 at 11:38 PM, Yonik Seeley <[email protected]> wrote: > Seems like a bug in javadoc if it fails on valid java code with no > javadoc specified on the involved classes. > >> if you'd run "ant precommit" you would have gotten the same error, and >> (if you hadn't understood the problem) you could have asked about it >> before breaking the build. > > I normally only make sure unit tests pass.
Please understand that by taking this attitude you waste everyone else's time who does want to pass "ant precommit" before committing, and everyone else's time to scan all these broken builds emails. If you truly refuse to pass "ant precommit" before committing, at least be vigilant and watch the next few builds to see if you broke them, and then fix it quickly. > "ant precommit" is way to picky. I agree it's picky but I think that's a feature, not a bug :) It is this way so it catches common errors that unit tests don't catch: a leftover #nocommit, wrong svn props, forgot to svn add, etc. Over time we've made it more picky each time one of us falls into a trap of forgetting to do XYZ before committing. And in this case it looks like it caught something truly wrong with your change (a public API using a package-private class). Had you run it before hand and paid attention to what it said you could have fixed it... My biggest complaint is how slow it is ... I wish we could improve that. > For example it will fail if one as > any extra files lying around (which is normally the case for active > development / debugging). Doing a clean checkout and re-applying the > patch just to make "ant precommit" happy is too high of a hurdle. My > guess is that most committers don't use it for the majority of > commits. This is to try to help you remember to "svn add" files. Why not store such files outside of the source tree? Or maybe we can add them to svn:ignore? Mike McCandless http://blog.mikemccandless.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
