TN (or anyone): I get a lot of Checstyle errors "Missing a header - not enough lines in file."
Do you get those too? Gary On Mon, Aug 20, 2012 at 4:39 PM, Thomas Neidhart <thomas.neidh...@gmail.com>wrote: > On 08/17/2012 09:15 PM, Gary Gregory wrote: > > On Fri, Aug 17, 2012 at 2:49 PM, Thomas Neidhart > > <thomas.neidh...@gmail.com>wrote: > > > >> On 08/16/2012 01:37 PM, Gary Gregory wrote: > >>> (edited message subject to add "[Codec]" prefix) > >>> > >>> Yes, there is a certain amount of rain dancing, keeping of fingers > >> crossed, > >>> and cussing involved when cutting releasing, and it's fallen off my > radar > >>> to due other priorities. > >>> > >>> Is the ML content by the state of the new Crypt classes in > >>> org.apache.commons.codec.digest? > >> > >> I did some javadoc cleanup of the package. > >> > > > > Thank you TN! > > > > > >> > >> (btw. I find non-closing <p> tags on a separate line the most readable > >> solution as outlined in the javadoc tutorial > >> > >> > http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html > >> > >> what do other people think about it?) > >> > > > > It is nice and clear. I personally do not use the style but am willing to > > change ;) Since we all know that Javadoc is [X?]HTML-lite, using "broken" > > XHTML feels odd (unbalanced tags). I might be speaking from fuzzy memory > > but I vaguely recall odd things happening in combination with opening, > > closing and nesting some tags. I guess we could use <p> and deal with > > special cases when they come up. > > > > > >> What is a bit odd is that the methods throw Exception although it's not > >> needed at all (e.g. UnixCrypt) > > > > > > I see that with > org.apache.commons.codec.digest.UnixCrypt.crypt(String)... > > nasty! Good catch! > > > > > >> or could be constrained to > >> NoSuchAlgorithmException (e.g. in Md5Crypt). > >> > > > > Yes, more nastiness. > > > > The exceptions might have been there with the though of making all of > these > > classes implement a common interface. I do not seen the need for that > ATM. > > We can always add it later if needed. > > > > > >> > >> Javadoc does not yet mention the exceptions too (but I can fix that). > >> > > > > > > Yes, please fix it all up as much as you can. > > ok done. > > Regarding the TODO in the B64 class: > > I do not think that the existing Base64 implementation can be reused, as > the cipher text encoded by crypt is only "in a form of" Base64. > > Actually the encoding alphabet is slightly different ('.' instead of > '+') and also the encoding itself is not the same. > > Thomas > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
