As the original creator of [flatfile] it would be interesting to see how difficult it would be to make [flatfile] do any of the things that [csv] can currently do; e.g. [flatfile] can already handle a delimited column structure.
On Wed, Mar 7, 2012 at 1:31 PM, Simone Tripodi <simonetrip...@apache.org> wrote: > Hi all, > > IMHO if you could implement the readers as XMLReader instances, you > can get benefit from the powerful Digester matching rules and POJOs > mapping. > I had a spike with Digester reading JSON via a javacc grammar but it > was not complete so never proposed it. > > just my 0.0000002 cents, > -Simo > > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ > > > > On Wed, Mar 7, 2012 at 8:11 PM, Gary Gregory <garydgreg...@gmail.com> wrote: >> On Wed, Mar 7, 2012 at 7:09 AM, Emmanuel Bourg <ebo...@apache.org> wrote: >> >>> Le 07/03/2012 12:57, sebb a écrit : >>> >>> >>> Since CSV is currently only a single package with very few classes, >>>> would it perhaps be suitable as a part of an existing Commons >>>> component? >>>> >>> >>> [csv] is still small but will probably increase in size as more features >>> are integrated (like the bean mapping). I prefer to leave it as an >>> independent component. If it was to be merged with another component in the >>> future I think [flatfile] would be a better candidate. >> >> >> I like the name [flatfile], it does imply something more generic than just >> *Comma* separated values. >> >> I am intrigued by the idea of merging this into an existing component but I >> do not see which one would really fit. [io] comes close but I my mind >> [flatfile] could evolve into a JDBC driver. When I think about it that way, >> it does not fit into [io]. >> >> I do like the idea of merging certain things though, so I might bring up >> merging [exec] into [lang] for example... >> >> Gary >> >> >> >>> >>> >>> [This would solve the package name issue.] >>>> >>> >>> Let's not try contortions to solve this issue. We have to admit that the >>> impact is limited. The solr-commons-csv artifact is not widely used, Solr >>> is going to fix the next releases, and for people importing the previous >>> release it'll be possible to exclude the dependency to avoid a conflict. >>> >>> It's not perfect but it's good enough to keep the current package and >>> class names unchanged. Well put a warning on the main page to document the >>> issue. >>> >>> Emmanuel Bourg >>> >>> >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 >> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory > > --------------------------------------------------------------------- > 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
