search

Mause / snakeyaml

Automatically exported from code.google.com/p/snakeyaml
Apache License 2.0
0 stars 0 forks source link

Support for Thrift types #161

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
This is a feature request:

I'd like to be able to parse yaml into a Thrift object. Thrift generated 
classes differ slightly from JavaBean semantics, so java.beans.Introspector 
fails to find getter, setter methods. Instead, FieldProperty instances end up 
being used to access and update Thrift type public fields. Unfortunately, if 
you set a Thrift object's field directly without using its associated setter, 
internal "isSet" state for that field isn't updated, so things break.

I've created a simple subclass of PropertyUtils and Properties 
(ThriftPropertyUtils, ThriftProperty) which make use of 
com.twitter.elephantbird.thrift.TStructDescriptor (from Twitter Elephant Bird 
Core) and Thrift APIs to resolve the above issue, but perhaps there's a cleaner 
mechanism by which this can be achieved.

If there's interest, I'd be happy to contribute this code.

Original issue reported on code.google.com by andrew.s...@gmail.com on 14 Nov 2012 at 8:55

GoogleCodeExporter commented 9 years ago 
Feel free to contribute the code.

Original comment by py4fun@gmail.com on 14 Nov 2012 at 3:22

GoogleCodeExporter commented 9 years ago 
Does Google Code support github-esque pull requests? I'm new to hg, so for now 
I'll just post a patch file.

Original comment by andrew.s...@gmail.com on 14 Nov 2012 at 6:58

GoogleCodeExporter commented 9 years ago 
See attached for patch which adds "snakeyaml-thrift" extension module 
containing subclasses and unit tests.

Original comment by andrew.s...@gmail.com on 14 Nov 2012 at 7:01

Attachments:

GoogleCodeExporter commented 9 years ago 
Google code does not have the 'pull request' but you can clone a repository 
(http://code.google.com/p/snakeyaml/source/clones) and we can pull your changes 
when we get the green light.

This is a major change. At the moment SnakeYAML does not have any dependency at 
all. This proposal introduces not only Java dependencies but also Thrift must 
be installed in order to run the tests.
If you need to make a change in the core SnakeYAML to support Thrift then let 
us see what we can do.

Original comment by py4fun@gmail.com on 16 Nov 2012 at 8:35

GoogleCodeExporter commented 9 years ago 
The new code introduces no new dependencies to the core SnakeYAML module. 
Instead, it adds a new module which isolates the new dependencies. A maven 
build within the root (core) module should be completely unaffected by the new 
module. Users interested in building the thrift module would need the thrift 
binary installed.

Original comment by andrew.s...@gmail.com on 16 Nov 2012 at 8:39

GoogleCodeExporter commented 9 years ago 
Should we create a separate independent project for this code ? What are the 
advantages to have the two projects together ?

Original comment by py4fun@gmail.com on 16 Nov 2012 at 7:41

GoogleCodeExporter commented 9 years ago 
I feel like it might be best to keep direct extensions to snakeyaml close to 
home, bundled within the same source repo. Here are some motivations:

* Easy for users to find extensions if they're all hosted in one place.
* Extensions which are hosted here are more likely to be trusted by end users.
* Code reviews are likely to be of higher quality given snakeyaml authors are 
involved.
* Easy for contributors to pattern new extensions after existing ones.
* It's become somewhat standard practice to bundle extensions in this way. See 
for instance Apache Hadoop and Pig.

Original comment by andrew.s...@gmail.com on 22 Nov 2012 at 10:42

GoogleCodeExporter commented 9 years ago 
Another for the list: As snakeyaml is improved / refactored, extensions are 
more likely to be kept up-to-date by community if they're included here.

Original comment by andrew.s...@gmail.com on 22 Nov 2012 at 10:44

GoogleCodeExporter commented 9 years ago 
1) I think most of the above is perfectly valid even if the source is hosted as 
a separate repository
2) if this extension is inside SnakeYAML, it implies the SnakeYAML team is 
responsible for maintenance. At the moment we cannot even build it because of 
too heavy external dependencies. Do you expect the SnakeYAML team to support 
this extension ?
3) Apache Hadoop and Pid is a good example. Pig resides in a separate 
repository, and they may have an independent release cycle
http://svn.apache.org/viewvc/pig/trunk/

Original comment by py4fun@gmail.com on 23 Nov 2012 at 8:45

GoogleCodeExporter commented 9 years ago 
> 1) I think most of the above is perfectly valid even if the source is hosted 
as a separate repository

I don't see how most of my arguments could be construed to support hosting the 
thrift extension in a separate repo.

> 2) if this extension is inside SnakeYAML, it implies the SnakeYAML team is 
responsible for maintenance. At the moment we cannot even build it because of 
too heavy external dependencies. Do you expect the SnakeYAML team to support 
this extension ?

Any contribution which is accepted by an OSS project I'd expect to be 
supported. If the burden of support is too great, I'd suggest looking for more 
maintainers / committers, or simply rejecting the contrib.

> 3) Apache Hadoop and Pid is a good example. Pig resides in a separate 
repository, and they may have an independent release cycle 
http://svn.apache.org/viewvc/pig/trunk/

To clarify, both Hadoop and Pig include contrib paths within their repos which 
include separate projects and extensions for those projects, respectively. The 
contribs are maintained along with the parent project:

http://svn.apache.org/viewvc/pig/trunk/contrib/
http://svn.apache.org/viewvc/hadoop/common/tags/release-0.20.2/src/contrib/

Please feel free to close this issue.

Original comment by andrew.s...@gmail.com on 23 Nov 2012 at 5:26

GoogleCodeExporter commented 9 years ago

Original comment by py4fun@gmail.com on 3 Jan 2013 at 2:52