6 Replies Latest reply on Jan 16, 2006 4:44 PM by aloubyansky

    Resolving XB conflicts in Branch_4_0 and HEAD

    aloubyansky

      JIRA issue:
      investigate conflicts between XB versions in Branch_4_0 and HEAD
      http://jira.jboss.org/jira/browse/JBXB-45


      Would it be ok to update users of XB in Branch_4_0 to use the new API starting from 4.0.4? And then remove XB code from Branch_4_0 and use the binary from HEAD.
      I know Scott is not happy with the package name org.jboss.xb.binding.sunday, so at this point we could also change the package name.

      If so, in HEAD, I would change the package preserving the impl in sunday package and making it as a wrapper of the impl in the new package. I could also review the public API once again.

        • 1. Re: Resolving XB conflicts in Branch_4_0 and HEAD
          starksm64

          Its ok once the scope of the incompatibilities with 4.0.3 are fully resolved. So far the only server integration usecase I have found a problem with is the MBeanServerUnitTestCase creating a local SchemaBindingResolver.

          • 2. Re: Resolving XB conflicts in Branch_4_0 and HEAD
            aloubyansky

            What about other API conflicts that I found? You don't consider them to be integration issues?

            May I assume I know all the users?

            Is the problem in making sure that code that could run in 4.0.3 still can run in 4.0.4 and later?
            Is it ok if code developed in 4.0.4 and later does not run in 4.0.3?

            BTW, in any case, making projects that use jboss-xml-binding.jar from HEAD run in versions below 4.0.4 is a problem because one would need to at least remove binding classes from jboss-common.jar first (assuming API incompatibilities are resolved).

            • 3. Re: Resolving XB conflicts in Branch_4_0 and HEAD
              starksm64

              The big issue is that existing binding configurations continue to work without modification. The biggest potential concern in the api change would be the GenericValueContainer changes since this is needed for some bindings and users might be using this.

              Code developed in 4.0.4 does not have to run in earlier versions, so that is not a concern.

              Refactoring the jbossxb classes and getting to a stable release we can rely on in 4.x, 5.x, mc, etc has to be the priority. If any of the current api incompabilities can be fixed, let's do it, otherwise we'll have to live with the issues and document them.

              Going forward the api compatibility in the minor releases needs to be maintained.

              • 4. Re: Resolving XB conflicts in Branch_4_0 and HEAD
                aloubyansky

                 

                "scott.stark@jboss.org" wrote:
                The biggest potential concern in the api change would be the GenericValueContainer changes since this is needed for some bindings and users might be using this.


                As the search shows, in JBoss-4.0.4 the users of GenericValueContainer are in the security module only and those classes are not a public API. There shouldn't other users since the project has not been released yet.

                "scott.stark@jboss.org" wrote:
                If any of the current api incompabilities can be fixed, let's do it, otherwise we'll have to live with the issues and document them.


                If the signature of a method changed in a class or interface then how could it be fixed?
                I think only by rolling back the change, moving new impl to a new package updating all the users to use the new package. In this case what about projects that use current API in HEAD and had RC/releases, e.g MC?

                • 5. Re: Resolving XB conflicts in Branch_4_0 and HEAD
                  starksm64

                  The only way it could be fixed is if the change was an introducution of a new method(s) that could be factored into a subinterface.

                  • 6. Re: Resolving XB conflicts in Branch_4_0 and HEAD
                    aloubyansky

                    This could be done for GenericValueContainer. Other conflicts, e.g. XsdBinder.bind(), SchemaBindingResolver, are changes of signatures.