4 Replies Latest reply on May 26, 2009 7:22 AM by Tim Fox

    Jar dependencies chapter

    Tim Fox Master

      Looks good so far, some comments suggestions:

      1) We need a section on what jars the user needs on the client and server classpaths, e.g.

      If you're using core, you need:

      jbm-core-core-client.jar

      if you're using netty you need netty.jar

      if you're using jms you need jbm-jms-cllient.jar (we should have separate jar for jms *client* stuff)

      If you're using log4j you need.. blah blah

      3)

      We should also take the javax.jms.* interface classes out of jboss-jee.jar and put them in their own jar so the user doesn't have to include *all* the jee classes.

      4) Also I think we should take all the jars that the JBoss MC needs to run, unzip them and rebuild them into another jar jboss-mc.jar (or whatever) and distribute that, this will greatly limit and simplify the number of jars we distribute.

      5) jboss-logging.jar has dependencies to both log4j *and* jboss as logging. Is this right? I don't think we should expect users who just want to use log4j to include all the jboss as logging jars!

      6) Why are we including jbm-ra.jar in the distro? Isn't jbm-ra.jar sufficient?

      7) JAASSecurity manager should be in core, not integration layer, since JAAS is standard part of JDK now. (I have moved this).

        • 1. Re: Jar dependencies chapter
          Andy Taylor Master

           

          1) We need a section on what jars the user needs on the client and server classpaths, e.g.

          If you're using core, you need:

          jbm-core-core-client.jar

          if you're using netty you need netty.jar

          if you're using jms you need jbm-jms-cllient.jar (we should have separate jar for jms *client* stuff)

          If you're using log4j you need.. blah blah


          +1

          3)

          We should also take the javax.jms.* interface classes out of jboss-jee.jar and put them in their own jar so the user doesn't have to include *all* the jee classes.

          4) Also I think we should take all the jars that the JBoss MC needs to run, unzip them and rebuild them into another jar jboss-mc.jar (or whatever) and distribute that, this will greatly limit and simplify the number of jars we distribute.


          what happened to 2?

          makes sense. should we do this in the build, i.e. unzip - zip or is there a better way?

          5) jboss-logging.jar has dependencies to both log4j *and* jboss as logging. Is this right? I don't think we should expect users who just want to use log4j to include all the jboss as logging jars!


          do you mean jbm-logging.jar or jboss-common-logging.jar?

          6) Why are we including jbm-ra.jar in the distro? Isn't jbm-ra.jar sufficient?


          Its used when creating the AS profile from the distro.



          • 2. Re: Jar dependencies chapter
            Clebert Suconic Master

            For 1) I' ve listed the dependencies on the JARs versus feature. I will try to make it more explicity though.

            • 3. Re: Jar dependencies chapter
              Clebert Suconic Master

              +1 on 4. Too many JARs. and it would be easier to redistribute it as one jar.
              Don' t know if there are license issues with trove and jaxb used by the MicroContainer though. Can we repack and redistribute a jar?

              (I know there are some restrictions.. sometimes you can as long as you mention license terms.. .I" m not sure)

              • 4. Re: Jar dependencies chapter
                Tim Fox Master

                I added a chapter on client classpath, Clebert please check and complete.

                We need to cover:

                pure core client
                jms client
                jndi client
                java ee jars
                etc