commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <benerit...@gmail.com>
Subject [csv] Handling of record separators (Was: Re: [csv] release 1.0?)
Date Tue, 01 Jul 2014 06:13:22 GMT
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 <ecki@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 <britter@apache.org>:
>
> > 2014-06-30 11:00 GMT+02:00 Tillmann Gaida <tillmann.gaida@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.reid@gmail.com> wrote:
> > > > On Sun, Jun 29, 2014 at 3:50 PM, Benedikt Ritter
> > > > <britter@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-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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