Community
Participate
Working Groups
Build Identifier: eclipse 3.7 The JSDI enhancements made in the 3.7 stream is extremely valuable to adopter products that are still on 3.6 and will stay on 3.6 for a while. Reproducible: Always
(In reply to comment #0) > Build Identifier: eclipse 3.7 > > The JSDI enhancements made in the 3.7 stream is extremely valuable to adopter > products that are still on 3.6 and will stay on 3.6 for a while. Which ones in particular are looking to have back-ported? There was quite a lot of work done between 3.2 and 3.3 (where 3.2 -> 3.6, 3.3 -> 3.7 and 3.4 -> 3.8).
Michael, I don't know a whole lot of details of all the enhancements made in 3.7, but I was thinking the crossfire protocol support that allows cross browser remote debugging. can you give some details on what other enhancements there are? thanks.
(In reply to comment #2) > Michael, I don't know a whole lot of details of all the enhancements made in > 3.7, but I was thinking the crossfire protocol support that allows cross > browser remote debugging. The crossfire support is currently in the development stage and is not part of any JSDT release - so you can have that anytime you want :) > can you give some details on what other enhancements > there are? thanks. 1. We added a Rhino UI bundle 2. made huge improvements to our source look-up story 3. added a ResumeEvent / ResumeRequest to the JSDI API 4. added createResumeRequest / resumeRequests methods to the JSDI EventRequestManager API 5. Single-click Rhino launching 6. tonnes of other bug fixes...
Created attachment 202822 [details] wst.jsdt.debug.core This patch is the backport for org.eclipse.wst.jsdt.debug.core
Created attachment 202824 [details] jsdt.debug.transport Path for the backport of org.eclipse.wst.jsdt.debug.transport
Created attachment 202827 [details] jsdt.debug.ui The backport for org.eclipse.wst.jsdt.debug.ui
Created attachment 202844 [details] patch Here is all of the other back-ports rolled into one with updated bundle versions and the Crossfire bundle included.
Nitin, Grant, please review.
Tried the comment 7 patch applied to the R3_2_maintenance stream, it seems fine. I didn't review the code itself, but verified that when used with the IE server that it works equivalently to HEAD.
committed the last patch to 3.2 maintenance.
*Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. It's plainly requested by an adopter, even though not marked as such, but it also fixes some rough spots in the debugging support as provided in 3.2.x so far, particularly "Single-click Rhino launching" (previously you had to launch Rhino as a Java Application and instruct it to listen on a port with precisely the right arguments, which you would then have to match with your JS Debug launcher). *Is there a work-around? If so, why do you believe the work-around is insufficient? No workaround, as the API additions allowing us to debug across other browsers are new. *How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Manual testing. *Give a brief technical overview. Who has reviewed this fix? Grant and I have reviewed it. It's very much bringing the 3.2.x JSDT Debug component in alignment with what we have in the 3.4 and 3.3 maintenance branch (changes in R_3_3_maintenance are not yet released due to the SR1 shutdown). It does, however, add the new org.eclipse.wst.jsdt.debug.rhino.ui and org.eclipse.wst.jsdt.debug.crossfire bundles to 3.2.5. *What is the risk associated with this fix? Medium. New bundles are introduced to the build itself, but we're hoping that by getting it in this week, we have ample time to test and find any unforeseen issues before we get to PMC mode. I would also appreciate guidance on how to handle the version numbering with the API additions in the maintenance branch--update just the micro to minimize range-based breakage, or properly update the minor versions?
I have discussed these changes with Nitin, and understand his reason's, although I am concerned over the timing, Nitin is committed to seeing these changes don't affect the build or other components. I approve
I think this enhancement is ok and will be appreciated by the community. I think, especially given the tight timing, a service field increment is best ... "the less of all evils". In the future, if there's something substantially added, it'd be best to have a sub-project release review to avoid all doubt about if a release review was required or not, but in discussing with the PMC we feel that this addition does fall within being an enhancement, rather than "a completely new feature" to we will not require a release review. Since this is specifically about Helios extended maintenance, a note to wtp-dev should suffice, notifying adopters and asking if there's any concerns. Later, when in Indigo SR2, a similar note to cross-project list would be in order. Thanks for the enhancement! I'm sure the community will greatly appreciate it.
Released
