df/mapred works with the old hadoop API df/mapreduce works with hadoop 0.20 API
On Saturday, November 28, 2009, Sean Owen <sro...@gmail.com> wrote: > I'm all for generating and publishing this. > > > The CPD results highlight a question I had: what's up with the amount > of duplication between org/apache/mahout/df/mapred and > org/apache/mahout/df/mapreduce -- what is the difference supposed to > be. > > > PMD is complaining a lot about the "foo == false" vs "!foo" style. I > prefer the latter too but we had agreed to use the former, so we could > disable this check if possible. > > > Checkstyle: can we set it to allow a 120 character line, and adjust it > to consider an indent to be 2 spaces? it's flagging like every line of > code right now ! > > > On that note, if possible, I would suggest disabling the following > FindBugs checks, as they are flagging a lot of stuff that isn't > 'wrong', to me. > > SE_NO_SERIALVERSIONID > I completely disagree with it. serialVersionUID itself is bad > practice, in my book. > > EI_EXPOSE_REP2 > it's a fair point but only relevant to security, and we have no such > issue. The items it flags are done on purpose for performance, it > looks like. > > SQL_PREPARED_STATEMENT_GENERATED_FROM_NONCONSTANT_STRING > SQL_NONCONSTANT_STRING_PASSED_TO_EXECUTE > It's a good point in general, but I'm the only one writing JDBC code, > and there is actually no security issue here. It's a false positive > and we could disable this. > > SE_BAD_FIELD > This one is a little aggressive. It assumes that types not known to be > Serializable must not be Serializable, which isn't true. > > RV_RETURN_VALUE_IGNORED > It's a decent idea but flags a lot of legitimate code. For example > it's complaining about ignoring Queue.poll(), which, like a lot of > Collection API methods, > > UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR > I don't necessarily agree with this one, explicitly setting fields to > null and primitives to zero? tidy but I'm not used to it. > > > I didn't see anything big flagged, good, but we should all have a look > at the results and tweak accordingly. In some cases it had a good > small point, or I was indifferent about the approach it was suggesting > versus what was in the code, so I changed to comply with the check. > > > On Fri, Nov 27, 2009 at 8:26 PM, Isabel Drost <isa...@apache.org> wrote: >> >> Hello, >> >> I just ran several code analysis reports over the Mahout source code. >> Results are published at >> >> http://people.apache.org/~isabel/mahout_site/mahout-core/project-reports.html >> >> It includes several reports on code quality, test coverage, java docs >> and the like. When generated regularly say on Hudson I think it could >> be beneficial both for us (for getting a quick impression of where >> cleanup is necessary most) as well as for potential users. >> >> I would like to see a third tab added to our homepage that points to >> a page containing reports for each of our modules. I would try to cleanup the >> generated site a little before - we certainly do not need the "Project >> information" stuff in there, as most of this is already generated >> through forest. In addition I can take care of setting up a hudson >> job to recreate the site on a regular schedule. >> >> Cheers, >> Isabel >> >> -- >> |\ _,,,---,,_ Web: <http://www.isabel-drost.de> >> /,`.-'`' -. ;-;;,_ >> |,4- ) )-,_..;\ ( `'-' >> '---''(_/--' `-'\_) (fL) IM: <xmpp://main...@spaceboyz.net> >> >> >
