8 Replies Latest reply on Dec 6, 2006 5:23 PM by thomas.diesler

    Proposed new package structure

    thomas.diesler

      Folks,

      the current package structure is becomming a little clutterd. I propose the following change to top level packages

      org.jboss.ws.annotation
      
      org.jboss.ws.common
      org.jboss.ws.common.metadata
      org.jboss.ws.common.utils
      
      org.jboss.ws.core
      org.jboss.ws.core.binding
      org.jboss.ws.core.jaxrpc
      org.jboss.ws.core.jaxws
      org.jboss.ws.core.jbossxb
      org.jboss.ws.core.metadata
      org.jboss.ws.core.server
      org.jboss.ws.core.soap
      
      org.jboss.ws.extras
      org.jboss.ws.extras.addressing
      org.jboss.ws.extras.eventing
      org.jboss.ws.extras.policy
      org.jboss.ws.extras.security
      org.jboss.ws.extras.xop
      
      org.jboss.ws.integration
      org.jboss.ws.integration.jboss40
      org.jboss.ws.integration.jboss50
      org.jboss.ws.integration.tomcat
      
      org.jboss.ws.tools
      


      Further refactoring would be necessary such that

      * core only has a dependency on common, so has tools.
      * core does not have a dependency on tools.

      When this is done, we move common and tools in their respective modules that then can be reused accross branches. Shortly we will have a third branch to maintain jbossws-1.2, wich is targeted for jboss-4.2.x. This can only be done efficiently if the code bases do not divert more than necessary.



        • 1. Re: Proposed new package structure
          jason.greene

          Are you referring to using the same tools and common binary across branches? I don't think we should go this route because tools changes often impact metadata, tools, and common/core. Therefore if we did this we would surely end up maintaining multiple versions of binary dependencies which is just as much if not more work (since you would need branches for each subcomponent).

          The only diversion that I think is necessary for 4.2 is a couple of configuration lines for remoting. IMO as long as this is true, I think it would be better just to add code that detects which version of remoting, and then configures appropriately across all versions.

          • 2. Re: Proposed new package structure
            heiko.braun

            Here are my 2 cents:

            - What's the difference between org.jboss.ws.common.metadata and org.jboss.ws.core.metadata?

            - I would rename 'extras' to 'extensions'

            - As a general approach i would recommend to use *.jaxrpc *.jaxws subpackages.
            I.e. there would be *.xop.jaxrpc and *.xop.jaxws

            - As a consequence of the above, we should have org.jboss.ws.core.j2ee.jaxrpc and org.jboss.ws.core.j2ee.jaxws

            • 3. Re: Proposed new package structure
              thomas.diesler

              Before we decide on implementation details, lets have a look at the current sittuation with respect to tools/metadata. Please step back a little and look at it from a consultants perspective whose only aim it is to make it better in the future - what happend in the past is not of interrest.


              * jbossws-2.0.x is a functional superset of jbossws-1.2.x and jbossws-1.0.x. There is however a conflicting implementation with respect to how JSR181 endpoints are handled.

              * currently we have two (in the near future three) code bases
              that are divergent to a degree where it becomes virtualy impossible to merge changes from branch to trunk and vice versa. Effectivly, team members spend days merging trivial functionality or don't do it at all (which is worse)

              * the tools code base in branch has virtually not been maintained for the largest part of the year it is also in a state where it is still difficult to maintain

              * the tools code base in trunk builds on the tools code base from branch, such that maintainability concerns apply likewise

              * there is no tools api that can be used from core and thirdparty


              Therefore, I'll put some effort in


              * unify the metadata model accross branches
              * reuse a single tools code base accross branches
              * draft a tools api


              I see this as necessary prerequisity before I continue with CTS work and the foundation for 1.0.5, 1.2.0

              • 4. Re: Proposed new package structure
                thomas.diesler

                 


                Therefore if we did this we would surely end up maintaining multiple versions of binary dependencies which is just as much if not more work (since you would need branches for each subcomponent).


                Only if the changes are not backward compatible, which they should be given that trunk is a superset in functionality.

                Looking at it from a different angle, there is no way we would be able to maintain the current largely divereged code base. Therefore it is a MUST that we consolidate.



                • 5. Re: Proposed new package structure
                  jason.greene

                  Lest look at the actual real problem, which is the need for a legacy jsr181 implementation. We could even have this legacy implementation in the trunk codebase if desired, but disabled. This can be achieved by simply having a metadata builder that exists in the branch that does not exist in trunk. If we want 1 codebase, all that is needed is to sync trunk with the jbossws-1.0 branch and whenever a change is made it is committed to trunk first, and then after committed to the 1.0 branch. The code bases would be virtually identical, and by merging in this order we guarantee that 1.0 specific stuff remains.

                  The contract between what you call core, and what you call tools is NOT static, but rather changes significantly. In fact, it is a work in progress. For an example take a look at WSDLMetaData, this is by no means complete or fully accurate, and if we solidify this to some kind of API, we are only going to make things more difficult by having to guarantee backwards compatibility across any particular branch of core.

                  I only see this effort as creating more work for us, and I don't see how it helps achieve any of the outstanding project goals.

                  • 6. Re: Proposed new package structure
                    jason.greene

                    Also, isn't the purpose of the integration API to support not only multiple containers, but also multiple versions of JBossAS?

                    I think this is the proper abstraction to use (rather than dividing our stack in the middle), and we can reduce our workload by not introducing new branches for every AS release, and instead just adding a new integration module.

                    • 7. Re: Proposed new package structure
                      thomas.diesler

                      I don't care about where the code lives. If we have virtually identiacal code in trunk and branch(es) thats fine with me. This is the methodology that we use for the jaxrpc testsuite.

                      Consolidation is my concern. If we do not consolidate the tools,metadata, raxrpc codebase to a degree where I can more or less brainlessly merge stuff, I don't see a chance (for myself) to get future releases off the ground in a timely manner.

                      The UMDM might be in flux it is still part of the contract. The curernt issue is that we have multiple code bases that work off diffent UMDMs which is unneccessary and MUST be fixed.

                      Lets, take this discussion off-line - this will be more productive.
                      The aim is to decide upon a clear migration path towards a maintainable code base, which we currently do not have.

                      • 8. Re: Proposed new package structure
                        thomas.diesler

                        We agreed on the following plan

                        1) Thomas commits changes to package structure in trunk
                        2) Jason synchronises meta data and tools code base accross branches
                        3) for now, there will be no seperate module
                        4) after CTS completion we get together for a tools/core design session that should produce a migration path towards a better maintainable tools code base