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

[ovidiu.feodorov]

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?

[adrian.brock]

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?

[ovidiu.feodorov]

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.

[tom.elrod]

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).

[ovidiu.feodorov]

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 :)

[tom.elrod]

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.