| Summary: | org.eclipse.hyades.test.core plugin has dependency on org.eclipse.hyades.trace.ui | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Joe Toomey <jptoomey> |
| Component: | TPTP | Assignee: | DuWayne Morris <dmorris> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | P1 | CC: | nssheth, paulslau, summerns |
| Version: | unspecified | Keywords: | plan |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | 162475 | ||
| Bug Blocks: | |||
|
Description
Joe Toomey
Joe, please assign a sizing to this defect. This bug is critical for our ship and test of our product. We are shipping IES 3.2.2 which contains the version of TPTP with the problem. Would it be possible to modify the plugins on our side since this fix will not be ready in time? Could we patch the org.eclipse.hyades.test.core plugin to make the org.eclipse.hyades.trace.ui dependency optional and then not include the org.eclipse.hyades.trace.ui plugin in our stack? Would this cause any problems with TPTP? We will get a DOU exception for this is acceptable. If it is, would you please provide the correct steps to make the dependency optional? I just reviewed the plugin XML and there is not a dependency for the trace.ui component. Is there some other place this is being referenced? Hi Summer, Depending on the needs of your consuming application, patching TPTP 4.2.2 yourself and marking this dependency as optional may be a good solution for you. If you do not require the Automatable Services Framework (which I believe is true, assuming you work on the same consuming product as Nirav), then marking this dependency as optional should not cause problems, although you'll obviously need to test your applixcation to validate this. You can mark the dependency as optional either by checking the checkbox in the dependency's properties dialog (from the manifest editor), or by directly editing the manifest.mf file: org.eclipse.hyades.trace.ui;bundle-version="[4.2.0,5.0.0)";resolution:=optional, Joe, Is that the only thing we need to do, or do we need to comment some code out so we don't run into any issues with classes being not found. If your application doesn't use ASF (which I believe is true for your RCP application), then declaring the dependency as optional is all you need to do. If it does use ASF, then I expect that the change would be much more invasive, requiring you to predict code paths covered, check bundle activations, etc. Were that the case, I wouldn't suggest going this route. But the code path that would try to activate this bundle won't be traversed if you don't use ASF, so you should be in good shape. I just looked at the code further, and it's possible that it will be more involved than I had hoped. There appears to be code that uses ASF on the basic Node.connect code path (which you definitely use.) There is error handling code to attempt connecting the old way if the ASF call fails, so perhaps you will still be okay. Please let me know how the testing goes. We tested making the dependency on org.eclipse.hyades.trace.ui optional and it removed many of the additional plugins we had to include. One additional question: Could we make org.eclipse.search an optiona dependent of org.eclipse.hyades.test.ui? If not, the following plugins are still required:(Still seems excessive) org.apache.commons_logging_1.0.4.v200606131651 org.apache.jakarta_log4j_1.2.8.v200606131651 org.eclipse.debug.core_3.2.1.v20060823.jar org.eclipse.jdt.launching_3.2.2.r322_v20061114.jar org.eclipse.pde.build_3.2.1.r321_v20060823 org.eclipse.pde.core_3.2.1.v20060915-0800.jar org.eclipse.pde.runtime_3.2.0.v20060605.jar org.eclipse.pde_3.2.1.v20060810-0800.jar org.eclipse.search_3.2.1.r321_v20060726.jar org.eclipse.team.core_3.2.2.M20061114.jar org.eclipse.update.core_3.2.3.R32x_v20070118.jar Hi Summer. Did you get the note I sent you last week in response to this question? Here is that response: Hi Summer, You can file a TPTP bugzilla request to have this dependency made optional in TPTP itself. I suggest that this is the right first step, since you don't want to require DOU exceptions every release. I spoke to Bianca (who wrote the code), and she thinks that if you don't use the Test Log Viewer in your RCP app (which I believe you don't) then you may be able to make this dependency optional. We don't see a red flag to tell us that it won't work, however, there is no substitute for testing this. Assigning target. After investigating further and briefly consulting with Joe Toomey, it looked like there was no remaining reason in the recent code base for a dependency on org.eclipse.hyades.trace.ui in org.eclipse.hyades.test.core, as also verified by running manual tests, Auto GUI tests, and JUnit tests with this dependency removed. I later realized after refreshing my CVS files that Paul had fixed this problem (perhaps inadvertently) on April 16, 2007, by removing several unreferenced dependencies in bugilla 163173. Thanks Paul! I picked up the build from 04-23 with Paul's changes and again verified that our tests run properly. Marking as verified per the above note where I tested on the 04-23 build. The Platform defect listed as a dependency of this one is really a separate issue and should be resolved separately. Closing. |