On 19 March 2013 18:52, Simone Tripodi <simonetrip...@apache.org> wrote: > 3 commits? :O
This one, and: r1458269 http://mail-archives.apache.org/mod_mbox/commons-commits/201303.mbox/%3C20130319132232.8ABD023888EA%40eris.apache.org%3E and r1458277 http://mail-archives.apache.org/mod_mbox/commons-commits/201303.mbox/%3C20130319130851.503092388906%40eris.apache.org%3E have the same problem. I'll raise it with infra. > sorry, I have no clue, svn history shows that only once... > > -Simo > > > stripodi$ svn log > ------------------------------------------------------------------------ > r1458278 | simonetripodi | 2013-03-19 14:44:37 +0100 (Tue, 19 Mar 2013) | 1 > line > > [FILEUPLOAD-232] initial checkin of QuotedPrintableDecoderTestCase class > ------------------------------------------------------------------------ > r1458277 | simonetripodi | 2013-03-19 14:43:09 +0100 (Tue, 19 Mar 2013) | 1 > line > > aligned issue documentation reference to @see tag > ------------------------------------------------------------------------ > r1458269 | simonetripodi | 2013-03-19 14:22:32 +0100 (Tue, 19 Mar 2013) | 1 > line > > added a test to see how this Base64 decoder impl behaves compared to > https://issues.apache.org/jira/browse/CODEC-68 > ------------------------------------------------------------------------ > r1458266 | simonetripodi | 2013-03-19 14:08:50 +0100 (Tue, 19 Mar 2013) | 1 > line > > added a test where the encoded input string has the padding char in > the middle; contrary to commons-codec, it doesn't halt and continues > translating > ------------------------------------------------------------------------ > r1458245 | simonetripodi | 2013-03-19 13:30:02 +0100 (Tue, 19 Mar 2013) | 1 > line > > no needs to specify always the offset and the length of the byte[] has > to be decoded, since in this implementation there's always the need to > decode the whole buffer > ------------------------------------------------------------------------ > r1458240 | sebb | 2013-03-19 13:18:39 +0100 (Tue, 19 Mar 2013) | 3 lines > > FILEUPLOAD-233 Base64Decoder doesn't correctly implement RFC 4648 > Oops, initial rework of code was wrong. > Re-enabled failing tests > ------------------------------------------------------------------------ > r1458236 | simonetripodi | 2013-03-19 12:56:27 +0100 (Tue, 19 Mar 2013) | 1 > line > > [FILEUPLOAD-233] fixed and re-enabled the test case where an empty > string doesn't need to be decoded > ------------------------------------------------------------------------ > r1458220 | markt | 2013-03-19 11:56:17 +0100 (Tue, 19 Mar 2013) | 3 lines > > There needs to be the same number of place-holders as there are replacements. > Fixes an issue introduced in r1453239. > Identified by FindBugs running against the Tomcat code base (which has > a package renamed copy of FileUpload). > ------------------------------------------------------------------------ > r1458213 | simonetripodi | 2013-03-19 11:37:37 +0100 (Tue, 19 Mar 2013) | 1 > line > > initial checkin of Base64 Decoder test case, which clearly demonstrate > the current Base64 implementation is broken > ------------------------------------------------------------------------ > r1458210 | simonetripodi | 2013-03-19 11:21:19 +0100 (Tue, 19 Mar 2013) | 1 > line > > extracted and documented constants that are used inside each algorithm > iteration > > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
