Hi everyone, This weekend commons-csv 1.1 was released, thus I've updated the pull-request with the latest version.
Have a nice day, Antoine. 2014-11-07 18:39 GMT+01:00 Antoine DESSAIGNE <antoine.dessai...@gmail.com>: > Hi everyone, > > Since it's a pretty big pull-request, I'm going to explain the changes > I've made and the reasons for them. > > The most obvious change is the model of commons-csv. > Previously, commons-csv was using 2 objects, a CSVStrategy and a > CSVConfig, that we configured using a getter/setter approach. They no > longer use these objects and this approach but a single CSVFormat object. > This CSVFormat object is created by applying changes on a reference format, > each change produces a new CSVFormat object. > Thus, now you can set the reference format (before applying any changes) > either using the object directly or its common name. > > Also, there is a lot of nice configuration options of the format, I > decided to make them all configurable using the Java API or the Spring API. > For those options, null often means that the feature is disabled. Since for > the data format null means "unconfigured, use default", I've added a > "disabled" options for each CSVFormat option. > > In commons-csv, the most interesting option is the header configuration. > You can specify the headers using a String array. If you want automatic > headers, you need to use an empty array. If you want to disable the headers > you need to pass null. Obviously you can configure all that using either > the Java API or the Spring API (using children <header> tags). A > consequence of exposing this configuration is that you no longer need the > autogenColumns parameter, thus I removed it. > > Also, in order to ease the readability of the code, I've created 2 > classes: CsvMarshaller and CsvUnmarshaller. The CsvDataFormat delegates to > them the marshalling and unmarshalling processes. These classes also handle > the different meaning of the same option like "skipHeaderRecord". When > unmarshalling you're indicating that there is an header row that you don't > want to read. When marshalling you're indicating that the header row should > not be written. > > I really hope that you'll find in this email the reasons behind the > changes you saw in the code. > > Anyhow, If you want to review the code with me, I will be more that happy > to organize it using Skype. > > Also, as you may have noticed it's a pretty big change and thus maybe it > should be in another data format module (csv1 ?). > > Have a nice day, > > Antoine. > > 2014-11-05 20:14 GMT+01:00 Claus Ibsen <claus.ib...@gmail.com>: > >> Hi >> >> Thanks. I think its a good time to migrate this in Camel 2.15. But the >> PR has merge conflicts now. Do you mind rebasing so the PR can be >> merged on master branch? >> >> >> >> On Wed, Oct 15, 2014 at 12:10 PM, Antoine DESSAIGNE >> <antoine.dessai...@gmail.com> wrote: >> > Hi everyone, >> > >> > I've submitted this PR https://github.com/apache/camel/pull/292 for >> > updating csv to the official version >> > >> > What do you think ? >> > >> > Have a nice day. >> > >> > Antoine. >> > >> > 2014-09-12 11:59 GMT+02:00 Antoine DESSAIGNE < >> antoine.dessai...@gmail.com>: >> > >> >> Hi, >> >> >> >> I don't see how it can be compatible since the public API of >> CsvDataFormat >> >> relies on 2 classes that were deleted : CSVStrategy and CSVConfig. >> >> >> >> I'm also not convinced by a camel-csv2 component since it's common-csv >> >> version 1. I would rather have another component ("camel-csv-commons" >> ?) >> >> that publishes the <commons-csv> data format (or <csv-commons>). >> >> >> >> Which is the right way ? >> >> >> >> Also, I didn't managed to build the master. I keep having "Failed to >> >> execute goal >> >> >> org.apache.camel:camel-api-component-maven-plugin:2.15-SNAPSHOT:fromApis >> >> (generate-test-component-classes) on project camel-box: Error >> generating >> >> source for >> com.box.boxjavalibv2.resourcemanagers.IBoxCollaborationsManager: >> >> String index out of range: 1" >> >> >> >> What did I do wrong ? >> >> >> >> Thanks. >> >> >> >> Antoine >> >> >> >> 2014-09-11 21:56 GMT+02:00 Christian Müller < >> christian.muel...@gmail.com>: >> >> >> >>> +1 >> >>> >> >>> I think a camel-csv2 component is not necessary. >> >>> >> >>> Best, >> >>> >> >>> Christian >> >>> ----------------- >> >>> >> >>> Software Integration Specialist >> >>> >> >>> Apache Member >> >>> V.P. Apache Camel | Apache Camel PMC Member | Apache Camel committer >> >>> Apache Incubator PMC Member >> >>> >> >>> https://www.linkedin.com/pub/christian-mueller/11/551/642 >> >>> >> >>> On Thu, Sep 11, 2014 at 2:30 AM, Willem Jiang <willem.ji...@gmail.com >> > >> >>> wrote: >> >>> >> >>> > When I upgraded the http client version of camel-http4 to 4.3.x, >> there >> >>> > were some API changes in http client just like common-csv. As we >> can do >> >>> > some adaption inside camel-http4, I just changed the configuration a >> >>> bit. >> >>> > I think we can do the same thing in camel-csv :) >> >>> > >> >>> > -- >> >>> > Willem Jiang >> >>> > >> >>> > Red Hat, Inc. >> >>> > Web: http://www.redhat.com >> >>> > Blog: http://willemjiang.blogspot.com (English) >> >>> > http://jnn.iteye.com (Chinese) >> >>> > Twitter: willemjiang >> >>> > Weibo: 姜宁willem >> >>> > >> >>> > >> >>> > >> >>> > On September 10, 2014 at 10:57:03 PM, Claus Ibsen ( >> >>> claus.ib...@gmail.com) >> >>> > wrote: >> >>> > > Hi >> >>> > > >> >>> > > Welcome back. >> >>> > > >> >>> > > I suspect the breakings is less affected by Camel users, eg I >> would >> >>> > > assume the data it creates on the Camel Exchange / Message / body >> / >> >>> > > headers can be the same as before? So the changes affected is >> maybe >> >>> > > how to configure it using the csv data format or its csv config >> >>> > > object? >> >>> > > >> >>> > > I am fine to make this change for Camel 2.15 and add some notes >> to the >> >>> > > release notes that end users need to do some changes. >> >>> > > >> >>> > > >> >>> > > >> >>> > > On Wed, Sep 10, 2014 at 4:46 PM, Antoine DESSAIGNE >> >>> > > wrote: >> >>> > > > Hi everyone, >> >>> > > > >> >>> > > > I was looking at this issue : >> >>> > > > https://issues.apache.org/jira/browse/CAMEL-7716. >> >>> > > > >> >>> > > > In fact, the commons-csv library changed a lot between the >> version >> >>> that >> >>> > > > camel uses and the official one. In addition, there is lot of >> nice >> >>> > stuff >> >>> > > > such as: >> >>> > > > * immutable configurations, it's no longer required to copy the >> >>> > > > configuration >> >>> > > > * build-in iterator mechanism >> >>> > > > * etc... >> >>> > > > >> >>> > > > Supporting the commons-csv API would break the compatibility >> with >> >>> > existing >> >>> > > > code and usage. >> >>> > > > >> >>> > > > What should I do ? Break compatibility ? Create a new data >> format ? >> >>> > > > >> >>> > > > Thanks a lot for your insights on this matter, >> >>> > > > >> >>> > > > Have a nice day, >> >>> > > > >> >>> > > > Antoine. >> >>> > > > >> >>> > > > PS: I was very busy, but now I managed to freed up time for >> camel :) >> >>> > > >> >>> > > >> >>> > > >> >>> > > -- >> >>> > > Claus Ibsen >> >>> > > ----------------- >> >>> > > Red Hat, Inc. >> >>> > > Email: cib...@redhat.com >> >>> > > Twitter: davsclaus >> >>> > > Blog: http://davsclaus.com >> >>> > > Author of Camel in Action: http://www.manning.com/ibsen >> >>> > > hawtio: http://hawt.io/ >> >>> > > fabric8: http://fabric8.io/ >> >>> > > >> >>> > >> >>> > >> >>> >> >> >> >> >> >> >> >> -- >> Claus Ibsen >> ----------------- >> Red Hat, Inc. >> Email: cib...@redhat.com >> Twitter: davsclaus >> Blog: http://davsclaus.com >> Author of Camel in Action: http://www.manning.com/ibsen >> hawtio: http://hawt.io/ >> fabric8: http://fabric8.io/ >> > >
