Description

<dependency>
    <groupId>com.novartis.opensource</groupId>
    <artifactId>YADA-Quickstart</artifactId>
    <version>8.3.0</version>
</dependency>

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <!-- Use any name that is meaningful in your environment -->
  <groupId>com.novartis.opensource</groupId>

  <!-- Use any name that is meaningful in your environment -->
  <artifactId>YADA-Quickstart</artifactId>

  <!-- You could keep the version number consistent with the version of YADA 
    you are using, or whatever you want. Currently the yada-api and yada-war 
    dependencies' versions are configured to equal ${project.version}, so if 
    the actual ${project.version} value is changed below, the dependency configs 
    will need to be adjusted accordingly. -->
  <version>8.3.0</version>

  <packaging>war</packaging>
  
  <url>http://github.com/Novartis/YADA</url>
  
  <licenses>
    <license>
      <name>Apache License, Version 2.0</name>
      <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>
    </license>
  </licenses>
  
  <organization>
   <name>Novartis Institutes for BioMedical Research, Inc</name>
   <url>http://opensource.nibr.com</url>
  </organization>
  
  <distributionManagement>
    <site>
      <id>yada.site</id>
      <name>YADA site</name>
      <url>${distribution.site.url}</url>
    </site>
    <snapshotRepository>
      <id>ossrh</id>
      <url>https://oss.sonatype.org/content/repositories/snapshots</url>
    </snapshotRepository>
    <repository>
      <id>ossrh</id>
      <url>https://oss.sonatype.org/service/local/staging/deploy/maven2/</url>
    </repository>
  </distributionManagement>
  
  <developers>
   <developer>
     <name>David Varon</name>
     <email>varontron@gmail.com</email>
     <organization>Novartis Institutes for BioMedical Research</organization>
     <organizationUrl>http://opensource.nibr.com</organizationUrl>
   </developer>
  </developers>
  
  <scm>
    <connection>scm:git:ssh:git@github.com:Novartis/YADA-Quickstart.git</connection>
    <developerConnection>scm:git:ssh://git@github.com/Novartis/YADA-Quickstart.git</developerConnection>
    <url>scm:git:ssh://github.com/Novartis/YADA-Quickstart</url>
  </scm>
  
  <!-- Year of current version -->
  <inceptionYear>2016</inceptionYear>
  
  <!-- Use any name that is meaningful in your environment -->
  <name>YADA-Quickstart</name>

  <!-- Set properties that are salient to your build process. This is your 
    project and the properties can reflect any build scenarios that you require. 
    The defaults below are explained in the comments -->
  <properties>
    <!-- 'display.version -->
    <!-- Adds version stamp to yada-admin UI and to JNDI context for inclusion 
      in default Response structures -->
    <display.version>${project.version}</display.version>

    <!-- 'project.build.sourceEncoding' -->
    <!-- Required to make the build platform independent. Maven will warn 
      you about this at the end of the build if it is omitted -->
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

    <!-- 'skip.war.deploy' -->
    <!-- Referenced by the 'war-deploy' profile and in turn by the exec plugin. 
      When 'true', the exec plugin will not execute. (true == skip) When 'false', 
      the exec plugin will execute. The exec plugin is used to deploy the YADA 
      war file to remote servers. Execution is skipped by default, as local testing 
      deployments use the cargo plugin, and so you don't get confused as you're 
      just starting out. The cargo plugin could theoretically be used for this 
      too, but it can be difficult to configure for remote access (what with settings.xml 
      changes and environment-specific properties, etc.) It works very well for 
      local deployments, in particular for testing, and that is how it is used 
      here. -->
    <skip.war.deploy>true</skip.war.deploy>

    <!-- 'skip.cargo.deploy' -->
    <!-- Lo, here it is. The cargo plugin is used for local testing. It is 
      skipped by default, so it doesn't confuse you as you're familiarizing yourself 
      with the YADA environment. -->
    <skip.cargo.deploy>true</skip.cargo.deploy>

    <!-- 'skip.auth.test' -->
    <!-- Auth testing presumes you have a different host or uri for YADA 
      if it's behind an authentication gateway. The maven failsafe plugin is used 
      for testing. -->
    <skip.auth.test>false</skip.auth.test>

    <!-- 'skip.noauth.test' -->
    <!-- Noauth testing presumes you have a different host or uri for YADA 
      if it's behind an authentication gateway. The maven failsafe plugin is used 
      for testing. -->
    <skip.noauth.test>false</skip.noauth.test>
  </properties>

  <description>Custom implementation of YADA</description>

  <!-- These profiles are set up to build your warfile for different environments, 
    assuming you don't use a continuous-integration (CI) tool like Jenkins. Obviously, 
    if you use a CI tool, you probably won't use maven to build locally, let 
    alone deploy or test. In that case these settins, and environment-specific 
    properties and scripts may serve as guidelines for CI configuration. -->

  <profiles>
    <!-- INSTALLER PROFILE -->
    <!-- 'izpack' -->
    <!-- builds the installer -->
    <profile>
      <id>izpack</id>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
      <properties>
        <env>izpack</env>
        <!-- change to 'false' to enable cargo deployment -->
        <skip.cargo.deploy>true</skip.cargo.deploy>
        <skip.auth.test>true</skip.auth.test>
      </properties>
      <build>
        <resources>
          <resource>
		        <directory>${basedir}/src/main/resources/izpack</directory>
		        <targetPath>${project.build.directory}/izpack</targetPath>
		        <filtering>true</filtering>
		        <excludes>
		          <exclude>*.zip</exclude>
		          <exclude>*.png</exclude>
		          <exclude>**/*.jar</exclude>
		        </excludes>
		      </resource>
		      <resource>
            <directory>${basedir}/src/main/resources/izpack</directory>
            <targetPath>${project.build.directory}/izpack/scripts</targetPath>
            <filtering>true</filtering>
            <includes>
              <include>launch.*</include>
            </includes>
          </resource>
        </resources>
	      <plugins>
		      <plugin>
		        <groupId>org.codehaus.mojo</groupId>
		        <artifactId>exec-maven-plugin</artifactId>
		        <configuration>
		          <version>1.3.2</version>
		          <executable>/bin/bash</executable>
		          <arguments>
		            <argument>/Applications/IzPack/bin/compile</argument>
		            <argument>${project.build.directory}/izpack/install.xml</argument>
		            <argument>-o ${project.build.directory}/${project.artifactId}-${display.version}.jar</argument>
		          </arguments>
		        </configuration>
		        <executions>
		          <execution>
		            <id>build-installer</id>
		            <phase>install</phase>
		            <goals>
		              <goal>exec</goal>
		            </goals>
		          </execution>
		        </executions>
		      </plugin> 
	      </plugins>
	    </build>
    </profile>
    <!-- DEPLOYMENT PROFILES -->
    <!--   The remaining profiles are intended to be used after customizing the quickstart
           for an internal deployment -->
    <!-- 'local' -->
    <!-- The 'local' profile is active by default. -->
    <!-- Remember that passing any other profile name to maven will override 
      activeByDefault settings, so you will need to include the 'local' profile 
      name if you want to also use 'war-deploy' -->
    <!-- The 'local' profile sets the ${env} property to 'local', which ultimately 
      is translated into the path '/resources/conf/local' in order to use the environment-specific 
      'build.properties' file. 'local' can also turn on 'cargo-deploy' (off by default) and turns off 
      auth testing, assuming that you want to deploy to a local tomcat instance, 
      and that it won't be behind your authentication gateway, so you'll just do 
      noauth, if any, testing. -->
    <profile>
      <id>local</id>
      <properties>
        <env>local</env>
        <!-- change to 'false' to enable cargo deployment -->
        <skip.cargo.deploy>true</skip.cargo.deploy>
        <skip.auth.test>true</skip.auth.test>
      </properties>
    </profile>

    <!-- 'dev' -->
    <!-- The 'dev' profile sets the ${env} property to 'dev', which ultimately 
      is translated into the path '/resources/conf/dev' in order to use the environment-specific 
      'build.properties' file and 'deploy.sh' script. 'dev' does not automatically 
      deploy, in case you want to just run tests without wasting time deploying 
      the same version of the war file -->
    <profile>
      <id>dev</id>
      <properties>
        <env>dev</env>
      </properties>
    </profile>

    <!-- 'test' -->
    <!-- The 'test' profile sets the ${env} property to 'test', which ultimately 
      is translated into the path '/resources/conf/test' in order to use the environment-specific 
      'build.properties' file and 'deploy.sh' script. 'test' does not automatically 
      deploy, in case you want to just run tests without wasting time deploying 
      the same version of the war file -->
    <profile>
      <id>test</id>
      <properties>
        <env>test</env>
      </properties>
    </profile>

    <!-- 'load' -->
    <!-- Maybe you need a second internal implementation pointing to your 
      production environment just for ETL? This is here to illustrate that "sure, 
      you can do that!" -->
    <profile>
      <id>load</id>
      <properties>
        <env>load</env>
        <skip.auth.test>true</skip.auth.test>
        <skip.noauth.test>true</skip.noauth.test>
      </properties>
    </profile>

    <!-- 'prod' -->
    <!-- The 'prod' profile sets the ${env} property to 'prod', which ultimately 
      is translated into the path '/resources/conf/prod' in order to use the environment-specific 
      'build.properties' file for filtering and 'deploy.sh' script for deployment. 
      Unlike other environment settings, no tests are run by default. -->
    <profile>
      <id>prod</id>
      <properties>
        <env>prod</env>
        <skip.auth.test>true</skip.auth.test>
        <skip.noauth.test>true</skip.noauth.test>
      </properties>
    </profile>

    <!-- When war-deploy is active, the exec plugin will execute with designated 
      environment settings. For example the command 'mvn -pdev,war-deploy' will 
      build your warfile, run your /resources/conf/dev/deploy.sh script, and then 
      run both auth and no-auth testing -->
    <!-- There are two deploy.sh options shipped in the 'dev' directory: 
      deploy.sh_probe and deploy.sh_local -->
    <!-- deploy.sh_psiprobe: Rename to 'deploy.sh' to use the psi-probe tomcat 
      manager to automate deployment of your warfile to a remote host. -->
    <!-- deploy.sh_local: Rename to 'deploy.sh' if a pre-existing container 
      on the same server where you are building, and you don't have psiprobe installed. -->

    <profile>
      <id>war-deploy</id>
      <properties>
        <skip.war.deploy>false</skip.war.deploy>
      </properties>
      <!-- If you choose to use the included deployment script for non-local 
        environments, this is where it becomes relevant, to redeploy the war file 
        via curl/psiprobe and restart Tomcat. -->
      <!-- To deploy without testing, use 'pre-integration-test' as the goal -->
      <build>
        <plugins>
          <plugin>
		        <groupId>org.codehaus.mojo</groupId>
		        <artifactId>exec-maven-plugin</artifactId>
		        <version>1.3.2</version>
		        <configuration>
		          <skip>${skip.war.deploy}</skip>
		          <executable>/bin/bash</executable>
		          <arguments>
		            <!-- default arguments are equivalent to '-d psiprobe -r script'-->
		            <argument>${project.build.directory}/deploy.sh</argument>
		            <!-- uncomment the following to use scp to deploy the war file remotely via scp -->
		            <!-- <argument>-d scp</argument> -->
		            <!-- uncomment the following to use cp to deploy the war file locally -->
		            <!-- <argument>-d cp</argument> -->
		            <!-- uncomment the following to use linux 'service' command instead of catalina script -->
		            <!-- <argument>-r service</argument> -->
		            <!-- uncomment the following 'sudo' arg to use sudo locally or over ssh -->
		            <!-- <argument>s</argument> -->
		          </arguments>
		        </configuration>
		        <executions>
		          <execution>
		            <id>restart-tomcat</id>
		            <phase>pre-integration-test</phase>
		            <goals>
		              <goal>exec</goal>
		            </goals>
		          </execution>
		        </executions>
		      </plugin>
        </plugins>
      </build>
    </profile>
  </profiles>

  <!-- Mavens meaty bit -->
  <build>
    <!-- Change the following, for example to 'ROOT' and YADA will install as the ROOT context. 
      Feel free to change it. By default, the context will be YADA-Quickstart-version -->
    <finalName>${project.artifactId}-${project.version}</finalName>
    <!-- As you can see, this is where the local, dev, test, load, or prod 
      profile choice becomes relevant, defining the values used for filtering resources -->
    <filters>
      <filter>${basedir}/src/main/resources/${env}/build.properties</filter>
    </filters>
    <resources>
      <resource>
        <directory>${basedir}/src/main/resources</directory>
        <!-- This is here as an example of how to include extra resources 
          in your deployable, that you may, for example, be required by one of your 
          java plugins -->
        <includes>
          <include>templates/**</include>
        </includes>
        <!-- We exclude the environment settings from the deployable (duh) -->
        <excludes>
          <exclude>db/**</exclude>
          <exclude>izpack/**</exclude>
          <exclude>dev/**</exclude>
          <exclude>test/**</exclude>
          <exclude>load/**</exclude>
          <exclude>local/**</exclude>
          <exclude>prod/**</exclude>
        </excludes>
      </resource>
      <!-- Get the environment specific props files that should be included 
        in the deployable -->
      <resource>
        <directory>${basedir}/src/main/resources/${env}</directory>
        <filtering>true</filtering>
        <includes>
          <include>log4j.properties</include>
          <include>YADA.properties</include>
        </includes>
        <excludes>
          <exclude>**/*.sh</exclude>
          <exclude>**/*.jar</exclude>
          <exclude>**/*.zip</exclude>
          <exclude>**/*.png</exclude>
          <exclude>**/*.db</exclude>
          <exclude>**/*.txt</exclude>
        </excludes>
      </resource>
      <!-- filter the deployment script for the designated environment. the 
        exec plugin will execute it. The target path setting effectively omits it 
        from the deployable -->
      <resource>
        <directory>${basedir}/src/main/resources/${env}</directory>
        <targetPath>${project.build.directory}</targetPath>
        <filtering>true</filtering>
        <includes>
          <include>deploy.sh</include>
        </includes>
        <excludes>
          <exclude>**/YADA.properties</exclude>
          <exclude>**/log4j.properties</exclude>
          <exclude>**/*.jar</exclude>
          <exclude>**/*.zip</exclude>
          <exclude>**/*.png</exclude>
          <exclude>**/*.db</exclude>
          <exclude>**/*.txt</exclude>
        </excludes>
      </resource>
    </resources>

    <!-- Maven's testResources config, so you can include your internal tests 
      and filter them -->
    <testResources>
      <!-- Your test properties and testng xml configs are in 'conf' -->
      <testResource>
        <directory>${basedir}/src/test/resources/conf</directory>
        <filtering>true</filtering>
        <targetPath>conf</targetPath>
      </testResource>
      <!-- Your test files containing query strings are in 'test' -->
      <testResource>
        <directory>${basedir}/src/test/resources/test</directory>
        <filtering>false</filtering>
        <targetPath>test</targetPath>
      </testResource>
    </testResources>

    <!-- The war plugin builds the deployable, the context.xml is defined 
      locally in your project. Anything else you include under '${basedir}/src/main/webapp' 
      should append or overwrite the artifacts in yada-war. This is how you customize 
      the 'yada-admin' tool, for example. -->
    <plugins>
      <plugin>
        <groupId>com.mycila</groupId>
        <artifactId>license-maven-plugin</artifactId>
        <version>2.11</version>
        <configuration>
          <header>${basedir}/src/main/resources/license.txt</header>
          <useDefaultExcludes>true</useDefaultExcludes>
          <properties>
            <year>${project.inceptionYear}</year>
          </properties>
          <includes>
            <include>**/*.java</include>
            <include>**/*.xml</include>
            <include>**/*.html</include>
            <include>**/*.jsp</include>
            <include>**/*.sh</include>
          </includes>
          <excludes>
            <exclude>pom.xml</exclude>
            <exclude>src/main/resources/izpack/*.xml</exclude>
            <exclude>src/main/resources/izpack/*.txt</exclude>
            <exclude>src/main/resources/izpack/apache-tomcat-*/**</exclude>
            <exclude>src/test/resources/conf/**</exclude>
            <exclude>src/test/resources/test/**</exclude>
            <exclude>src/main/webapp/META-INF/**</exclude>
            <exclude>target/**</exclude>
          </excludes>
        </configuration>
        <executions>
          <execution>
            <goals>
              <goal>check</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-war-plugin</artifactId>
        <version>2.6</version>
        <configuration>
          <filteringDeploymentDescriptors>true</filteringDeploymentDescriptors>
          <archive>
            <addMavenDescriptor>false</addMavenDescriptor>
          </archive>
          <webResources>
            <!-- includes the default sqlite db in the war file -->
            <!-- comment out the following resource section to exclude the 
              YADA.db sqlite file from the artifact -->
            <resource>
              <directory>${basedir}/src/main/resources/db/</directory>
              <filtering>false</filtering>
              <include>YADA.db</include>
            </resource>
            <!-- set context values including resources and env vars -->
            <resource>
              <directory>${basedir}/src/main/webapp/META-INF</directory>
              <targetPath>META-INF</targetPath>
              <filtering>true</filtering>
              <includes>
                <include>context.xml</include>
              </includes>
            </resource>
            <!-- put version stamp into nav bar -->
            <resource>
              <directory>${basedir}/src/main/webapp/yada-admin</directory>
              <targetPath>yada-admin</targetPath>
              <filtering>true</filtering>
              <includes>
                <include>index.html</include>
                <include>config.json</include>
              </includes>
            </resource>
          </webResources>
          <overlay>
            <groupId>yada</groupId>
            <artifactId>yada-war</artifactId>
          </overlay>
        </configuration>
      </plugin>

      <!-- for local deployment and testing, cargo will create a new tomcat 
        instance in your target directory, and start it up. If you want to do interactive 
        testing change the goal from 'start' to 'run' -->
      <plugin>
        <groupId>org.codehaus.cargo</groupId>
        <artifactId>cargo-maven2-plugin</artifactId>
        <version>1.2.2</version>
        <configuration>
          <skip>${skip.cargo.deploy}</skip>
          <container>
            <containerId>tomcat</containerId>
            <home>${YADA.local.tomcat.home}</home>
          </container>
          <configuration>
            <type>standalone</type>
          </configuration>
        </configuration>
        <executions>
          <execution>
            <id>test-deploy</id>
            <phase>pre-integration-test</phase>
            <goals>
              <!-- change from 'start' to 'run' to do interactive testing, 
                or change to a property to pass on the command line -->
              <goal>start</goal>
            </goals>
          </execution>
        </executions>
      </plugin>

      <!-- Integration test execution -->
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-failsafe-plugin</artifactId>
        <version>2.18</version>
        <executions>
          <execution>
            <id>noauth-test</id>
            <phase>integration-test</phase>
            <goals>
              <goal>integration-test</goal>
            </goals>
            <configuration>
              <properties>
                <!-- The use of the QueryFileTransformer listener makes test 
                  toggling possible. Omitting it relegates test methods to in-code configuration, 
                  thereby forcing the skipping of any superclass-(i.e.,ServiceTest)-defined 
                  methods. -->
                <property>
                  <name>listener</name>
                  <value>com.novartis.opensource.yada.test.QueryFileTransformer</value>
                </property>
              </properties>
              <skipTests>${skip.noauth.test}</skipTests>
              <!-- <reportFormat>plain</reportFormat> -->
              <trimStackTrace>false</trimStackTrace>
              <useSystemClassLoader>false</useSystemClassLoader>
              <systemPropertyVariables>
                <java.naming.factory.initial>org.apache.naming.java.javaURLContextFactory</java.naming.factory.initial>
                <java.naming.factory.url.pkgs>org.apache.catalina.util.naming</java.naming.factory.url.pkgs>
                <java.naming.provider.url>org.apache.naming</java.naming.provider.url>
              </systemPropertyVariables>
              <additionalClasspathElements>
                <additionalClasspathElement>${basedir}/target/test-classes/conf/TestNG_YADA_Internal_noauth.properties</additionalClasspathElement>
              </additionalClasspathElements>
              <suiteXmlFiles>
                <suiteXmlFile>src/test/resources/conf/TestNG_YADA_Internal_noauth.xml</suiteXmlFile>
              </suiteXmlFiles>
              <dependenciesToScan>
                <dependency>yada:yada-api</dependency>
              </dependenciesToScan>
            </configuration>
          </execution>
          <execution>
            <id>auth-test</id>
            <phase>integration-test</phase>
            <goals>
              <goal>integration-test</goal>
            </goals>
            <configuration>
              <skipTests>${skip.auth.test}</skipTests>
              <useSystemClassLoader>false</useSystemClassLoader>
              <systemPropertyVariables>
                <java.naming.factory.initial>org.apache.naming.java.javaURLContextFactory</java.naming.factory.initial>
                <java.naming.factory.url.pkgs>org.apache.catalina.util.naming</java.naming.factory.url.pkgs>
                <java.naming.provider.url>org.apache.naming</java.naming.provider.url>
              </systemPropertyVariables>
              <additionalClasspathElements>
                <additionalClasspathElement>${basedir}/target/test-classes/conf/TestNG_YADA_Internal_auth.properties</additionalClasspathElement>
              </additionalClasspathElements>
              <suiteXmlFiles>
                <suiteXmlFile>src/test/resources/conf/TestNG_YADA_Internal_auth.xml</suiteXmlFile>
              </suiteXmlFiles>
              <dependenciesToScan>
                <dependency>yada:yada-api</dependency>
              </dependenciesToScan>
            </configuration>
          </execution>
        </executions>
      </plugin>

      <!-- Unit tests are suppressed -->
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>2.18.1</version>
        <!-- surefire is skipped by default to circumvent api testing which 
          would otherwise run and fail, because the tests are included in the test-jar. 
          The relevent tests for the war file are run by failsafe. -->
        <configuration>
          <skip>true</skip>
        </configuration>
      </plugin>
      
      <!--  for sonatype release to maven central -->
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-gpg-plugin</artifactId>
        <version>1.5</version>
        <executions>
          <execution>
            <id>sign-artifacts</id>
            <phase>verify</phase>
            <goals>
              <goal>sign</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
      
    </plugins>
  </build>

  <!-- If you write custom YADA java plugins, for example, maybe you need 
    to support uploading and parsing of excel spreadsheets and require Poi to 
    compile your plugin, this is where you add the dependency -->
  <dependencies>
    <dependency>
      <groupId>${project.groupId}</groupId>
      <artifactId>yada-api</artifactId>
      <version>${project.version}</version>
    </dependency>
    <dependency>
      <groupId>${project.groupId}</groupId>
      <artifactId>yada-war</artifactId>
      <version>${project.version}</version>
      <type>war</type>
    </dependency>
    <dependency>
      <groupId>${project.groupId}</groupId>
      <artifactId>yada-api</artifactId>
      <version>${project.version}</version>
      <type>test-jar</type>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupId>org.apache.tomcat</groupId>
      <artifactId>dbcp</artifactId>
      <version>6.0.32</version>
      <scope>provided</scope>
    </dependency>
    <dependency>
      <groupId>org.testng</groupId>
      <artifactId>testng</artifactId>
      <version>6.8.21</version>
    </dependency>
    <dependency>
      <groupId>nl.javadude.assumeng</groupId>
      <artifactId>assumeng</artifactId>
      <version>1.2.4</version>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupId>com.vertica</groupId>
      <artifactId>vertica-jdbc</artifactId>
      <version>7.1.1-1</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>mysql</groupId>
      <artifactId>mysql-connector-java</artifactId>
      <version>5.1.31</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>postgresql</groupId>
      <artifactId>postgresql</artifactId>
      <version>9.2-1002.jdbc4</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.xerial</groupId>
      <artifactId>sqlite-jdbc</artifactId>
      <version>3.8.11.1</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>com.oracle</groupId>
      <artifactId>ojdbc6</artifactId>
      <version>11.2.0.3</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>javax.servlet</groupId>
      <artifactId>servlet-api</artifactId>
      <version>2.5</version>
      <scope>provided</scope>
    </dependency>
    <dependency>
      <groupId>org.apache.tomcat</groupId>
      <artifactId>catalina</artifactId>
      <version>6.0.37</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>