Community
Participate
Working Groups
Currently the target platform is saved as preferences. In 3.5 the new target story adds in additional information to find and load target definitions, but the definitions still needed to be stored as preferences to be used. In 3.6 we will look at eliminating these preferences. Instead we will create a target model based on a target definition. This model provides all the information that the preferences did and more. This is a required step for multiple target platforms per workspace (bug 159072). It will simplify the code and allow much greater flexibility in how the active target platform is created. There is a risk that people are setting these preference manually, which will be broken. However the preferences are internal and we will try to continue to migrate people from preference settings to target definitions.
+1, this is in the right direction
Planned for M2.
Concentrating on bug 287619 first.
Removing milestone. Bug 287619 isn't getting fixed for 3.6. The work for that bug in the target_api_changes branch deprecates a number of preferences.
Doesn't look like this will happen anytime soon. It is a large and risky change.
Marking for consideration in 4.4. If we are changing the model creation code to remove support for pre-osgi plug-ins (Bug 407765), it would be a good time to look at removing the use of preferences.
Similar to API tools bug 405494 we also want to be able to recognize when target content changes on disk.
There is a new tracing option org.eclipse.pde.core/model which outputs the time taken to initialize the models (Bug 412795). Mike, please turn this option on and let me know what kind of numbers you are getting. The first part of the changeover will probably hurt performance as we'll be loading the manifest content twice. When we can avoid the duplication, we can see what the performance impact is.
The performance hit has not been as significant as I expected, no more than a second or two. p2 targets were very painful, but this was because they marked themselves as dirty on startup, causing the cached profile to be skipped and remote repositories pinged. Correcting this problem reduces the performance hit on p2 targets to < 100ms. We can still look at ways to avoid reading the manifests more than once. There is also a performance gain when interacting with the target platform (target pref page, export target, etc.) as the target will already be resolved. If we make access to the active target be API, we should consider how bug 392652 will be affected.
http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=b2c8660a932ffcbd66beb832b8869be53bd62099 Pushed major changes to master. Assuming this doesn't cause any regressions I will mark this bug as fixed and open new enhancement requests. More details on what I changed and what I plan to change are available on a wiki: http://wiki.eclipse.org/PDE/4.4TargetChanges
download.eclipse.org/eclipse/downloads/drops4/I20130829-2000/testresults/html/org.eclipse.pde.ui.tests_win32.win32.x86_7.0.html 46 failures that definitely are related to this change. All the tests pass locally. Which could indicate we aren't handling the transition of of old preferences correctly.
(In reply to comment #11) > download.eclipse.org/eclipse/downloads/drops4/I20130829-2000/testresults/ > html/org.eclipse.pde.ui.tests_win32.win32.x86_7.0.html > 46 failures that definitely are related to this change. All the tests pass > locally. Which could indicate we aren't handling the transition of of old > preferences correctly. p2 also had a lot of test failures because of jar signer issues (they show up in our logs as well). I noticed though that some of the IUBundleContainer tests do not reset the target platform back to the default if they fail an assertion. Seems likely that the signing issue caused one test to fail but the target platform was never reset. http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=3459823e88634531c365ce2be53d8d27b2d235e3
With the test fix, only IUBundleContainerTests are failing which mirror problems in the p2 tests. Marking this bug as fixed. I will open new bugs for additional work items as specified on the wiki.
*** Bug 284875 has been marked as a duplicate of this bug. ***
Curtis, I believe the last commit caused a regression with resolution of target platforms. Please see bug 439011.
