-
Notifications
You must be signed in to change notification settings - Fork 0
Dependencies
The code-base uses a number of third-party libraries. This wiki page lists the major dependencies along with a discussion of where they are used. The list of dependencies is broken into two categories: hard dependencies and soft dependencies.
Hard dependencies are libraries to which the code-base is tightly coupled. They can not be easily replaced.
SLF4J is used throughout the code base to provide logging functionality.
FindBugs provides a set of JSR305 annotations which are used throughout the code base to mark class and method fields and method return values which may be null. Further more FindBugs is used during the build process (via a maven module) to perform additional static code analysis.
As of this writing, FindBugs is reporting a number of issues that can be safely ignored. The issues that it is reporting are in classes which are generated by Dagger.
Dagger is used to handle dependency injections in cases where the dependencies are not fixed or trivial. Currently, it is used to create instances of all of the Builders for the Element classes, as well as the DomainModel and DataStore classes. While the Dagger components are available to the programs which use the DomainModel, the creation of instances of the aforementioned classes is handled internally.
AutoFactory is used with Dagger to create instances of the DomainModel and DataStore classes.
AutoService is used by all of the Element implementation classes to instruct the Profile class to load the definition for the element implementation when the program initializes. Loading the definition, causes the Element classes to be registered and initialized.
AutoValue is used by the MemDataStore and the SubActivityConverter classes to generate composite Map key classes.
The Guava Preconditions and MoreObjects classes are used throughout the code base to provide error checking and string representation of objects respectively.
Apache Commons CSV is used by the Extractor class to read registration data from the provided CSV files. The registration data is used while processing records from the Moodle database.
Soft dependencies are the libraries to which the code is loosely coupled. In most cases access the library is accessed though a standard interface. These libraries can be replaced with a small amount of effort.
Postgresql is used for both the source and destination databases. The databases are accessed through the Java Persistence API. It is possible to use a different RDBMS for either or both of source and destination databases, by updating the JPA configuration. The process for changing the RDBMS for the source and destination databases is discussed below.
Any database supported by Moodle can be used as the input database, as long as it has a JDBC driver. To use a database other than PostgreSQL for the source data the following things must be done:
- Provide a JDBC driver for the new database
- Update the URL in the input profile to use the new JDBC driver
- Update persistence.xml
The schema of the destination database was designed against Postgresql and uses PostgreSQL's bigserial data type (an auto-incrementing integer) for the id field of most of the tables. PostgeSQL can be replaced with another database if that database supports foreign key constraints and a method of automatically assigning id numbers which in turn is supported by the JPA implementation. If both of these constrains can be met then the following steps need to be taken to replace PostgreSQL with the new database:
- Provide a JDBC driver for the new database
- Update the URL in the input profile to use the new JDBC driver
- Update persistence.xml
- Port the schema to the new database
- Update the id entries in the mapping files to reflect any changes to the schema
Hibernate is the Java Persistence API implementation used for accessing the databases. The code-base and mappings are written to the JPA version 2.1 specification and do not use any non-JPA features. So any JPA implementation which supports JPA 2.1 should be able to be substituted for Hibernate. However, each JPA implementation has its idiosyncrasies and interpretations of the JPA specification regarding persistence.xml and the XML mapping files. Swapping out Hibernate for a different JPA implementation will probably require some changes to persistence.xml and the mapping files.
When it opens the destination (course) database, Hibernate issues a warning about as field being present in the mapping file, but not in the class. This warning can be ignored. Hibernate looks for public accessor methods for all of the fields that are listed in the mapping file, and issues a warning if it does not find them. For the fields that Hibernate lists the accessors are protected as the fields in question are internal parts of the element, and should not be returned to a user. Furthermore, Hibernate Hibernate (and any other JPA implementation) is configured to access the class by field, so it does not need the method that it is complaining about.
The Java Persistence API specifies that entity classes may be accessed either by field or by property. When accessing by field the JPA implementation will directly read and write to the specified class member variables. For property access the JPA implementation will use the accessor and mutator methods for the entity class. In theory, both methods should be equal, however the JPA implementations seem to prefer access by field. When attempting to use access by property Hibernate runs into trouble with any form of defensive copying on collections. EclipseLink (the JPA reference implementation), handles defensive copies properly, but has other problems.
Log4J is the logging back-end used for writing log files. If necessary, it can be replaced with any logging back-end supported by SLF4J. However, a new configuration file will need to be written for the new back-end.