Giter Club home page Giter Club logo

lexeme's Introduction

LeXeMerger

https://maven-badges.herokuapp.com/maven-central/com.github.maybeec/lexeme/

Branch Build Coverage

master

Build Status

badge

development

Build Status

badge

Description

The Language-aware XML Merger (for short LeXeMe) is a 2-way XML merger that allows to influence the structural merge by declaring additional structural information. Therefore, a so called merge schema can be specified for each namespace, which itself is a XML document that will be parsed and used by LeXeMe as an additional input for the structural merge.

Maven usage

<dependencies>
  <dependency>
    <groupId>com.github.maybeec</groupId>
    <artifactId>lexeme</artifactId>
    <version>1.0.0</version>
  </dependency>
<dependencies>

Features

A merge schema allows to specify …​

  • …​ what properties of a XML element should be considered while matching elements from the base with elements from the patch

  • …​ XML elements can or should occur only once or more often as children of a specific XML node

  • …​ whether the value of an attribute of the patch is allowed to be attached to the base value or not

  • …​ whether the textual content of an XML node of the patch is allowed to be attached to the base textual content or not

  • …​ different merge rules (called handlings) depending on the XML elements location in the DOM node tree

LeXeMe is able to …​

  • …​ perform four conflict handlings (override with patch’s or base’s contents as well as attaching attributes and text contents when it’s desired or not)

  • …​ optionally validate the merge result

Usage

The api of the LeXeMe library is the LeXeMerger class.

To instanciate a merger you need to specify a folder in that LeXeMe will search for merge schemas. The merge process will use default settings for each namespace that has no merge schema in that folder.

LeXeMerger merger = LeXeMergerFactory.build("path/to/merge/schemas/");

The merger is now set and ready to merge XMl documents. Depending on the namespace of the documents the algorithm chooses the corresponding merge schema (if one is found).

org.jdom2.Document result = merger.merge(org.jdom2.Document baseDoc, org.jdom2.Document patchDoc, ConflictHandlingType c);

Interfaces

LeXeMe provides multiple interfaces for the merge() method using org.jdom2, java.nio.File and plain String objects:

org.jdom2.Document merge(Document base, Document patch, ConflictHandlingType c)
org.jdom2.Element merge(Element base, Element patch, ConflictHandlingType c)
org.jdom2.Document merge(File base, String patch, String charset, ConflictHandlingType c)
String mergeInString(File base, String patch, String charset, ConflictHandlingType c)

ConflictHandlingTypes

LeXeMe supports 4 strategies to handle conflicts during the merge process:

Prefere values from Base

Prefere values from Patch

No text attachment

BASEOVERWRITE

PATCHOVERWRITE

Text attachment

BASEATTACHOROVERWRITE

PATCHATTACHOROVERWRITE

lexeme's People

Contributors

maybeec avatar themetalone avatar jan-vcapgemini avatar may-bee avatar

Watchers

James Cloos avatar  avatar

lexeme's Issues

Refactor namespaces

Due to issues with the maven naming conventions and my username, I had to rename my GitHub account. Thus, we have to change the namespace also in Java and MergeSchemas.

Precondition for #5

Considering Information from XSD and DTD

At the moment LeXeMe assumes either one or arbitary many elements while merging. This information is contained in the definition schematas. LeXeMe should use those information to improve the quality of the merge

Introduce Leaf Elements

At the moment all elements are in both base and patch will eventually be present in the merge result. Although in some use case (e.g. html forms) this may not be the desirable result.

LeXeMe should therefore introduce the concept of a leaf element, i.e. an element whose sub tree won't be merged after a match but either replaced by the base or the patch elements sub tree.

This can be done by adding a new attribute to the handling element that indicates such a leaf element.

Properly Initialize the generated Classes

During testing I found that the generated classes use trivial constructors.
This leads to the problem that empty MergeSchemas come with a lot of NullPointers that can cause the system to break

Failing Travis Build

The Travis Build fails but the local builds don't.

The Problem seems to be that Travis cannot access/parse the merge schemas properly.

XSD Clean up

  • Remove unused content
  • Apply name conventions
  • Refactor any problems

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.