Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Looking for means to persist collections of Strings in project settings

Hi Martin,

No objection - go for it. I submitted an update for ClearlyDefined, and I believe if it is accepted you will be able to use 1.27 easily too without having to raise a CQ, although it still would need adding to orbit. 

This is a great contender to add to orbit as it has no dependencies of its own and the 5 minute flow works well for it: https://wiki.eclipse.org/Orbit/Adding_Bundles_To_Orbit_In_5_Minutes - use:

instead of 
<ipzilla bug_id=""/>

in the ip_log.xml's <legal> section. Let me know if you need help with this flow so you can use 1.27 if 1.14 is too old.

Thanks
Jonah



~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Mon, 2 Nov 2020 at 19:20, 15 knots <fifteenknots505@xxxxxxxxx> wrote:
Hi all,
I already asked a similar question here and was encouraged to not use the .cproject/XmlStorage mechanism for new code.
I need to persist lists of integral values (int, boolean, String) and, if feasible, to persist (String-)key-value pairs, all of these in an SCM-friendly way. The RCP and eclipse APIs as well as the java property-file API do not allow to store lists.

Basically I want sth. that does the same as Java serialization does for *Java beans*, but stores the data as text files.
Some options I evaluated in this field:

- XML: (quite a bit of the 90ties, but anyway
-- The CDT .cproject/XmlStorage mechanism. It looks like an attemp to persist properties coming in from multiple plugins in a singel file. Tedious and error-prone.
-- I looked at apache xmlbeans and found it seems to be more a XML-schema-to-java-classes generator. At my short glance, it seems to require an xml schema definiton to start from.
-- x-stream [1]. Jenkins uses it to (de-)serialize configuration classes. OOTB it uses *field names* as XML tags which will make persisted data un-readable if a field gets renamed. But it comes with a JavaBeanConverter [2] which might help to write *JavaBean property names* to XML instead of field names to avoid breaking persisted data when fields are renamed.

- YAML:
-- snakeyaml is in eclipse orbit (as v 1.14; current version is 1.27).

I would prefer to use snakeyaml since it can persist JavaBean objects which is much easier to code than access to property maps.

Does anyone object if I would add snakeyaml to the current target platform and use it?

Regards,
    Martin

[1] https://x-stream.github.io/
[2] https://x-stream.github.io/javadoc/com/thoughtworks/xstream/converters/javabean/JavaBeanConverter.html

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev

Back to the top