v4.0.0 is a new major release available today, 10 Oct 2016. Enhancements include:
- A greatly improved Validation framework.
- Validation findings are now less reliant on textual descriptions and allow calling code to review and process the findings from code.
- Automatic repairs made by the framework are be logged with before/after copies of the objects, and callers are be able to control which repairs are made.
- Developers are be able to write their own validators and register them into the validation framework.
- Reworked support for Custom Tags.
- Custom (i.e., user-defined) tags are now handled as first-order classes in the object model and parsed as CustomFact objects, which can have fully parsed notes, citations, change dates, and more.
- The StringWithCustomTags class is now a StringWithCustomFacts class.
- Setting the StringWithCustomFacts properties is now much easier, with overloaded setters that accept either StringWithCustomTags objects or regular String objects for the value.
- Built-in support for custom tags defined by third-party software packages.
- Adapters make it easy to access and manipulate the CustomFacts in files from popular third-party products.
- Support for Family Tree Maker 3, Legacy Family Tree 8, and Family Historian are included.
- The framework is extensible with potential for other adapters for other products in the future.
- References to StringWithCustomTags will need to be changed to references to StringWithCustomFacts instead.
- References to GedcomValidator should be replaced with Validator - but this should only affect you if you are directly accessing the validator. Most users only access the validation framework implicitly in the GedcomWriter, and using the writer hasn't really changed...although the validation findings have changed their formats.
- Most of the enums in the library have been moved to the org.gedcom4j.model.enumerations package, so you may need to touch up your imports.
- References from Family objects to the Individuals in it now have an intermediate object called an IndividualReference, so there's a place to store custom tag data on those relationships. Direct references didn't allow this, so data in GEDCOM files was going unparsed and ignored (see issue #167). Similar classes have been added for other root-level classes (such as FamilyReference, SubmitterReference, RepositoryReference, etc.).