cas-filemgr
Used in:
components
- OverviewOverview
- VersionsVersions
- DependentsDependents
- DependenciesDependencies
<dependency>
<groupId>ai.mattmann.mnemosyne</groupId>
<artifactId>cas-filemgr</artifactId>
<version>1.13.3</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/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>ai.mattmann.mnemosyne</groupId>
<artifactId>oodt-core</artifactId>
<version>1.13.3</version>
<relativePath>../core/pom.xml</relativePath>
</parent>
<artifactId>cas-filemgr</artifactId>
<name>Catalog and Archive File Management Component</name>
<description>
The file management component of a Catalog and Archive Service. This component
purposefully separates data stores and metadata stores as standard interfaces, and
provides some out of the box backend implementations of them (including one based
on the javax.sql.DataSource interface). This component provides everything that you need
to catalog, archive and manage files, and directories, and their associated metadata.
</description>
<properties>
<docker.build.disabled>false</docker.build.disabled>
<docker.image.name>oodt/filemgr:latest</docker.image.name>
</properties>
<dependencies>
<dependency>
<groupId>org.apache.avro</groupId>
<artifactId>avro</artifactId>
</dependency>
<dependency>
<groupId>org.apache.avro</groupId>
<artifactId>avro-ipc</artifactId>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-compress</artifactId>
</dependency>
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk</artifactId>
</dependency>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
</dependency>
<dependency>
<groupId>commons-cli</groupId>
<artifactId>commons-cli</artifactId>
</dependency>
<dependency>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
</dependency>
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-dbcp2</artifactId>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
</dependency>
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-pool2</artifactId>
</dependency>
<dependency>
<groupId>org.hsqldb</groupId>
<artifactId>hsqldb</artifactId>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.apache.lucene</groupId>
<artifactId>lucene-core</artifactId>
</dependency>
<dependency>
<groupId>org.apache.lucene</groupId>
<artifactId>lucene-analysis-common</artifactId>
</dependency>
<dependency>
<groupId>org.apache.lucene</groupId>
<artifactId>lucene-queryparser</artifactId>
</dependency>
<dependency>
<groupId>ai.mattmann.mnemosyne</groupId>
<artifactId>cas-cli</artifactId>
</dependency>
<dependency>
<groupId>ai.mattmann.mnemosyne</groupId>
<artifactId>cas-metadata</artifactId>
</dependency>
<dependency>
<groupId>ai.mattmann.mnemosyne</groupId>
<artifactId>oodt-commons</artifactId>
</dependency>
<dependency>
<groupId>ai.mattmann.mnemosyne</groupId>
<artifactId>oodt-conf</artifactId>
</dependency>
<dependency>
<groupId>org.apache.solr</groupId>
<artifactId>solr-solrj</artifactId>
<exclusions>
<exclusion>
<groupId>org.apache.lucene</groupId>
<artifactId>lucene-core</artifactId>
</exclusion>
<exclusion>
<groupId>org.apache.solr</groupId>
<artifactId>solr-lucene-core</artifactId>
</exclusion>
<exclusion>
<groupId>org.apache.zookeeper</groupId>
<artifactId>zookeeper</artifactId>
</exclusion>
</exclusions>
</dependency>
<!--
Detection, not parsing. Everything this module asks of Tika is
org.apache.tika.mime.* and the AutoDetectParser facade, all of which is
in tika-core; format parsers are found at runtime through the service
loader.
The parsers package brought seventeen format modules, POI, and through
those both Bouncy Castle and a log4j 1.x that had to be excluded for
CVE-2019-17571. Every deployment carried them so that one commented out
example extractor would work if somebody uncommented it. The
tika-parsers profile below puts them back for anyone who wants them.
-->
<dependency>
<groupId>org.apache.tika</groupId>
<artifactId>tika-core</artifactId>
</dependency>
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-all</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-all</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.python</groupId>
<artifactId>jython</artifactId>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.safehaus.jug</groupId>
<artifactId>jug</artifactId>
<classifier>asl</classifier>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jul-to-slf4j</artifactId>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-slf4j2-impl</artifactId>
</dependency>
</dependencies>
<build>
<directory>target</directory>
<finalName>${project.artifactId}-${project.version}</finalName>
<sourceDirectory>src/main/java</sourceDirectory>
<testSourceDirectory>src/test/java</testSourceDirectory>
<outputDirectory>target/classes</outputDirectory>
<testOutputDirectory>target/test-classes</testOutputDirectory>
<resources>
<resource>
<filtering>true</filtering>
<directory>${project.basedir}/src/main/resources</directory>
<excludes>
<exclude>**/*</exclude>
</excludes>
</resource>
</resources>
<testResources>
<testResource>
<directory>${project.basedir}/src/test/resources</directory>
<includes>
<include>**/*</include>
</includes>
</testResource>
</testResources>
<plugins>
<plugin>
<groupId>org.apache.avro</groupId>
<artifactId>avro-maven-plugin</artifactId>
<version>1.8.2</version>
<configuration>
<stringType>String</stringType>
<detail>true</detail>
</configuration>
<executions>
<execution>
<id>schemas</id>
<configuration>
<imports>
<import>${basedir}/src/main/avro/types/AvroMimeType.avsc</import>
<import>${basedir}/src/main/avro/types/AvroReference.avsc</import>
<import>${basedir}/src/main/avro/types/AvroExtractorSpec.avsc</import>
<import>${basedir}/src/main/avro/types/AvroMetadata.avsc</import>
<import>${basedir}/src/main/avro/types/AvroTypeHandler.avsc</import>
<import>${basedir}/src/main/avro/types/AvroProductType.avsc</import>
<import>${basedir}/src/main/avro/types/AvroProduct.avsc</import>
<import>${basedir}/src/main/avro/types/AvroFileTransferStatus.avsc</import>
<import>${basedir}/src/main/avro/types/AvroQueryCriteria.avsc</import>
<import>${basedir}/src/main/avro/types/AvroQuery.avsc</import>
<import>${basedir}/src/main/avro/types/AvroProductPage.avsc</import>
<import>${basedir}/src/main/avro/types/AvroElement.avsc</import>
<import>${basedir}/src/main/avro/types/AvroQueryResult.avsc</import>
<import>${basedir}/src/main/avro/types/AvroFilterAlgor.avsc</import>
<import>${basedir}/src/main/avro/types/AvroQueryFilter.avsc</import>
<import>${basedir}/src/main/avro/types/AvroComplexQuery.avsc</import>
</imports>
</configuration>
<goals>
<goal>schema</goal>
</goals>
</execution>
<execution>
<id>protocol</id>
<configuration>
<imports>
<import>${basedir}/src/main/avro/types</import>
</imports>
</configuration>
<goals>
<goal>idl-protocol</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<!--
These two exercise the example extractors, which need a real
parser behind Tika. Without the parser modules AutoDetectParser
falls back to EmptyParser and they fail on the very assertion
that says the document was never read. They run under the
tika-parsers profile, which supplies them.
-->
<excludes>
<exclude>**/TestTikaAutoDetectExtractor.java</exclude>
<exclude>**/TestTikaOfficeExtraction.java</exclude>
</excludes>
<forkMode>pertest</forkMode>
<argLine>-enableassertions --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED</argLine>
<useSystemClassLoader>false</useSystemClassLoader>
<systemProperties>
<property>
<name>java.util.logging.config.file</name>
<value>src/test/resources/test.logging.properties</value>
</property>
<property>
<name>log4j.configurationFile</name>
<value>src/main/resources/log4j2.xml</value>
</property>
</systemProperties>
<environmentVariables>
<FILEMGR_HOME>${project.basedir}</FILEMGR_HOME>
<OODT_PROJECT>primary</OODT_PROJECT>
</environmentVariables>
<forkedProcessTimeoutInSeconds>0</forkedProcessTimeoutInSeconds>
<redirectTestOutputToFile>true</redirectTestOutputToFile>
<includes>
<include>**/*Test*.java</include>
</includes>
</configuration>
<version>2.22.2</version></plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.6</version>
<configuration>
<!-- Built for local use, not attached: these RADiX bundles are ~159 MB
each and are deployment archives rather than library artifacts. -->
<attach>false</attach>
<appendAssemblyId>false</appendAssemblyId>
<descriptors>
<descriptor>src/main/assembly/assembly.xml</descriptor>
</descriptors>
<archive>
<manifest>
<mainClass>org.apache.oodt.cas.filemgr.system.AvroRpcFileManagerClient</mainClass>
</manifest>
</archive>
</configuration>
<executions>
<execution>
<goals>
<goal>single</goal>
</goals>
<phase>package</phase>
</execution>
</executions>
</plugin>
</plugins>
</build>
<!--
Declared explicitly rather than inherited. Maven appends the module path to
an inherited url and scm, publishing a 404 project url and an scm
connection ending in ".git/<module>". The child.*.inherit.append.path
attributes meant to suppress that are not honoured under Maven 3.9.
-->
<url>https://github.com/chrismattmann/mnemosyne</url>
<scm>
<connection>scm:git:https://github.com/chrismattmann/mnemosyne.git</connection>
<developerConnection>scm:git:https://github.com/chrismattmann/mnemosyne.git</developerConnection>
<url>https://github.com/chrismattmann/mnemosyne</url>
<tag>HEAD</tag>
</scm>
<repositories>
<repository>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
<id>sonatype-nexus</id>
<url>https://oss.sonatype.org/content/groups/public</url>
</repository>
</repositories>
<profiles>
<!--
Tika's format parsers, for the example metadata extractors.
TikaAutoDetectExtractor and TikaCmdLineMetExtractor are the only things
here that read a document's content rather than identify its type, and
neither is enabled in any shipped policy: the one reference to the
first sits inside an XML comment in the example product-types.xml. So
the parsers are opt in, and a deployment that does not extract content
does not carry them.
-->
<profile>
<id>tika-parsers</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
<dependencies>
<dependency>
<groupId>org.apache.tika</groupId>
<artifactId>tika-parsers-standard-package</artifactId>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<excludes combine.self="override"/>
</configuration>
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>audit</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>rat-maven-plugin</artifactId>
<configuration>
<excludes>
<exclude>**/testdata/*</exclude>
<exclude>**/testdata/**/*</exclude>
</excludes>
</configuration>
<executions>
<execution>
<goals>
<goal>check</goal>
</goals>
<phase>verify</phase>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
</project>