XRN Dependancies

  • Here are the dependancies I find :

    Ant task dependancies :

    xalan 2.5.1
    xercesImpl 2.4.0
    ant 1.6.1 use 1.5.2 in the maven-plugin

    GUI dependancies :

    dom4j 1.5
    jaxb-api 1.0.4
    jaxb-impl 1.0.4
    jaxb-libs 1.0.4
    jaxb-xjc 1.0.4
    relaxngDatatype 1.0
    fop 0.20.5
    jax-qname UNKNOWN
    namespace UNKNOWN
    You use too the avalon logger

    If you have any idea about the UNKNOW version number let me know

    • Concerning the XRN core dependencies, they are accurately (described in the XRN release notes, I'm working on that so that this is clearer):

      - xercesImpl.jar and xml-api.jar shipped with the Ant V1.5.0,
      - ant.jar and optional.jar shipped with the same Ant V1.5.0,
      - saxon.jar, which is now present under the 'lib' project directory.

    • Carsten

      Now, all jars (GUI) should be available in the libs dir (CVS). Don't know the version of jax-qname und namespace. These are smaller libs which comes with JAXB.

    • That will not facilitate the ant/maven compatibility !

      Here are a few advices :

      + use versioned jar only
      - don't include jar in the project itself according to asf licence the user should find sun jar himselt, no ?
      + add in cvs a new module that contains the dependancies if possible structured like the http://www.ibiblio/maven ones
      + add a dependancies.properties file that mask the version number we use for the ant task (maybe this can of file can be exploited by xrn too? ). Here was something I use when I use ant (1.5 year ago ;) )
      And in the build.xml use the ${xercesImpl.deps} to create the class path
      + ant build process should do a a get for internet if the jar is not present in the maven local repository ie
      <get ignoreerrors="true" usetimestamp="true" dest="${maven.repo.local}/${jar}" src="${maven.get.jars.baseUrl}/${jar}" />

      I am not _for_ having jar/generate file/classes in a maven repo but we can't have a build process who work without it.
      An alternative solution could be have some build failure with a significative message that point the user where to find some jar if this jar are not compatible with open source license.