Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
WTP/What we have learned (to love) about P2
Well, the "love" part might be premature :) but are confident we'll end up there.
This page is a central place to document some notes about what we in WTP have learned about P2, which bugs effect us, little "tricks", etc. Warning: this is a fast evolving area, due to bugs, miscommunication, and ignorance, so take these notes as hints ... nothing is forever ... and update this page as you find more information or errors in the information here.
Contents
Intro
In theory, shouldn't effect you at all. You could or should be able to do things as always, except there might be some bugs, and there are reasons to try to make use of it. One reason is to help the platform find bugs early so they get fixed by their release. Closer to home ... help find bugs in _our_ code that only show up in the conditions encouraged by P2.
Ever wonder what P2 stands for? As best I can tell "Provisioning Platform" (I think I know why they did not want to call it PP ). We in WTP won't be taking advantage of the platform aspects of it directly (that is, not using their APIs) but its my understanding that the EPP Project will be making their "all in one" installs using P2, which should be much better then the old Update Manager.
Running WTP
Here's one way to create a running version of WTP. Unzip the Eclipse SDK in some directory, say /M6. You'll see the familiar directories, eclipse/plugins and eclipse/features but some new ones too ... the main new one is an empty directory called eclipse/dropins. This is by design the place to "drop in" other zip files or plugins that are not installed via the P2 User Interface.
I unzip wtp-sdk and all our pre-reqs into separate subdirectories, such as wtp, emf, xsd, gef, dtp, relengtool, testFramework. So ... you end up with a hierarchy similar to
/M6/eclipse /M6/plugins /M6/features /M6/dropins /M6/dropins/wtp /M6/dropins/emf /M6/dropins/xsd /M6/dropins/.... etc. And, each of those subdirectories end up looking as they did before ... for example, /M6/dropins/wtp /M6/dropins/wtp/eclipse /M6/dropins/wtp/eclipse/plugins /M6/dropins/wtp/eclipse/features
Now, start eclipse like you usually would. You should have a fully functioning WTP.
This structure has the advantage that it _should_ be easier to update pieces of your install, say just with a new WTP build, without touching the rest of it.
Tip: The first time you start, it'll take a lot longer than it used to. See bug 224579. But, subsequent restarts should be as fast or faster -- as long as you do not use -clean (-clean clears the timestamp cache and it goes through the whole re-discover process again).
Self Hosting WTP Development
With the above install, you can use the plugins you normally develop and commit and it will "compile and run against" that version you are self hosting on. (If trouble, go to PDE Preferences, Target Platform, and press "reset" (not reload). Check on "show by location" and you should see all your sub-directories in dropins. (If not, open a bug, or comment in this instructions, or both).
I think there are issues with running against a completely different target, installed in a different directory (see bug 225148). Even that can be worked around by "running" the target, so all the meta data is updated. But, check the bug ... that may change with more information. Maybe it's just me. :) Or, update the bug if you find out more!
Bugs we've discovered in our code due to P2
My guess is others have similar bugs, so hopefully other projects and adopters can learn from us. This bugs all had to do with making incorrect assumptions about they locations of where things were installed.
One was some old pre-bundle code that had been copied several places, where we were making some incorrect assumptions about the locations of plugins. These were easy to fix using the correct APIs. See bug 224148.
We have some code which makes assumptions about location of where features are installed. It currently works with P2, but we should never assume anything about features, and may eventually look if there's some P2 API way of accomplishing the update that is being done. See bug 224441.