Details

    • Type: Task Task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.2.1
    • Fix Version/s: 2.2.1
    • Component/s: Dependencies
    • Labels:
      None

      Description

      Some dependencies are duplicate, so we need to reduce the redundancies.
      For example, I found the followings need to be refined:

      (1) In components/jetspeed-registry,
      javax.xml.bind:jaxb-api:jar:2.1:compile could be
      replaced by org.apache.geronimo.specs:geronimo-jaxb_2.1_spec:1.0
      Accordingly, the transitive dependencies could be replaced as well:
      stax-api-1.0-2.jar by geronimo-stax-api_1.0_spec-1.0.1.jar
      (By the way, we still need to keep both activation-1.1.jar geronimo-activation_1.1_spec-1.0.2.jar
      because activation.jar contains implementations as well as interfaces.)

      (2) In components/jetspeed-cm and in other components:
      javax.transaction:jta:jar:1.0.1B:runtime could be
      replaced by org.apache.geronimo.specs:geronimo-jta_1.1_spec.

      (3) In components/jetspeed-portal
      mail-1.3.3.jar could be replaced by geronimo-javamail_1.4_spec-1.6.jar
      (geronimo-javamail_1.4_spec-1.6.jar seems to have been used by CXF already.)

        Activity

        Hide
        Woonsan Ko added a comment -

        Fixed.

        Removed javax.activation:activation:jar because geronimo-javamail_1.4_provider contains implementations for JAF.
        By the way, we cannot simply use the geronimo javamail pom dependency because the pom does not have those three (javamail spec, javamail provider and activation spec) in the dependency list and so it doesn't pull out those transitively.
        Therefore, I left those separately defined.

        Show
        Woonsan Ko added a comment - Fixed. Removed javax.activation:activation:jar because geronimo-javamail_1.4_provider contains implementations for JAF. By the way, we cannot simply use the geronimo javamail pom dependency because the pom does not have those three (javamail spec, javamail provider and activation spec) in the dependency list and so it doesn't pull out those transitively. Therefore, I left those separately defined.
        Hide
        Woonsan Ko added a comment -

        Oh, Ate's solution with geronimo javamail pom looks better.

        Show
        Woonsan Ko added a comment - Oh, Ate's solution with geronimo javamail pom looks better.
        Hide
        Woonsan Ko added a comment -

        Fixed.

        In addition to the description of the issue,

        • jaxb-api-2.1.jar is removed because we have geronimo-jaxb_2.1_spec-1.0.jar.
        • jta-1.0.1B.jar is removed because we have geronimo-jta_1.1_spec-1.1.jar
        • mail-1.3.3.jar is replaced by geronimo-stax-api_1.0_spec-1.0.1.jar and geronimo-javamail_1.4_provider-1.7.jar
        • stax-api-1.0-2.jar is removed because we have geronimo-stax-api_1.0_spec-1.0.1.jar
        Show
        Woonsan Ko added a comment - Fixed. In addition to the description of the issue, jaxb-api-2.1.jar is removed because we have geronimo-jaxb_2.1_spec-1.0.jar. jta-1.0.1B.jar is removed because we have geronimo-jta_1.1_spec-1.1.jar mail-1.3.3.jar is replaced by geronimo-stax-api_1.0_spec-1.0.1.jar and geronimo-javamail_1.4_provider-1.7.jar stax-api-1.0-2.jar is removed because we have geronimo-stax-api_1.0_spec-1.0.1.jar
        Hide
        Ate Douma added a comment -

        Hi Woonsan,

        I looked briefly at the activation/javamail dependencies and how these supposedly can completelyreplaced with geronimo specs and implementations.
        I think the implementation classes within activation-1.1.jar won't be needed/used then (or at all even).
        Documentation about replacing javamail with geronimo is very limited, but the following blog post seems helpful, especially in the context of cxf: http://sdomsta.blogspot.com/2009/03/java-mail-smtp-transport-provider.html

        If I understand it correctly, the activation and javamail jars can be excluded if we just add an dependency on the Geronimo JavaMail Bundle pom and explicitly exclude activation/javamail from whatever dependency pulls them in:

        org.apache.geronimo.javamail:geronimo-javamail_1.4:1.7:pom

        That one will pull in all the needed dependencies:

        org.apache.geronimo.specs:geronimo-activation_1.1_spec:1.0.2:jar
        org.apache.geronimo.specs:geronimo-javamail_1.4_spec:1.6:jar
        org.apache.geronimo.javamail:geronimo-javamail_1.4_provider:1.7:jar

        Testing if it really works without the activation/javamail jars should be easy by configuring an smtp server and trying to send an email through the self registration portlet.

        Show
        Ate Douma added a comment - Hi Woonsan, I looked briefly at the activation/javamail dependencies and how these supposedly can completelyreplaced with geronimo specs and implementations. I think the implementation classes within activation-1.1.jar won't be needed/used then (or at all even). Documentation about replacing javamail with geronimo is very limited, but the following blog post seems helpful, especially in the context of cxf: http://sdomsta.blogspot.com/2009/03/java-mail-smtp-transport-provider.html If I understand it correctly, the activation and javamail jars can be excluded if we just add an dependency on the Geronimo JavaMail Bundle pom and explicitly exclude activation/javamail from whatever dependency pulls them in: org.apache.geronimo.javamail:geronimo-javamail_1.4:1.7:pom That one will pull in all the needed dependencies: org.apache.geronimo.specs:geronimo-activation_1.1_spec:1.0.2:jar org.apache.geronimo.specs:geronimo-javamail_1.4_spec:1.6:jar org.apache.geronimo.javamail:geronimo-javamail_1.4_provider:1.7:jar Testing if it really works without the activation/javamail jars should be easy by configuring an smtp server and trying to send an email through the self registration portlet.

          People

          • Assignee:
            Woonsan Ko
            Reporter:
            Woonsan Ko
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development