If we decide to support only a few record separators (which I'd vote for), it makes sense to:
- introduce an enum - throw an exception during CSVFormat validation if a record separator that we can not handle is passed to the format (the latter is only necessary if the record separator can also be passed as char/string) Benedikt 2014-06-30 22:15 GMT+02:00 Bernd Eckenfels <e...@zusammenkunft.net>: > Hello, > > I think it is fine to not support record seperators other than EOL. So > as long as it supports (*) CR/LF/CRLF, NEL (U+0085 - mapped from EBCDIC) > and LS (U+2028) it is ok to not require further configuration. > > One thing which is however quite common is multi-line field values > (inside quotes). > > Gruss > Bernd > > * based on XML 1.1 2.11 "End-of-Line handling" > > Am Mon, 30 Jun 2014 22:06:57 +0200 > schrieb Benedikt Ritter <brit...@apache.org>: > > > 2014-06-30 11:00 GMT+02:00 Tillmann Gaida <tillmann.ga...@gmail.com>: > > > > > It looks like the two issues revolve around the question if record > > > separators should always be some combination of CR and LF or if they > > > may be more exotic. I think that if someone made the call that > > > commons-csv will not support exotic record separators, both issues > > > could be closed very quickly. I'd support that call since I don't > > > see any use cases for exotic record separators. After all, CSV is a > > > specified format and while some tolerance is required to cover what > > > has become a family of formats, I think that exotic record > > > separators don't play a role here. > > > > > > > Nicely said! I'd support this. > > What do others think? > > > > > > > > > > On Mon, Jun 30, 2014 at 8:58 AM, Gabriel Reid > > > <gabriel.r...@gmail.com> wrote: > > > > On Sun, Jun 29, 2014 at 3:50 PM, Benedikt Ritter > > > > <brit...@apache.org> > > > wrote: > > > >> > > > >> Alpha, beta, or GA makes no difference if it's made public > > > >> through maven central. As soon as something is available there, > > > >> people will start to > > > use > > > >> it. This will lead to jar hell, when we decide/have to break BC > > > >> between alpha/beta and GA. > > > >> > > > >> That said I'd just release trunk as 1.0, since nobody among us > > > >> seems to have the ability/time to fix the last outstanding issue. > > > > > > > > +1 to releasing trunk. > > > > > > > > We had a similar discussion about this a couple of months ago. The > > > > fact is that people are using commons-csv now, either by making > > > > their own build or by pulling the commons-csv codebase directly > > > > into their own codebase, and this will lead to the same jar hell > > > > issues when a "real" first release comes out. I think that > > > > delaying the release further, particularly for a couple of > > > > tickets that have been open for over two years, will only make > > > > this problem worse. > > > > > > > > - Gabriel > > > > > > > > --------------------------------------------------------------------- > > > > 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 > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
