diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md new file mode 100644 index 0000000..cdb319e --- /dev/null +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -0,0 +1,49 @@ +--- +name: Bug report +about: Create a report to help us improve +title: '' +labels: 'Prio: Triage, Status: Pending, Type: Bug' +assignees: '' + +--- + + + + + +## Bug report + +## Expected Behavior - What where you expecting to happen? + + +## Current Behavior - What happens? + + +## Possible Solution + + +## What are the steps to reproduce this issue? (for bugs) + + +1. +2. +3. + +## Context + + + +## Any logs, error output, etc? + +## Your Environment + +* Version used: +* Environment name and version (e.g. Chrome 39, node.js 5.4): +* Operating System and version (desktop or mobile): + +## Notes and further information diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md new file mode 100644 index 0000000..5b36483 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/feature_request.md @@ -0,0 +1,33 @@ +--- +name: Feature request +about: Suggest an idea for this project +title: '' +labels: 'Prio: Triage, Status: Pending, Type: Feature' +assignees: '' + +--- + + + + + +# Feature request + +## Expected Behavior - What where you expecting to happen? + + +## Current Behavior - What happens? + + +## Possible Solution + + +## Context + + +## Notes and further information diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md new file mode 100644 index 0000000..1166485 --- /dev/null +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -0,0 +1,65 @@ + + + + +## Type of request + +- [ ] Bug fix (non-breaking change which fixes an issue) +- [ ] New feature (non-breaking change which adds functionality) +- [ ] Breaking change (fix or feature that would cause existing functionality to change) +- [ ] Refactoring +- [ ] Documentation or documentation changes + +## Related Issue(s) + + + + + +## Concept + +#### Description of the change + +#### Description of current state +#### Description of target state + +#### Estimated investment / approximate investment + + +#### Initiator +name / company / position / created at + + +## Technical information +#### Platform / target area + + +#### known side-effects +#### other +#### DB Changes (if so: incl. scripts with definitions and testdata) + + + +#### How has this Tested? + + + + +#### Screenshots, Uploads, other documents (if appropriate): + + +## Checklist: + + +- [ ] My code follows the code style of this project. +- [ ] I agree with die CLA. +- [ ] I have read the CONTRIBUTING docs. +- [ ] I have added/updated necessary documentation (if appropriate). \ No newline at end of file diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md new file mode 100644 index 0000000..23e44cc --- /dev/null +++ b/CODE_OF_CONDUCT.md @@ -0,0 +1,52 @@ +# Contributor Covenant Code of Conduct + +## Our Pledge + +In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. + +## Our Standards + +Examples of behavior that contributes to creating a positive environment include: + +* Using welcoming and inclusive language +* Being respectful of differing viewpoints and experiences +* Gracefully accepting constructive criticism +* Focusing on what is best for the community +* Showing empathy towards other community members + +Examples of unacceptable behavior by participants include: + +* The use of sexualized language or imagery and unwelcome sexual attention or advances +* Trolling, insulting/derogatory comments, and personal or political attacks +* Public or private harassment +* Publishing others' private information, such as a physical or electronic address, without explicit permission +* Other conduct which could reasonably be considered inappropriate in a professional setting + +## Our Responsibilities + +Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. + +Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. + +## Scope + +This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. + +## Enforcement + +Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at hello@aposin.org. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. + +Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. + +## Escalation + +To report an issue with the project leadership team, please contact Matthias Holzer ([@holzerma](https://github.com/holzerma)) or Markus Rothmueller ([@MarRothm](https://github.com/MarRothm)) via GitHub. + +## Attribution + +This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version] + +[homepage]: http://contributor-covenant.org +[version]: http://contributor-covenant.org/version/1/4/ + + diff --git a/CODING_MANIFEST.md b/CODING_MANIFEST.md new file mode 100644 index 0000000..5bd6c5c --- /dev/null +++ b/CODING_MANIFEST.md @@ -0,0 +1,134 @@ + + + +# Coding Manifest +### Introduction +We are very happy, you are interested in this project! :metal: + +If you have any questions, please read the relevant docs on this GitHub repositories and our FAQ on the website first, there is a good chance some questions may be answered already. + +The contributed code, task, concept or design needs to fit into the general system architecture and must provide the key principles described below. + +## 1. How we work +### 1.1 Branches +In this project there will be one branch: +> **master** +>This is the projects main branch, where all Pull Requests, will be merged into. Of course this branch may be instable. + +We will not provide a stable branch. Stable versions will be tagged directly on the master branch. + +### 1.2 Workflow +In our projects we prefer a lightly customized GitHub Workflow, to get a more detailed level in the pull request / review process. Basic concept is built on the following standard [workflow](https://guides.github.com/introduction/flow/). + +The key aspects of the used workflow are as follows: +- Each developer pushes to their own repository and pulls from others. +- Developers who want to make a change to another repository, create a fork on GitHub and work on their own clone. +- When forked repositories are ready to be merged, Pull Requests are sent to the original repository maintainer. +- The Pull Requests include all of the proposed changes, project and code specific policies and their associated discussion threads. +- Whenever a Pull Request is accepted, the change is merged by the maintainer (integration manager and/or dictator) and pushed to their blessed repository. + +In order to be able to contribute to one of the association’s projects you must open a Pull Request. You should usually open a Pull Request in the following situations: +- Submit trivial fixes (for example, a typo, a broken link or an obvious error) +- Start work on a contribution that was already asked for, or that you’ve already discussed, in an issue +- A Pull Request may be one of the following types: + - idea for a solution (as basis for further exchange) + - solutions for an (open) issue + - bugfix + - new feature implementation + - code parts / snippets for a related issues + - improvement of code + - new documentation / documentation changes + - anything else relevant to the project + +A Pull Request doesn’t have to represent finished work. It’s usually better to open a Pull Request early on, so others can watch or give feedback on your progress. Just mark it as a “WIP” (Work in Progress) in the subject line. You can always add more commits later. + +Please check out our [contribution guideline](CONTRIBUTING.md) for a detailed description. + +### 1.3 Issues / Pull requests mandatory information +For creating Issues or Pull Requests please use the provided templates. +Our maintainers will check the formal requirements first. + +Please check out our [contribution guideline](CONTRIBUTING.md) for a detailed description. + +## 2 Project Standards & Quality Standards + +### 2.1 Coding Standards + +New contributions should meet the general java code conventions (see ). + +All code contributions must meet the following coding guidelines: + +* Your code must not contain any compile errors or warnings (some warnings reported by Eclipse IDE may be allowed) +* Your code must not contain any problems reported by SpotBugs +* Don't implement god classes (classes with several 1,000 lines of code) +* Public API (classes, methods, variables, ...) must contain Javadoc. It is recommended also to document internal API. +* Don't commit Sysouts. Use logger to monitor the correct and expected program workflow. +* Implement JUnit-Tests against new and changed code parts. +* All JUnit-Tests must pass (green). +* JUnit-Tests should be integrated into the buid process (e.g. Maven). +* Binary artifacts (dlls, jars, etc.) are not allowed to be checked in. They should be referenced from the provided Nexus server. + +### 2.2 Recommendations and hints + +* Use the proposed Eclipse IDE for code contributions. +* Use the proposed setup process Oomph of the project. (if any) +* Use the AdoptOpenJDK JVM binaries from +* Use SpotBugs to identify and avoid bad and illegal coding patterns (a reference configuration will follow soon). +* Use SonarQube to identify code smells, bugs and vulnerabilities. +* Think about modularity during the implementation (e.g. new features can be added as optional artifacts). +* Code and documentation must be done only in English. +* Think about appropriate names for classes, methods and variables + * Don't use naming shortcuts, e.g. EM for ExecutionManager + * Don't use only general names (e.g. Manager, Util, etc.) + * Name the classes, methods and variables suitable to their responsibility (e.g. IRunnable implementation checking the version can be called CheckVersionRunnable) + +Your code needs to run on all supported systems. (Java / operating systems). + +### 2.3 Conventions +The contributed code, task, concept or design needs to fit into the general system architecture and must provide the following key principles: + +##### Internationalization +- Always use English language for names, variables, classes, definitions, packages, comments etc. +- outsourcing from text parts into properties (resource files), so that the project can be easily translated +- no queries against locale specific +- developer messages might not need to be internationalized (e.g., debug logging, exception messages not relevant to the user, etc). + +##### Scalability +- Every new extension must be open and designed so they are easily extended for other usecases. Other requirements must not be influenced in any case. + +##### Multi Tenancy +- Functional or technical extensions must fit the multi-tenancy concept. + +##### Multi-Currency +- Functional or technical extensions must fit the multi-currency concept. + +##### Time Zones +- Functional or technical extensions must fit the the current time-zone concept. + +### 2.4 Tests +- Implement JUnit-Tests against new and changed code parts. +- All JUnit-Tests must pass (green). + +### 2.5 Versioning +versioning (tdb) + +## 3 Development workflow + +Creation of new functional and technical artefacts may follow our standardized development process: +- General approval for project relevance. +- Conception/Discussion for changes in the data model +- Creation of a functional design (if needed) with a follow-up approval +- Creation of a technical design (if needed) with a follow-up approval +- Implementation of the functionality / feature + - Please stick to our standards and general architecture guidelines: + - Implementation should be in the correct plugins (for modularization), packages or classes. + - Strictly make use of the correct layers (Business-, Dialog-, UI-,Adapter) (if needed) +- Implementation of Unit- and/or Integration Tests +- Review from one of our maintainers + - Always keep in mind, that the code must fulfill performance and security requirements in order to get accepted. + + + + + + diff --git a/Individual CLA.txt b/Individual CLA.txt new file mode 100644 index 0000000..240efec --- /dev/null +++ b/Individual CLA.txt @@ -0,0 +1,104 @@ +Grant of Rights + +(for contributions by Non-Members) + +between + +Verein zur Förderung quelloffener Versicherungssoftware und Etablierung offener Schnittstellenstandards in der Versicherungsbranche (Association for the promotion of open-source insurance software and for the establishment of open interface standards in the insurance industry) +Hietzinger Kai 101-105 +1130 Wien +AUSTRIA + +("Association") + +and + +[Company/Person] +[Street] +[City] +[Country] + +("Contributor") + +(each a "Party", together the "Parties"). +1. Preamble +1.1. The Association is a non-profit association established under the laws of Austria and founded for the promotion of open-source insurance software and for the establishment of open interface standards in the insurance industry. The Association will run one or more open source projects now or in the future. [Marketing language to be added]. +1.2. Contributor wishes to contribute to the project(s). +2. Grant of Rights +The Contributor agrees that all contributions to the project are subject to the following terms. This document needs to be signed and submitted with any contribution: +2.1. Scope of Rights granted +2.1.1. The Contributor hereby grants to the Association the royalty-free, irrevocable and non-exclusive right to use all contributions by any currently known and any future forms of exploitation without any limitations as to time, scope or territory, and particularly grants the right to reproduce and distribute it, to rent and lend it, to broadcast and communicate it to the public by wire or wireless means, to publicly recite, perform and present it, to make it available and to transfer and sublicense any such rights to the contribution against consideration or royalty-free to any third parties who may use the contribution to the same extent. The Association may further itself or through third parties make adaptations, arrangements and other alterations of the contributions and may exploit such adaptions, arrangements or alterations to the same extent and may also grant third parties rights to the same extent. For the avoidance of doubt, all contributions are provided at no charge and royalty-free. +2.2. Distribution under the Apache 2.0 license +2.2.1. The Association currently plans to license the open source software, which may contain the Contributor's contribution, on basis of the Apache 2.0 license. The Contributor explicitly acknowledges this fact, consents to the inclusion of its contributions to the open source software and issuance under the Apache 2.0 license, guarantees and warrants that the contribution is eligible to be published under such license. +2.2.2. The Association reserves the right to change the applicable license to the open source software including the contribution at any time in its own sole discretion. +2.3. Moral rights +2.3.1. The Contributor waives its and all its employees' or sub-providers' (and all other third parties who may claim authorship) rights to be named as an author of the contribution to the extent legally permissible. The Contributor shall obtain the written confirmation from its employees, sub-providers or other third parties who may claim authorship and disclose such confirmations without undue delay upon the Association's request. The Association will in its own discretion decide whether and in which way authors will be named or published. +2.4. Indemnity +2.4.1. The Contributor hereby guarantees and warrants that it is entitled to grant the rights to the contribution according to this License Grant document and that the contribution is free of any third party rights (including intellectual property rights). In the event that any contribution infringes any third party rights (including the rights of the Contributor, its employees or sub-providers or any third party rights), the Contributor shall indemnify and hold the Association and the Association's members harmless, including reasonable attorney fees. +2.5. Notice about claims raised +2.6. The Contributor shall inform the Association without undue delay about any legal claims raised by third parties as to the alleged infringement of such third party's rights by the contribution. The Contributor shall assist the Association to a reasonable extent in its defense against such third party claims. + + + + +2.7. Warranty +2.8. Subject to any express warranties or guarantees under this Grant of Rights, and unless required by applicable law or agreed to in writing, Contributor provides the contribution on an "as is" basis, without warranties of any kind. +3. Association's IP Policy +3.1. The Association has set in place an IP Policy (Annex ./1) and Requirements for the Quality of Contributions (Annex ./2), which shall be binding to the Contributor. Contributor guarantees and warrants that the Contribution complies with the IP Policy and the Requirements for the Quality of Contributions. +4. Acceptance of contributions +4.1. The Association may in its sole discretion decide whether to accept contributions by the Contributor and incorporate them in the official version or not. The Contributor has no right that any contribution is accepted. +5. Applicable law and Jurisdiction +5.1. Applicable law +5.1.1. This license grant document shall be governed by Austrian substantive law, under the exclusion of its conflict of law rules and the United Nations Convention on Contracts for the International Sale of Goods. +5.2. Jurisdiction +5.2.1. Any and all disputes arising between the Association and a Contributor, out of or in connection with this Grant of Rights including disputes relating to its validity, breach, termination or nullity shall be subject to the exclusive jurisdiction of the courts of 1010 Vienna, in case the Contributor has its seat in the European Economic Area. In case Contributor has its seat outside the European Economic Area, all disputes arising between the Association and a Contributor out of or in connection with this Agreement, including disputes relating to its validity, breach, termination or nullity shall be finally settled under the Rules of Arbitration of the International Arbitral Centre of the Austrian Federal Economic Chamber in Vienna (Vienna Rules) by three arbitrators appointed in accordance with the said Rules, one arbitrator nominated by the claimant, one arbitrator nominated by the respondent, and one arbitrator nominated by the two Party-nominated arbitrators. The place of arbitration shall be Vienna, Austria. The language of the arbitral proceedings shall be English. +6. Agreement +6.1. The Contributor guarantees and warrants, that it has all requisite power and authority to enter into this Grant of Rights. The Contributor particularly guarantees and warrants, that it has the full legal capacity necessary under the law applicable to the Contributor to enter into this Grant of Rights. If the Contributor is acting on behalf of a third person or entity, the Contributor confirms to be duly authorized by such person or entity to do so. The Contributor will indemnify and hold the Association harmless in this respect. + + + + +Contribution submitted: _________________________________ (please specify) + + +__________________________ + +date, place + + +__________________________ + +[Contributor] + + + +Annex ./1: IP Policy +Annex ./2: Requirements for the Quality of Contributions + + + +Annex ./1 – IP Policy + +The Association operates under the following IP Policy. To facilitate the project and to promote its objectives, all contributors shall fully comply with this IP Policy. +1. Contributions +1.1. Contributors may contribute to the project at their own discretion. The Association will in its own discretion review any such contributions, conduct due diligence checks and will then decide whether such contribution shall be used in the further course of the project. +1.2. All accepted contributions will be published under the Apache 2.0 license terms. The contributor explicitly acknowledges the rights grant involved by the publication and guarantees and warrants that the contribution is eligible to be published under the Apache 2.0 license. +2. Copyrights +2.1. Along with the contribution, a contributor shall provide the Association with the license grant document signed by authorized representatives of its organization. Without provision of such document, the Association will not accept nor review any submitted contributions. +2.2. Deviations from the license grant document require prior express written permission by the Association. Due to the open source nature of the project, deviations will generally not be accepted. +2.3. All publications shall bear the following copyright notice: + +"© Association for the promotion of open-source insurance software and for the establishment of open interface standards in the insurance industry, [year]. All rights reserved." +3. Other Intellectual Property Rights (Patents, Trademarks) +3.1. Other than granted under the license grant document, a contributor shall have no obligation to license any other intellectual property rights to the Association or other members of the Association. However, the contributor shall guarantee and warrant that the contribution does neither infringe its own rights nor rights of a third party and will hold the Association and all other members of the Association harmless in case of claims by such third parties. +3.2. The contributors shall inform the Association without undue delay about any legal claims raised by third parties as to alleged intellectual property violations due to usage of the software and about any intellectual property initiatives they are pursuing that could be relevant for the project and the project goals. +3.3. The Association may register trademarks for use in the project. If it does so, it will publish guidelines regarding rules and limitations under which contributors will be allowed to use such trademarks. + + + + +Annex ./2 – Requirements for the Quality of Contributions + + +[see our Contribution Guideleines and the Coding Manifest] + diff --git a/README.md b/README.md index 82d1587..3731036 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,7 @@ +![GitHub top language](https://img.shields.io/github/languages/top/aposin/MergeProcessor.svg) +[![CLA assistant](https://cla-assistant.io/readme/badge/aposin/MergeProcessor)](https://cla-assistant.io/aposin/MergeProcessor) +[![GitHub](https://img.shields.io/github/license/aposin/MergeProcessor.svg)](https://github.com/aposin/MergeProcessor/blob/master/LICENSE) + # MergeProcessor Documentation ## Introduction