Onyx (code)

Wiki page for comments regarding the code for OBiBa Onyx.

It seems to me (JeffLusted) that there are a bunch of associated issues arising with developing and maintaining the Onyx questionnaire. I would think overall we need to mould one sensible solution which encompasses these. There are some surprising complexities here. We probably need to try and evolve a solution which covers live/test, developing one or more questionnaires (even the basics of a build are tedious), and the ability to version the BRICCS questionnaires separately from the Obiba onyx code base.

Distinguishing Between a Live and a Test system at the User Interface Level

Addition - 9 December 2010 (NickHolden): We realised today that we wanted to clearly differentiate between the live and test systems. The easiest way seems to be to use a different logo. I have uploaded new logos on the test system - and also on the live system because it was using the old 'NIHR' logo, not the new approved logo.

In /usr/local/briccs-webapps/briccs-onyx-1.9.2/images/logo there are two files:

nick@uhlbriccsdev:/usr/local/briccs-webapps/briccs-onyx-1.9.2/images/logo$ ls -al
total 64
drwxrwxr-x 2 tomcat6 tomcat6  4096 2010-12-09 15:27 .
drwxrwxr-x 6 tomcat6 tomcat6  4096 2010-11-11 13:09 ..
-rw-r--r-- 1 root    root     7609 2010-12-09 15:24 logo_on_dark.png
-rw-r--r-- 1 root    root    14624 2010-12-09 15:24 logo_on_light.png
-rw-rw-r-- 1 tomcat6 tomcat6 10255 2010-11-11 13:05 old_logo_on_dark.png
-rw-rw-r-- 1 tomcat6 tomcat6 19115 2010-11-11 13:05 old_logo_on_light.png

I've saved the old logos as shown, so now there are four files (see attachments at bottom of page)

Note that these changes affect the current version of briccs-onyx, and would need to be replicated after each upgrade. At the time of writing I cannot find the mechanism for giving the onyx package an image file to build the logo_on_dark.png and logo_on_light.png automatically. THIS NEEDS TO BE ADDRESSED BEFORE THE NEXT UPGRADE.

---

Comments

Looks to me as if this could be addressed in one of two ways:

• By having two maven profiles, one for production and one for test.
• By having two deployment options in a deployment script.

It maybe the best approach is to have both! That is, we build two artifacts each with their respective logos, and decide at system deployment whether the system requires the production artifact or the test artifact.

-- JeffLusted

Naming and Versioning Onyx Questionnaires

The OBIBA maven build uses overlays upon the onyx-webapp war. This is fine up to a point, but it is difficult to see how to set a BRICCS-specific version number for the artifact without interfering with the dependencies in the maven build. That is: it screws the build. The easy way is to use a finalName parameter within the POM, which sets the artifact to, let us say, 1.9.2. But this final name is NOT automatically carried over into any maven repo, and there lies the problem.

Solution. There is probably a better solution, but the SVN projects now contain two scripts which will help deploy an artifact to a remote maven repository with the correct BRICCS's version number. See the README within a project for further details. So, for instance, we can now have a questionnaire with a BRICCS version number of 1.9.2 whilst the Onyx code is at version 1.7.0. The version numbering is now independent, and the real dependencies are handled within the POM.

Naming. At the moment we have one generic Onyx questionnaire. The project within SVN is called onyx-questionnaire and it generates an artifact called briccs-onyx-n.n.n.war, where n.n.n is the version number. This is less than informative. Presumably there will be further questionnaires. We need a naming convention which is descriptive of the questionnaire. And each project requires an adequate description within the maven POM.