Woof! Mardy, thanks for clarifying the current situation. I was confused over all the versions of JAIN-SIP out there. This means the issues I'm tracking down are probably not due to JAIN-SIP versioning mismatches, as sipXpage is using the sipXcommons version at both compile and run time. Good, now I can look elsewhere for my troubles.
With Damian on vacation, I don't think it is an appropriate time to discuss the merits of RPM vs checked in jars, and I didn't mean to open that can of worms (I wasn't even aware I was doing so). I was honestly confused about what versions were being used by when. It appeared to me that the sipXcommons version was being used at compile time and the RPM version at run time. But one thing Mardy wrote needs to become part of the arguments when we do discuss this: > Developers and Release Engineering do not need to be aware of or > deal with satisfying third party package dependencies as they are > automatically included with the source code. There is no need to hunt > for RPM's or be concerned about version mismatch. I think this one nails it. I rarely update my system with "yum update", as it often means things break that used to work...due to packages I neither know or care about. It also means building an older version sometimes becomes impossible as I cannot keep two versions of RPMs on the same machine. VM's are great for this, but my main development environment isn't a VM I'm afraid. RPMs of C/C++ libraries keep the older version of the .so files around, so even if the library is updated older code can still find and use the old one. This is not the case with the JAIN-SIP RPM, and Java in general. There is no versioning system like ld.so to find the right version that was used at the time. Instead, if the changes aren't backwards compatable, it just fails. This is a strong argument to me that checked in jars are a safer, if less attractive, alternative. --Woof! _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
