5 Replies Latest reply on Jun 16, 2005 11:02 PM by Tom Elrod

    For some reason jms is using an incompatible jboss-remoting.

    Ovidiu Feodorov Master

       


      revision 1.14
      date: 2005/06/15 21:45:33; author: adrian; state: Exp; lines: +1 -1
      Fix the eclipse build.

      For some reason jms is using an incompatible jboss-remoting.jar?


      src/resources/jboss-remoting.jar contains fixes that haven't made it yet into jboss-head/thirdparty/jboss/remoting. It's built from the JBossRemoting head.

      Why are you saying it's incompatible?

      If you know a better way to manage this, please let me know.

      I am not using eclipse, but shouldn't .classpath and .project be private to everybody?

        • 1. Re: For some reason jms is using an incompatible jboss-remot
          Adrian Brock Master

          It is incompatible because jms won't compile with the currently integrated JBoss
          remoting version. I'm assuming you didn't put in the thirdparty because
          then you break the rest of JBoss? Or are you just leaving this testing to somebody
          else?

          • 2. Re: For some reason jms is using an incompatible jboss-remot
            Ovidiu Feodorov Master

             

            It is incompatible because jms won't compile with the currently integrated JBoss remoting version.


            This is correct. JBoss Remoting head contains API changes and I have chosen to go with the head, since this is where I fix the issues I encounter.

            I'm assuming you didn't put in the thirdparty because
            then you break the rest of JBoss?


            Probably yes, the remoting head will break the rest of JBoss. But putting something remoting in thirdparty is not my decision to make. It belongs to the remoting project lead.

            What I could have done differently is to fix bugs on stable branches instead of the head. Then, if I wanted them on head, it would have been my own responsibility to port them there. However, this is overhead I cannot afford right now, unless somebody else does Messaging.

            If the fixes are desirable, the remoting project lead will decide whether to back port them on stable versions. What I do is document all of them, e.g:
            http://jira.jboss.com/jira/browse/JBREM-137
            http://jira.jboss.com/jira/browse/JBREM-106
            http://jira.jboss.com/jira/browse/JBREM-92

            Or are you just leaving this testing to somebody else?


            Partially yes. If I notice that a fix I introduced breaks the remoting testsuite, while allowing me to go forward, I make a note of it, I create a remoting test that guarantees the functionality I want and I go forward.

            • 3. Re: For some reason jms is using an incompatible jboss-remot
              Tom Elrod Master

              So I am a little unclear to the inital problem. You mean that jboss-head/build/build.xml does not build or that the jms project itself does not build? If the answer is not yes to either of these, then this is not something I am concerned about.

              The reason being that I will replace the jboss-remoting.jar in thirdparty with the new 1.2.0 release (which should be end of next week). This shoudl get all the projects in sync with the latest release (at which time I will go through all the projects and work on any incompatabilities due to any API changes).

              After this, there is the issue of how and how often the jboss-remoting.jar should be updated. At one point, I was thinking could have the new jboss build do this via updating from snapshot from nightly build. Since after 1.2.0 release, I don't think the API will change, it is not that big of a deal since wouldn't have to send out an e-mail every time I did a checking (but of course don't know when will be able to do this via new jboss build).

              • 4. Re: For some reason jms is using an incompatible jboss-remot
                Ovidiu Feodorov Master

                Tom,

                The Messaging head doesn't build with the current thirdparty jboss-remoting.jar. This is because I am using ServerInvocationHandler.getClientSessionId(), for example. This will be corrected as soon as you upgrade the thirdparty remoting to 1.2.0.

                It's OK anyway, I am managing this and anybody who uses the project's build.sh shouldn't have any problems.

                As for maintaining eclipse configuration files ... Adrian bumps into this every time he wants to do something with Messaging, so I guess I am covered there :)

                • 5. Re: For some reason jms is using an incompatible jboss-remot
                  Tom Elrod Master

                  Ok. We'll be to point where you can use the thirdparty jboss-remoting.jar soon, so am good with that.

                  As for eclipse configuration files, I couldn't care less. Is Adrian's choice to use it, so he can live with the consequences.