Am 27.07.2012 15:56, schrieb Elijah Zupancic:
I didn't know that Jackson supported YAML. Wow, that sounds like a
great solution.
-Elijah
+1, looks indeed promising. Maybe also interesting for [configuration].
Oliver
On Fri, Jul 27, 2012 at 2:08 AM, Simone Tripodi
<simonetrip...@apache.org> wrote:
Hi all [chain2] people,
looks like what we have in /trunk is good already to cut a first RC -
anyway I would like to spur all involved people to be more "visionary"
and do more work now :P
Just to put more food for thoughts, for the configuration side: I
would like to invite you on evaluating the Jackson[1] library wich is
natively JSON and now supports data binding for more formats[2], XML,
YAML and Smile included!
Hopefully, with Jackson we could get rif of the Digester and have a
universal underlying parser wich supports more formats... how does it
sound? Maybe we won't need multiple config submodules anymore!
About licensing, Jackson is available under ALv2.
This is something that worths investigate - WDYT?
all the best, have a nice day!
-Simo
[1] http://wiki.fasterxml.com/JacksonHome
[2] http://www.cowtowncoder.com/blog/archives/2012/04/entry_472.html
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Fri, Jul 27, 2012 at 3:55 AM, Elijah Zupancic <eli...@apache.org> wrote:
For this particular project I would rather take the approach of writing a
[configuration] based configuration and then extending [configuration] to
support other formats.
-Elijah
On Thursday, July 26, 2012, Simone Tripodi wrote:
Hi Oliver,
we are on the same path!!! I had the idea of realizing an "universal"
parser (XML/JSON/YAML/INI) just writing XML readers adapters :)
good thought!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Thu, Jul 26, 2012 at 9:37 PM, Oliver Heger
<oliver.he...@oliver-heger.de> wrote:
Slightly off-topic:
Do you think the following approach could work: Consider there is a
central
component - e.g. [flatfile] in sandbox - which implements parsers for
various text-base formats like YAML, JSON, CSV, ... and a generic
mechanism
for transforming the parsed data into XML SAX events. Then in theory it
would be possible that all XML-based Commons components like [digester],
[configuration], or [jelly] could directly read such formats.
WDYT?
Oliver
Am 26.07.2012 16:10, schrieb Simone Tripodi:
Good!
hopefully Bruno can provide some help/advice to Elijah!
Thanks,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Thu, Jul 26, 2012 at 3:43 PM, Bruno P. Kinoshita
<brunodepau...@yahoo.com.br> wrote:
+1
I used SnakeYaml in a project [1] that parses TAP test streams and in
some Jenkins plug-ins, and had a look at the source code too. It works
very
well with the latest YAML spec and the source code is very neat and
with
many tests.
TestNG uses SnakeYaml for parsing YAML configuration of test suites too
[2].
[1] http://www.tap4j.org
[2] https://github.com/cbeust/testng/blob/master/pom.xml#L124
Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com
________________________________
From: Simone Tripodi <simonetrip...@apache.org>
To: Commons Developers List <dev@commons.apache.org>
Sent: Thursday, 26 July 2012 4:58 AM
Subject: Re: [chain2] configuration façade APIs
I may draft up a prototype using YAML as a configuration source, just
to make sure that it in fact is a good abstraction. I noticed that
the
SnakeYaml parser is under the Apache 2.0 license
(http://code.google.com/p/snakeyaml/). I'm assuming that it wouldn't
be a problem to take it as a dependency.
+1!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
