Eiffel Event Repository
Eiffel Event Repository is a persistent storage solution for Eiffel events.
This repository contains a software implementation based on the Eiffel protocol. For more information on Eiffel, its vocabulary, descriptions, guides and schemas, please see the Eiffel repository. For news, discussions and questions, please visit the Eiffel Community Google group.
Eiffel Event Repository is licensed under the Apache License 2.0.
How to Run
For the dummy event repository to work, you have to extract src\main\resources\static\reference-data-set.zip into src\main\resources\static\reference-data-set.json
To run the app you need Java 8 and Maven installed.
Navigate to the repository root and execute one of the following commands in the terminal.
mvn spring-boot:run
or
(mvn clean package) -and (java -jar target\dummy-er-0.0.1-SNAPSHOT.jar)
The app should now be running at http://127.0.0.1:8081/ and the events should now be accessible through http://127.0.0.1:8081/reference-data-set.json
How to docker (run together with Vici)
First make sure you have created the docker image for Vici https://github.com/Ericsson/eiffel-vici
- Dockerfiles is found in the folder src\main\docker\
- Docker image is created with the fabric8io/docker-maven-plugin with settings found in pom.xml.
1: Make sure you have unzipped the reference-data-set.json file, instructions found in the "How to Run" section.
2: Build docker image:
Navigate to the repo root and use the following command: (requires 'mvn clean package')
mvn docker:build
The docker image should now appear in the list generated by:
docker images
3: Make sure that no image/container of eiffel-vici or eiffel-event-repository is running. Navigate to src/main/docker from the root directory. And enter the following command:
docker-compose up -d
You can now access the Vici app at http://127.0.0.1:8080/ (if you are running docker-machine check IP with : docker-machine ip)
To shut down the docker composition:
docker-compose down
API
http://[url|ip]/{filterName}/{metaId}
{filterName} is the name of the specific eiffel event repository at the url/ip. {metaId] is optional and is if you want to fetch one specific event given the ID. Takes a \app\src\main\java\er\api\entities\query\Query.java in json format as request body (POST).
How to Propose Changes
Anyone is welcome to propose changes to this repository by creating a new Issue ticket in GitHub. These requests may concern anything contained in the repo: changes to documentation, changes to interfaces, changes to implementations, additional tests et cetera.
When posting a new issue, try to be as precise as possible and phrase your arguments for your request carefully. Keep in mind that collaborative software develpoment is often an exercise in finding workable compromises between multiple and often conflicting needs. In particular, pay attention to the following:
- What type of change is requested?
- Why would you like to see this change?
- Can you provide any concrete examples?
- Which arguments in favor can you think of?
- Which arguments against can you think of, and why are they outweighed by the arguments in favor?
Also, keep in mind that just as anyone is welcome to propose a change, anyone is welcome to disagree with and criticize that proposal.
How to Contribute
Contributions can be made by anyone using the standard GitHub Fork and Pull model. When making a pull request, keep a few things in mind.
- Always explicitly connect a pull request to an Issue. See How to Propose Changes above for further information.
- Make sure you target the correct branch. If you are unsure which branch is appropriate, ask in the Issue thread.
- Pull Requests will be publicly reviewed, criticized, and potentially rejected. Don't take it personally.
Reviewing and Merging Pull Requests
We use the Squash and Merge model, which means that all commits in a Pull Request get squashed into a single commit in the target branch. In other words, the revision history will look like a string of single commits corresponding one-to-one with Issues.
Pull requests can be merged by members of the Eiffel team. There is a certain protocol to adhere to, however, as well as expectations on membership.
- All members of the Eiffel team are expected to make the effort to participate in the review of Pull Requests. Every member may not review everything in detail, but everyone can make the effort to chime in on some. Remember that expedient high quality reviews are crucial to the long term survival of any open source project.
- Eiffel team members are strongly encouraged to participate in reviews even if they do not feel entirely qualified to assess the pull request. Looking at changes and participating in review discussions is one of the best ways to learn, and presents an excellent opportunity to ask questions. And remember, participating in a review is not the same as having to make the final decision.
- Anyone can participate in reviews, not only Eiffel team members.
- A Pull Request should be approved by at least two Eiffel team members (including the one doing the merging). For this to function well, the above point on participation is critical.
- Do not feel any pressure to merge Pull Requests. Unless you feel confident about what you are doing, don't press that big green button. Instead, ask a more senior member to make the decision.
- When squashing and merging, ensure that the description reflects the change. Detailing every individual commit in the Pull Request is unnecessary, as they are squashed anyway. Instead, describe the change as a single thing. That description should always include an Issue reference, and should focus on WHY the change was made, to provide the reader with context. See this excellent guide on writing good commit messages.
License Management
To be accepted into the repository, contributions must be licensed under the Apache License 2.0. Consequently, a license notice shall be included in suitable comment syntax where applicable. This license notice shall state the copyright holder(s) and point to the commit history for a full list of individual contributors, on the following format:
Copyright <Year(s)> <Copyright holder of original contribution [and others].>
For a full list of individual contributors, please see the commit history.
The copyright holder is either the individual contributor if they act on their own behalf, or any organization on whose behalf they contribute. When multiple copyright holders have contributed to the same file, the copyright notice shall be appended "and others". The copyright year(s) shall reflect the year(s) of contribution(s) and be updated accordingly when new contributions are made to the file. To exemplify, the copyright notice of an original contribution made by Jane Doe acting on behalf of Ericsson AB may read:
Copyright 2017 Ericsson AB.
For a full list of individual contributors, please see the commit history.
When John Doe, acting on his own behalf, makes a subsequent addition to the same file, the notice will be updated accordingly:
Copyright 2017 Ericsson AB and others.
For a full list of individual contributors, please see the commit history.
When John Doe makes a subsequent contribution the following year, the notice will again be updated:
Copyright 2017-2018 Ericsson AB and others.
For a full list of individual contributors, please see the commit history.