commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [Codec] Next Commons-Codec release?
Date Mon, 20 Aug 2012 20:46:14 GMT
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.neidhart@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.neidhart@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message