qerts/pa165-java

pa165-java's Issues

Set up Travis-CI

Set up Travis-CI, so it "runs mvn package" on any pull request made to branch "dev" (ideally, with merge still allowed when build fails) and to branch "master" (ideally, mege should not be possible until build passes).

Journey - contraints

Single journeys with same vehicle should not cover.

User Interface

• To start the web application you have to configure maven plugin (tomcat7 or jetty). It is very important that it’s super easy to start the web application from command line. So for example using tomcat7 plugin, the following sequence of commands should start the web application: “mvn clean install && cd web && mvn tomcat7:run”
• The web application must be available on the following HTTP context http://localhost:8080/pa165
• Your application should use in-memory database. This means that after application restart (killing web container and starting it again with mvn tomcat7:run) the data may be reset.
• Implement the user interface using Spring MVC or Angular JS.
• The user interface should allow to carry out all business functions of your system.
• You should fill in all the necessary data automatically. So for example you can use Web Listener to load data during Web Application startup.
• Make sure there are validations implemented on user interface.
• Your user interface should use either Facade layer or REST layer to access the system. Do not directly access database and do not directly use Service layer.
• The web interface layer may reside in separate maven module (if this is helpful).
• Each member of the team must implement (mostly independently, without copy-pasting) part of user interface. Including controller and view.

Service - getTotalKilometrage

Create method getTotalKilometrage(double vehicleId):double. This method will sum init state of tachometer and all rides for given vehicle. Return value is total kilometers.

Tasks after seminar on 18th of October

• Everyone - create at least one EntityDao.
• Everyone - create at least one test for EntityDao, which is not his own

---

• @JozeFe - Design general Dao and create one Entity and Entity's Dao. Entity: Employee
• @msmidik - Look on a way to design repository for some existing Entity, e.g. http://docs.spring.io/spring-data/data-commons/docs/1.6.1.RELEASE/reference/html/repositories.html Entity: Vehicle + VehicleCategory
• @trebi - Set up test framework, create one Entity and Tests for it using in-memory database. Entity: Journey, DaoTest: Employee
• @Qerts - Entity: InspectionInterval + Inspection

Switch to GitHub flow from the Git flow

On the last meeting, we have agreed to use some kind of Git flow instead of GitHub flow, i.e. use dev branch as the main branch and master branch for the stable releases. I have told you, that I don't care whether the branch on which are we working on is actually called master or dev, but I changed my mind.

1. GitHub interface is suited for GitHub flow rather than GitFlow. Perfect example is that if you open the project, you are by default on master branch rather than dev branch, which is for us as developers much more interesting. Another issue is that if we stick to the Git Flow, we will see Compare & Pull Request on the dev branch.
   

2. I believe that Git flow is more for the bigger teams with separate roles, as Developers, QAs, testers and so on.

I suggest to switch to the proper GitHub flow, i.e. use master as most up-to-date branch, pull requests for merging code into master and tags for stable releases.

Read more about diffence between Gitflow and GitHub flow for instance here: https://lucamezzalira.com/2014/03/10/git-flow-vs-github-flow/

Move diagrams used in Wiki to external Gist

Now, they are part of the source code, more specifically dev branch. Should be the diagrams part of this repository, or we should create a separate one (aka Gist)? What do you think?

Proper exceptions in DAO layer

Make sure that DataAccessException or its subclass is thrown in case of any exception on a the DAO layer.

• Employee
• Inspection
• InspectionInterval
• Journey
• Vehicle
• VehicleCategory

Service - getAllJourneys

Create method getAllJourneys(Date from, Date to, double employeeId):List(). This method will search for all journeys within given time span and with given employee ID.

Milestone 1 requirements

• create a project in a Github repository that is publicly accessible (for read) choose a short and descriptive name. Create some project wiki to publish other information for your project.
• on the project wiki there will be a project description, a use case diagram and a class diagram for entity classes. There will be at least two user roles in the use case diagram. Associations between entities will be present in the class diagram.
• create 4 entity classes for your project.
• create a DAO layer interface (with proper javadoc).
• create the JPA implementation of the DAO classes (CRUD operations are enough for the first checkpoint).
• create unit tests for DAO classes (use in-memory database).
• every team member should work with different entities on different parts of the project (e.g. member 1 will create implementation of DAO for entity A, but member 2 will create unit test for entity A). In every class there will be javadoc @author with the name of the class author. Also you must commit into Git only the changes that you made yourself. If you commit on behalf of somebody else this will not be regarded as his work!
• the project will be built using maven, and make sure you have all dependencies correctly configured, so it is possible to build it using just the command line.

