Spring Web Services
  1. Spring Web Services
  2. SWS-678

jms 1.1 dependency jar - change to freely available jar in M2 Central

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Won't Fix
    • Affects Version/s: 2.0 RC2
    • Fix Version/s: 2.0 GA
    • Component/s: Core, Samples
    • Labels:
      None
    • Environment:
      Ubuntu, maven 3.0.1, jdk 1.6.0_22

      Description

      Tried to build after checkout gives following output:

      ERROR] Failed to execute goal on project spring-ws-support: Could not resolve dependencies for project org.springframework.ws:spring-ws-support:jar:2.0.0-RC2: The following artifacts could not be resolved: javax.jms:jms:jar:1.1, javax.ejb:ejb:jar:2.1: Could not find artifact javax.jms:jms:jar:1.1 in central (http://repo1.maven.org/maven2) -> [Help 1]
      

      Use the following for jms-dependency:

      <dependency>
          <groupId>org.apache.geronimo.specs</groupId>
          <artifactId>geronimo-jms_1.1_spec</artifactId>
          <version>1.1.1</version>
      </dependency>
      

        Activity

        Hide
        Arjen Poutsma added a comment -

        We prefer to use the javax.* group ids in maven, as this is what Maven recommends. I understand that it can be a bit cumbersome to download & install them manually.

        Show
        Arjen Poutsma added a comment - We prefer to use the javax.* group ids in maven, as this is what Maven recommends. I understand that it can be a bit cumbersome to download & install them manually.
        Hide
        Joerg Bellmann added a comment -

        With respect to SWS-644 this patch only replaces the jms dependencies.

        Show
        Joerg Bellmann added a comment - With respect to SWS-644 this patch only replaces the jms dependencies.
        Hide
        Joerg Bellmann added a comment -

        I would not say that Maven recommends this. If you refer to this site all I read is how to do it when I use Sun's artifacts. And that Apache isn't allowed to distribute them from ibiblio because these artifacts fall under a bad license for oss. And that it seems there are no naming conventions for these artifacts at Sun.

        Conclusion: Don't use these artifacts. Use the artifacts for all JEE - APIs from Apache. They are available here and in M2 Central and have the right license. Running mvn on a fresh SWS-checkout will resolve them and don't break the build.

        All fine.

        Show
        Joerg Bellmann added a comment - I would not say that Maven recommends this. If you refer to this site all I read is how to do it when I use Sun's artifacts. And that Apache isn't allowed to distribute them from ibiblio because these artifacts fall under a bad license for oss. And that it seems there are no naming conventions for these artifacts at Sun. Conclusion: Don't use these artifacts. Use the artifacts for all JEE - APIs from Apache. They are available here and in M2 Central and have the right license . Running mvn on a fresh SWS-checkout will resolve them and don't break the build. All fine.
        Hide
        Arjen Poutsma added a comment -

        Let me try and explain my reasoning for using the javax.* group ids. We want to use one consistent approach, so it's either going to be javax.* or org.apache.gernimo.specs for all JEE specs (jms, mail, activation, ejb, etc.). The problem is that some of the Spring-WS dependencies depend on the javax.* jars, so even if we use the geronimo specs, we still end up with javax.* on the classpath (unless we disable those transitive dependencies with exclusions, which is another world of pain). Finally, we also depend on some SUN/Oracle-specific extensions of the JavaMail jar (to enable IMAP IDLE support). I could not find these extensions in the geronimo specs.

        So, once again, I understand that it can be a pain to download & install the javax.* jars manually, but I think the current solution is the best, though that's not saying much.

        Show
        Arjen Poutsma added a comment - Let me try and explain my reasoning for using the javax.* group ids. We want to use one consistent approach, so it's either going to be javax.* or org.apache.gernimo.specs for all JEE specs (jms, mail, activation, ejb, etc.). The problem is that some of the Spring-WS dependencies depend on the javax.* jars, so even if we use the geronimo specs, we still end up with javax.* on the classpath (unless we disable those transitive dependencies with exclusions, which is another world of pain). Finally, we also depend on some SUN/Oracle-specific extensions of the JavaMail jar (to enable IMAP IDLE support). I could not find these extensions in the geronimo specs. So, once again, I understand that it can be a pain to download & install the javax.* jars manually, but I think the current solution is the best, though that's not saying much.
        Hide
        Arjen Poutsma added a comment -

        Closing old issues

        Show
        Arjen Poutsma added a comment - Closing old issues

          People

          • Assignee:
            Arjen Poutsma
            Reporter:
            Joerg Bellmann
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - Not Specified
              Not Specified
              Remaining:
              Remaining Estimate - 0d
              0d
              Logged:
              Time Spent - 1h 31m
              1h 31m