Community
Participate
Working Groups
BugzillaSearchEngine and related tests use SUN JDK specific com.sun.org.apache.xerces... classes and do not compile using IBM JDK.
Was that the only compile problem that you saw? I should be able to fix it by moving to java.util.regex.
Yes, this was the only problem.
Created attachment 31895 [details] Partial attempt to move to java.util.regex.Pattern
Created attachment 31896 [details] Partial attempt to move to java.util.regex.Pattern
(please ignore the double attachement, I accidentally hit submit twice) I spent a little time trying to move to the java.util.regex package but there are a few differences and grossly insufficient test coverage here so it would be too distabailizing to do right now. Unfortuantely the tests pass with the attached partial move but queries fail, which means the first thing that needs to happen is increased test coverage (since this code is manually verified to work with 2.16, 2.18, and 2.20). Marking as helpwanted in case there are any regex gurus out there interested in tackling this one.
Created attachment 35478 [details] Functional java.util.regex patch Support for the IBM JDK is important for my day job, so I am providing here an updated version of Mik's proto-patch from comment 3 and comment 4. This removes references to internal Sun-only classes from BugzillaSearchEngine and RegularExpressionMatchTest. I have tested the changes under IBM and Sun JDKs(5.0.0), and against Bugzilla repositories of versions 2.20 and 2.18. I couldn't find a 2.16 against which to test. I am (coupled with my fix in bug 129459) now able to access Bugzilla repositories from Mylar in Eclipse 3.2M5 running from IBM JDK 5.0.0 without problems.
The change in visibility of 'RegularExpression re' from protected to public is no longer necessary -- my apologies. It should still be protected.
Created attachment 35491 [details] Improved patch This version fixes the protected/public oversight mentioned in comment 7, and also fixes a problem with a customised 2.16 Bugzilla that I've been trying to access. It does not cause Mylar to be able to access that 2.16 Bugzilla, but it does restore the behaviour of the unpatched version. Specifically, moving the 'matcher = null' assignment inside the 'do...while' fixes a potential IllegalStateException.
Thanks for these patches Ian! We now have additional unit tests that cover the supported versions of Bugzilla, so I plan on applying them today.
You're most welcome. It's purely enlightened self-interest :). I tried to do patches to get it working with the internal 2.16 Bugzilla that I mentioned (a different internal Bugzilla than the one mentioned in bug 129459), but I found it too difficult to ensure that I wasn't breaking anything. Are we even sure that the 2.16 Bugzilla integration works?! I can only find this one internal repository, and it does appear to have been customised in some way. Perhaps the improved tests to which you refer will enable me to be more sure. I also attempted a patch to make the Bugzilla version configuration per-repository instead of system wide (couldn't find a bug for that), but got hopelessly tangled up. I'm not a UI person :).
I applied the patch, and this looks great Ian, and is a valuable contribution since this has been lingering. Self-interest is always the best motivator, and we woudn't get anywhere if we didn't use Mylar ourselves :) Coincidentally we just fixed bug 123813, and bugzilla versions are now specified per-repository. So that's all set, and I don't blame you for punting on that patch because it was disruptive due to the weak architecture that's still dominant in the bugzilla stuff (we've been continually hardening an initial prototype that we inherited). Regarding 2.16, our new test harness will allow us to write search test against each live repository. This is bug 130217, and once that's done (probably today), it would be great if you could verify that HEAD works for everything you need (and submit more patches if it doesn't ;)
Verified as fixed in the 2006-03-03 builds.
