Skip to content
This repository has been archived by the owner on Jan 9, 2023. It is now read-only.

Building the MyEquivalents Software

Anonymous edited this page Sep 10, 2015 · 16 revisions

As explained elsewhere, the myEquivalents software is based on Java and Maven. You can build it from scratch as described in this page. Note that we assume familiarity with Unix command line interface. Maven and Java knowledge are useful too.

  • Clone the [myequivalents github repository] (/EBIBioSamples/myequivalents)
  • cd to the root level and issue 'mvn install'. Add the -P option to set up a suitable back-end profile (see below).

After this, the command line package should be available as a .zip file into myequivalents/target, the programmatic interface, the relational database back end and the web service client should be available as a .jar files in myequivalents-core/target, myequivalents-core/target and myequivalents-wscli/target respectively, the web service will be available as a .war file in myequivalents-web/target. You need to include one or more such files in your Java classpath, depending on how you want to configure your myEquivalents installation.

##Database Profiles By default, myEquivalents is shipped with a relational database as backing storage system. Such database can be configured by either changing files in the installed packages, or by pre-configuring such files during the package build. The latter is based on Maven profiles. There are two types of profiles defined (and definable) in the root POM that affect the building process.

Profiles named test.* are database configurations used for JUnit tests (or other types of tests). Usually these configurations are not included on the main build of a module, which generates the binary distribution file (e.g., a .jar or a .war).

Profiles named differently than that may affect a main build. For example, if you issue: mvn -Ptest.hsql,oracle_test test all the JUnit tests will be run against a volatile in-memory database, while modules like the command line will be shipped with a default configuration file that points at the EBI test database.

As you can see in such XML, profiles affect Spring Bean configuration files, since myEquivalents configuration are based on such a file.

##Setting up the database back end myEquivalents requires that a fresh backend is initialised with some information, namely an initial administrator user and an 'unspecified' fictitious service, which is used to manage generic URIs. If you have a relational database backend, this can be done from the command line package, by means of the init.sh script. This will populate the backend with the user 'admin', having password 'admin.password' and API secret 'admin.secret'. Probably you have already figured it out that, in order to guarantee satisfactory security levels, these passwords do need to be changed after the initial setup. Use the command line (myeq.sh) to do that.

In examples/ you also find a create_examples.sh script, which populates the backend with a couple of sample services and mappings. This script uses the default credentials set up by the init.sh script, i.e., you should apply the mentioned password changes after having run this script too.