Builds of AMG for different versions of jdk and tomcat, and for a standalone version

The framework is developed using java 1.4, and we deploy it as a web application both in a tomcat 4 and tomcat 5.
As an experiment, we tried to compile the code with java 1.5, and tried to deploy the web application on a tomcat 5.5 (which uses java 1.5)
The conclusion is that is should be possible to use java 1.5. More exactly, this is what we found out at this moment:

  • The source can be compiled with Java 1.5. This version will then run only on a tomcat 5.5
    One additional remark is that you must have certain libraries in the common/endorsed folder of the tomcat. Below you will see links to those libraries.
  • It can be compiled with java 1.4, and can then be deployed on every tomcat I tried (4 and 5 and 5.5)
    As in the previous case, if you want to use it in tomcat 5.5, the below mentioned 4 libraries must be in the common/endorsed folder.

Below, you will find links to the previously mentioned builds.

  • Overview of all necessary libraries, including a zip-file containing all of them.
  • For java 1.4 (last updated: 2005-04-14)
  • For java 1.5 (last updated 2005-03-18): ! important ! This version is out of date: as it is not our intent to provide support for java 1.5 at this moment, we do not update this version. This has as consequence that for example the explanation below is not correct for the java 1.5 jar and war. However if you would want a version for java 1.5, please feel free to contact us, so we can provide you with such a version.
  • The libraries that must be put in the common/endorsed folder, if you want to use it with tomcat 5.5 (last updated 2005-03-18)
  • Web application:
    To run the framework as a web service, you should do the following:
    1. Get the war-file.
    2. Deploy it on your application server (we use a tomcat).
    3. When the application is up and running, in a browser go to the ./install/config.jsp page within your web application. There you will find an overview of parameters that are used within the application. The "validate jaxp, sax, dom & xalan" link tests for the availability of some libraries. The "validate configuration" link checks whether the parameters are (probably) correct, by looking eg for the existence of the given directories. You can change the parameters, and by clicking the submit-button, the parameters will be saved.
  • Standalone:
    To be able to run the framework stand-alone (so not as a webservice), you should do the following:
    • Get all the libraries, that are summed up at http://ariadne.cs.kuleuven.ac.be/amg/libraries.php
    • Get the jar, for example of the java 1.4 version.
    • Get the ariadneV4.properties file template, and do the following:
      1. Give the fields the correct value. Normally it should be clear what you are supposed to put there. If it would not be clear, feel free to contact us. There are however 2 entries that need some more explanation:
        1. LMdir: this is a directory, containing some files for determining the language. A zipped version of this directory can be found here. So you should unpack this, and let the LMdir entry point to the destination directory.
        2. gen.configurationfiles: this should point to the directory where some configuration files are. You can find the files at Sourceforge, namely the ariadneConf directory. A zipped version of this can be found here.
        Side remark: the fields you find here, are the same as the ones you find in the config.jsp page, mentioned above for the web application version. So indeed, the config.jsp file for the web application version just provides a graphical interface for adapting the ariadneV4.properties file.
      2. Make sure to add the ariadneV4.properties file to your java classpath.
    • After having the previous steps, you can try it for example by running the following java command:
      java org.ariadne.autoindexing.indexers.contextBasedIndexers.FileSystemContextBasedIndexer /home/test.pdf lom
      What we do there is the following:
      1. we execute the main method of the FileSystemContextBasedIndexer class. This is just a test method to illustrate how the framework can be used.
      2. The first argument is the file we want to generate metadata for. As it is in this case a PDF file, some PDF specific methods will be executed.
      3. The second argument is the metadata format in which we want to retrieve the results. The possible strings you can provide there, can be found as constants in the IndexingService class... Eg "lom" represents LOM XML. The metadata formats we support right now, are the following:
        1. the Ariadne LOM application profile
        2. the general LOM standard
        3. a humanreadable version
        4. a very basic version of Dublin Core. Please note that the Dublin Core version will not include all generated metadata. This is due to the way we work with metadata right now:
          • Internally, we work with Ariadne-specific classes, that implement the Ariadne LOM application profile. At this moment we are looking for ways to change this, to make it more generic. We haven't decided yet how we will tackle this issue, but in the (near?) future, our approach will change.
          • To be able to generate not only Ariadne-specific metadata or LOM metadata, we do the following:
            • After having generated Ariadne metadata, we transform it to LOM (we have a stylesheet doing that)
            • That LOM is then used as input for a Java library implementing the LOM standard (see http://edusource.athabascau.ca/LOM-tools.html)
            • That library provides support for transforming LOM to other metadata standards. It does this by a mechanism of marshallers. For example, there is a Dublin Core Marshaller that allows to transform LOM into DC. The marshallers that are provided in the library are however made as a proof of concept. It is basically functional, but probably needs some extra attention when wanting to use it. When marhalling to DC, some available information is lost... and that is why the Dublin Core version is more limited than the other versions.
          • So: when somebody would want support for some other metadata format, it is a matter of writing a new Marshaller, and that should do the job. I however must admit that I have not tried this yet myself, so I can't make a judgement on how well this works.
    • Please note that is is not our first concern to make available a standalone version. In the future, we will aim to achieve both a web application version, and a standalone version. But we haven't tested the standalone version thoroughly, so errors are possible... As always, we would be happy to hear suggestions and comments about all our work, including the standalone version.