commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [VOTE] Promote [csv] to Commons proper
Date Wed, 07 Mar 2012 19:57:16 GMT
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 <simonetripodi@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 <garydgregory@gmail.com> wrote:
>> On Wed, Mar 7, 2012 at 7:09 AM, Emmanuel Bourg <ebourg@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: garydgregory@gmail.com | ggregory@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-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
View raw message