2 Replies Latest reply on Aug 27, 2009 8:41 AM by Jeff Mesnil

    Why were these classes added to the hornetq-core-client.jar?

    Tim Fox Master


       <include name="org/hornetq/core/server/HornetQComponent.class"/>
       <include name="org/hornetq/core/server/JournalType.class"/>
       <include name="org/hornetq/core/journal/EncodingSupport.class"/>
       <include name="org/hornetq/core/server/ServerMessage.class"/>

      They were added in revision 7798 by Clebert.

      Can anyone shed some light on this?

        • 1. Re: Why were these classes added to the hornetq-core-client.
          Jeff Mesnil Master


          "timfox" wrote:

          They were added in revision 7798 by Clebert.

          They have been added since longer than that, at least r4062:


          I'll investigate why/if we need to add them to the core client jar

          • 2. Re: Why were these classes added to the hornetq-core-client.
            Jeff Mesnil Master

            Some findings about our hornetq-core-client jar dependencies:

            * required by DiscoveryGroup
            => break deps by adding start()/stop() directly to DiscoveryGroup
            * required by Configuration
            => break deps by adding start()/stop() directly
            => ideally, Configuration should move to org.hornetq.server.config and leave only TransportConfiguration in org.hornetq.config

            required by SessionSendMessage
            => TODO: removed call to ServerMessageImpl ctor from SessionSendMessage & add a ServerMessageImpl ctor taking SessionSendMessage as parameter

            => required by transitivity to ServerMessage (see above)

            => required by transitivity to Configuration
            => should be moved in same package than Configuration

            We include *too much* in the client jar:

            => this also includes RemotingServiceImpl which must be only on the server side
            => clients need only remoting/*.class, spi & impl subpackages

            => this includes all the management implementation in addition to the API
            => clients need only management/*.class for the API

            Our package hierarchy is not consistent:

            org.hornetq.client subpackages => for the client side
            org.hornet.server subpackages => for the server side
            org.hornetq.core subpackages => it depends

            Server packages that should be moved under org.hornet.server:
            * asyncio
            * deployers
            * journal
            * paging
            * persistence
            * postoffice
            * security
            * settings

            I also think we should split our code into several source folders to let the Java compiler check our dependencies rather to do it manually from time to time

            src/client => all types required by client (no dep)
            src/jms-client => all types required by JMS + dep to src/client
            src/server => all types required by server + dep to src/client & src/jms-client

            this way, we could compile src/client in a single step to build hornetq core client without introducing server classes by error

            We could do this refactoring if/when we switch to Maven for our build process