A few months ago, I wrote about using the p2 director to control where you install plugins & features.
Here's the other approach I mentioned in that article -- using the p2 Update UI and a little filesystem trickery.
- Use the p2 Update UI (Help > Software Updates... > Available Software) to install what you want. When prompted to restart, click No -- DO NOT RESTART OR APPLY CHANGES.
- Open a console window and run
./moveInstall.sh foo 10to move all plugins and features created in the last 10 minutes from ./plugins and ./features into ~/eclipse/eclipse-plugins-foo, then link them from ./dropins/foo.link.Note that the name, foo, is arbitrary -- it can represent the specific feature set you just installed (eg., "jet" for JET plus dependencies) or it could be something generic like "team", where I've got plugins for Mylyn, Tasktop, Subclipse, CVS, JIRA, and Bugzilla. You can also add/replace plugins & features in an existing folder by running the script again.
- Use the p2 Update UI (Help > Software Updates... > Revert Configuration) to revert the changes you just installed by selecting the timestamp of the configuration from BEFORE you installed the plugins & features in step 1.
Since you moved the files when Eclipse wasn't looking, it simply removes the p2 metadata, but can't delete the plugins and features.
- When prompted, restart Eclipse. On restart, the new plugins & features will be loaded.
Because the new plugins & features are not in the Eclipse root, you can now use those plugins with multiple versions of Eclipse -- just copy the foo.link file into another Eclipse's dropins/ folder.
This is perfect for testing milestone builds without having to reinstall everything each time.
Of course it's so easy to do this in shell script I have to wonder why p2 can't do it under the covers so we can get back the old functionality from Eclipse 3.3...
6 comments:
Great post Nick! Do you have the bug# for this request? I wonder how hard it would be to implement.
There are several bugs on it (like 225055, 230382, 230373 and 224145), as we are several who has tried to get the p2 team to give us our Extension Locations back.
But alas, it seems that they don't think we, the users, are able to handle this sort of flexibility and it is not how p2 is designed to work - apparently no matter what we say as users.
That's really good to know...
just coming a week too late when I decided not to worry anymore where p2 would update my plugins.
Another issue is what about the updated plugins? is there a p2 way to delete them? I personnaly went with a script to delete the 800+ (now) redundant plugins I had after a few month of updates.
If you let p2 install everything, then you can use it to uninstall everything too, followed by an install of the newer version.
But if you use my hack, then no. p2 can't manage plugins stored outside of a profile-driven location.
To properly manage shared install locations & bundle pools, I think you'll have to use the Director or the Installer.
More information here.
Patrick,
From what I understand, p2 should be able to get rid (garbage collect) unused bundles. However, I suspect there are a few bugs around this.
This will likely work for simple cases, but fail for more complex installs. For example if you install two "extras" in different locations, but they have a common prerequisite. Where will the prerequisite end up, and how will it be updated? If they have conflicting dependencies then the install may appear to work but fail at runtime.
Post a Comment