[root]/PZFileReader/src/main/java/net/sf/pzfilereader/util
| Author | Changes | Lines of Code | Lines per Change |
|---|---|---|---|
| Totals | 67 (100.0%) | 1386 (100.0%) | 20.6 |
| Paul Zepernick | 40 (59.7%) | 873 (63.0%) | 21.8 |
| Benoit Xhenseval | 27 (40.3%) | 513 (37.0%) | 19.0 |
Stopped column lookup from being case sensitive
6 lines of code changed in:
corrected issue with tab and space delimiter when there were
just empty columns with no data. trim() was removing delimiters
and breaking the parse
10 lines of code changed in:
added constant for specifying an empty qualifier
2 lines of code changed in:
combined if statements fix for PMD
13 lines of code changed in:
fixed NPE when referencing a column that did not exist in the map for a fixed length file
4 lines of code changed in:
quick checkstyle.
2 lines of code changed in:
checkstyle
0 lines of code changed in:
simian fixes
57 lines of code changed in:
findbug fixes
21 lines of code changed in:
cleaned up most of the checkstyle errors.
There are still a couple out there that I am not sure how to
deal with exactly
11 lines of code changed in:
added the ability to include / exclude columns from the Excel export
79 lines of code changed in:
cleaned up exception handling. Got rid of throws Exception
5 lines of code changed in:
more efficient check for unescaped qualifier contained within a qualified element.
This new change avoids substring and left trim per Benoit's suggestion.
22 lines of code changed in:
added to the comment about the lTrimKeepTabs
2 lines of code changed in:
renamed IDataSet to DataSet
3 lines of code changed in:
corrected a couple bugs where the double qualifier replace was not
getting run. Tried to make the look ahead check a little more efficient
preventing the substring and left trim where possible.
11 lines of code changed in:
fixed problem with qualifiers being allowed within the qualified element.
Created a new issue. The check on line 134 of ParserUtilsSplitLineTest
is failing. It seems to me like the check itself may be flawed on the end result.
The parser looks like it is chopping off a " on the end of the element that should
be there.
Benoit, I left a note on what I updated. There is probably a better way
that is going to make for a faster parse.
10 lines of code changed in:
corrected javadoc
1 lines of code changed in:
added bx parser
228 lines of code changed in:
moved parser's into ParserUtils
0 lines of code changed in:
(38 more)
