QA: Dependencies for Voucher Label Report

[mikejritter]

What does this do?
Adds batik-all and barcode4j as dependencies to the reports/service module

Why are we doing this? (with JIRA link)
No Jira. This is a QA issue which was raised during testing of the UCB Voucher Label report.

These dependencies bring in a similar set to those found under services/report/3rdparty/jasper-cs-report/src/main/resources/tenants/ucbg/nuxeo-server-lib, e.g.

[services (qa/ucb-voucher-label)] $ ls -l services/report/3rdparty/jasper-cs-report/src/main/resources/tenants/ucbg/nuxeo-server-lib
total 5560
-rw-r--r-- 1 shake shake  274404 Sep  1 12:39 barcode4j-2.1.jar
-rw-r--r-- 1 shake shake  282237 Sep  1 12:39 barcode4j-fop-ext-0.20.5-complete.jar
-rw-r--r-- 1 shake shake   15864 Sep  1 12:39 barcode4j-fop-ext-0.20.5.jar
-rw-r--r-- 1 shake shake  298488 Sep  1 12:39 barcode4j-fop-ext-complete.jar
-rw-r--r-- 1 shake shake   32115 Sep  1 12:39 barcode4j-fop-ext.jar
-rw-r--r-- 1 shake shake  274404 Sep  1 12:39 barcode4j.jar
-rw-r--r-- 1 shake shake  230538 Sep  1 12:39 barcode4j-light.jar
-rw-r--r-- 1 shake shake   22109 Sep  1 12:39 barcode4j-xgc.jar
-rw-r--r-- 1 shake shake 4254931 Sep  1 12:39 batik-all-1.9.1.jar

[services (qa/ucb-voucher-label)] mvn dependency:tree | grep -E 'batik|barcode'
[INFO] +- org.apache.xmlgraphics:batik-all:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-anim:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-awt-util:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-bridge:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-codec:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-constants:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-css:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-dom:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-ext:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-extension:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-gui-util:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-gvt:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-i18n:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-parser:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-rasterizer-ext:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-rasterizer:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-script:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-slideshow:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-squiggle-ext:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-squiggle:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-svg-dom:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-svgbrowser:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-svggen:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-svgpp:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-svgrasterizer:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-swing:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-transcoder:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-util:jar:1.9.1:compile
[INFO] |  +- org.apache.xmlgraphics:batik-ttf2svg:jar:1.9.1:compile
[INFO] |  \- org.apache.xmlgraphics:batik-xml:jar:1.9.1:compile
[INFO] +- net.sf.barcode4j:barcode4j:jar:2.1:compile

It's likely we could omit a number of the transitive dependencies, but I've made no attempt to do so.

How should this be tested? Do these changes have associated tests?
Before rebuilding CollectionSpace, make sure that your ucbg nuxeo database has the following types and functions:

botgarden_domain_default=# \dT voucherlabeltype 
           List of data types
 Schema |       Name       | Description 
--------+------------------+-------------
 public | voucherlabeltype | 
(1 row)

botgarden_domain_default=# \df findvoucherlabels 
                                List of functions
 Schema |       Name        |    Result data type    | Argument data types | Type 
--------+-------------------+------------------------+---------------------+------
 public | findvoucherlabels | SETOF voucherlabeltype |                     | func
(1 row)

If you're missing either of these, the voucher label type can be added with the following DDL:

create type voucherlabeltype as
(objectnumber varchar,
determinationformatted varchar,
family varchar,
collectioninfo varchar,
vouchernumber varchar,
numbersheets integer,
labelrequested varchar,
gardeninfo varchar,
vouchertype varchar,
fieldcollectionnote varchar,
annotation varchar,
vouchercollectioninfo varchar
);

The findvoucherlabels function exists in services/common/src/main/resources/db/postgresql/tenants/ucbg/fnc-public-findvoucherlabels-nuxeo_botgarden.sql and can be loaded with

psql -U postgres -h localhost -W botgarden_domain_default < services/common/src/main/resources/db/postgresql/tenants/ucbg/fnc-public-findvoucherlabels-nuxeo_botgarden.sql

In addition, the voucher label report must exist in your collection space. If it does not exist, it can be added by issuing a POST to cspace-services/reports using the XML found in services/report/3rdparty/jasper-cs-report/src/main/resources/tenants/ucbg/payloads/ucbgVoucherLabel.xml.

Once these exist, you can test by doing the following:

• Rebuild CollectionSpace with this PR
• Log in to the UCB BotGarden instance
• Create a new Object
  • I added values to the Accession number, Taxonomic determination -> Scientific name, and field collection information fields.
  • For the new object, create a new voucher
    • In the voucher, Label requested must be yes, and Number of sheets must be greater than 0. I also filled out the collector, horticulture/wild, voucher date, voucher collection number, and garden location fields.
• With the object and voucher filled out, navigate to Tools > Reports, and run the Voucher Label report.
• Upon completion of the report, barcodes should be visible.

Dependencies for merging? Releasing to production?
None

Has the application documentation been updated for these changes?
I might update the comment in the pom.xml so that it explains why the dependencies are being brought in.

Did someone actually run this code to verify it works?
@mikejritter tested locally