Services for entities

create all services for DAO classes

some bugs and todo

• (TODO) implement create, update, delete/disable operations from web
• (TODO) Serviceman -> Add InspectionInterval (#404)
• (BUG) Serviceman -> vehicle detail (#500 Null pointer exception) => (maybe?) Inspection intervals for individual vehicle do not display in vehicle detail (under serviceman menu)
• (BUG) available vehicles not shown for logged user but for user id 1 (hardcoded in line 44 template.tag)

Make the repoitory public or move it elsewhere

Lecturers / tutors require us to have a repository easily accessible by all member of the course, because we will be doing peer reviews (see notes to Milestione 1). We could either make this repository public (I have nothing against it) or move it to the school server http://gitlab.fi.muni.cz

Unit Tests for Facade Layer

We should implement simple unit tests for Facade layer. One simple test per method. Just to prove the facade works.

Submit evaluations of other teams

Evaluation Checklist:

• You can assign maximum 10 points to the project you are reviewing.
• -3 points if it is not possible to compile the project using “mvn clean install”. You must either make this work or ask the team to fix this ASAP because it’s hard to check the code without this.
• -1 point for each minor occurrence of a team member not contributing enough.
• -1 points for incorrectly implementing equals/hash code.
• -1 points for every minor occurrence of missing methods/tests (e.g. missing important method on a DAO object or a missing test for that method).
• If a team member was not contributing at all, or very little, you should explicitly say this in your evaluation report. Tutor will follow up on this information.

Each member evaluates a project of another team. To find out which project do you evaluate, check:
https://docs.google.com/spreadsheets/d/193LHasHryuDqN60cBUvBN8iH74GZgc7AQRreKV7FJKo/edit?usp=sharing

Unit Tests for Service Layer

It is vital to have extensive unit test coverage for service layer. All the test should contain mocked DAO objects!

• getTotalKilometers method
• getAllJourneys method
• others

Implement Facades

TASK: Select an Actor and the use case from the Use Case Diagram and implement it using Facade. You will also need to implement appropriate service(s) and extends DAOs (and eventually also entities) accordingly.

Assigned work:

• - Employee facade - @JozeFe - PR #39
• - Journey facade - @msmidik - PR #40
• - Vehicle facade - @Qerts - PR #41
• - Inspection facade - @trebi - PR #42

DEADLINE: Thursday evening.

Before you start working, please write here to the comments, or to the Slack, which facade and which use cases will you implement. Remember, we need to implement at least two non-trivial use cases, fully cover our services with unit tests (mocking DAOs), be aware of exceptions: services should work only with DataAccessExceptions; and finally implement some really simple (unit? integration?) test for facade.

Here is the drawing with my proposal of possible facades and their methods:

Inspired from our Use Case Diagram:

REST layer

• Your application should have a basic REST interface.
• At least one entity and operations on that entity must be exposed.
• This is mainly to demonstrate you can implement this, it’s not necessary to have all application functions accessible through this interface.
• The REST must be accessible at http://localhost:8080/pa165/rest
• it is not required to have the interface secured.
• You should include a README file with instructions how to test the REST interface (e.g. CURL commands for command line).

Security

• There should be at least 2 roles in the system (e.g. Administrator, User). Each role should have some differences in user interface or in capabilities.
• There should be login form (not HTTP Basic)
• Registration is NOT required. You can prefill the users and their passwords in the database.
• Password should not be saved in the database in open form.

Make project multimodule

Change layout of your project to Multimodule Maven project (tutorial here http://maven.apache.org/guides/getting-started/index.html) Your project should have 3 separate modules:

• DAO layer
• Service Layer and Facade Layer implementation
• API layer - just DTOs and facade interfaces!

Facade Implementation Rules

• Everything that should happen in the system must be available through these interfaces (create entities, deleting them etc);
• Other points about the Facade and Service layers:
• All the classes must be wired via dependency injection. Your service objects should obtain an instance of the EntityManager that way;
• All the facade interfaces must not reference entities, but Transfer Objects only;
• All service interfaces must reference only entities, not Data Transfer Objects;
• You can use Dozer framework to map entity instances to transfer objects. The mapping may be done on Facade Layer;
• Facade layer is used to drive transactions;
• Facade layer will use Service layer and Service layer will use DAO layer;