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
