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.
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.
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). So, the tip is, don't use -clean routinely (as I used to do) but only if you know you really need it. This should be fixed eventually. (But in fact, we had to remove -clean from all our JUnit tests ... or, else they could not complete in a reasonable amount of time. See bug 224269).
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. These bugs all had to do with making incorrect assumptions about the locations of where things were installed.
One bug was some old pre-osgi-bundle code (that had been copied several places) assumed some things about the name and length of the "eclipse/plugins" directory. 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.
If you just really can't make it work and its interfering with your own development (then, after opening a bug saying so :) ... or, you just want to do some tests comparing the old with the new ... then there is a way to disable P2. See Equinox p2 Removal. I think only the first three steps listed there are required. Of course, this should be a separate install than your P2 attempts, everything unzipped where it used to be, and backups of replaced files kept.
I should also warn, that as far as I know, running in this disabled mode has not been extensively tested, though in theory it should all work just fine.
- Replace the eclipse/configuration/config.ini file with the contents from Eclipse platform version 3.3.2.
- Replace the eclipse/eclipse.ini file with the contents from Eclipse platform version 3.3.2.
If you have none handy, you can try unzipping this zip file (File:NOP2config.zip) that has the above two files laid out to over write those two config and ini files.
- Remove the platform.xml from eclipse/configuration/org.eclipse.update/platform.xml. (to force re-discovery).