After searching around I see that eclipse 3.4/3.5 now allow you to use their 'dropin' folder to manually install plugins.
This works well in a situation where you have already downloaded the feature and plugin files, however in cases where you use the Software Updates feature to simply point to a URL and download a plugin, you don't appear to have control over what folder the plugin is installed into.
Is it possible to force plugins to be installed to an arbitrary dropin folder, or otherwise export a plugin to a location so that it can be shared with other people's eclipse installations?
I'd prefer not to have to comb through the plugin info and manually determine which plugin jars to copy into a dropin folder :P
Thanks
I think the answer in this thread and the mentioned blog post of Michael Scharf can be useful for you, although the procedure is not as simple as it should be :(
The new p2 system in 3.4 is supposed to have a feature called bundle pooling that allows for shared plugins. However, I haven't used it, so I'm not sure about the particulars. I hope this at least points you in the right direction.
When using 3.4.1 you can still enable the "old" update manager in Preferences/ General/ Capabilities. Then you can use the extension points again. But it has been removed in 3.4.2 completely.
You have to remove P2 to get the old update manager.
Note: The P2 team managed to broke everything backward compatible. This tricks does not work with 3.5.
Related
Is it possible to create an Eclipse installation package, that contains a bunch of bundles and plugins? If so, how? (Like the ones that are already being offered by Eclipse.org and also from different vendors with their own projects)
The reason I am asking is, that I find it very time-consuming to install a bunch of software into development environment every time I need a clean installation of Eclipse (based on various reasons, corruptions etc.).
So I would like to install all the software I need at once, and save it somewhere else before working with it (as a backup) and if something goes wrong I can install the entire base installation again without being have to handle all the extra software in it.
Thanks!
Eclipse is downloadable as a zip or tar file, so you can dezip it in a folder, add your favorites plugins (their will be store in the eclipse folder in plugins subfolder) and create a new archive with your modified environment (your eclipse folder).
I think It's the simple way to create a backup.
I hope it may help you,
Have a nice day
One option is to use Yoxos, which allows you to create your own package of Eclipse and easily share it (including with yourself).
I have an update site that contains some 100 - 200 features and many more plugins. For some users all of these are needed, so I'd like to simplify the installation process by creating one feature that they can install. This feature would then contain all the contents of the update site.
I've created a new feature project and my plan is to add the contents of the original update site as included features and plugins in this project.
Problems is; In my feature project, when adding feature in the "included features" tab, I can only add features that are currently installed in my Eclipse platform. I'd rather not install those 200 features just so I can add them.
Is there a way to work around this?
Without the features installed in your target platform, you will need to edit the feature.xml file directly. All you need to do is to add the following for each feature that you want to include:
<includes
id="<add_feature_id>"
version="0.0.0"/>
Your build process (PDE or tycho) should add the proper version numbers for you.
I think you should have a detailed look at the Eclipse target platform concept. The features don't need to be installed in your current Eclipse platform (i.e. the IDE), they need to be installed in the target platform to be available for an update site.
If you never defined a target platform, your currently running application will be taken as IDE, and that is where your confusion might come from.
When I try to manipulate a feature I only need to have them in my workspace. No reason to install them.
I use the google plugin for eclipse with GWT and Appengine libraries. Every so often I upgrade one of the libraries, which currently involves:
I install the update somewhere on my HD
I add the update as an alternative SDK in eclipse, with a generic name
I update the project settings to point to the new generic name
I commit the changed settings files (which do NOT include the upgraded library) to our source control
The problem here are in unfortunate steps 5-7:
5 Everyone else's builds stop working past the change,
6 I go from machine to machine, repeating steps 1 and 2, and
7 I think for the nth time, "I should really find a way to automate this."
I'm here for the elusive step 8: Actually automating this. I want to include the SDK in my source control, so when I switch between versions or set up shop on a new machine, the relevant SDKs are automatically installed and downloaded. I don't want to have to configure eclipse settings at all. In my ideal situation, I am willing to install Eclipse and the GPE on each machine, but after that I just want to clone my repository and go.
I've tried doing this by removing the GWT library from my build settings, copying the entire GWT installation folder into the root of my project, and adding gwt-user.jar and gwt-dev.jar to the build path from there. This almost works, but eclipse complains that it can't find gwt-servlet.jar (even though it exists precisely where it claims to be looking for it!). There also seem to be other magical settings I don't understand.
Finally, the question: If this is the right track, what settings do I need to manually control? If this is the wrong track, what's the right one?
+1 good question. This may or may not answer your question, but I can share with you what I do. I also work with GAE and GWT.
I just include the SDK .tar/.zip files in my repository, remove the version numbers from the filename, and update it when I want to move to a new version. If that version migration fails, I can easily revert to the old SDKs. I also use GXT and a bunch of other GWT extensions, so my problem is even worse than yours. I don't use eclipse for GAE nor GWT, so I can't relate to the problems you are having there. If you don't want to have to configure eclipse every time, then don't use eclipse.
Disclaimer: I hate eclipse.
I want to create an automated installer for an Eclipse plugin (i.e. not through the "Update Manager"). My scenario is simple: the user closes Eclipse, drops a downloaded JAR into the dropins folder, starts Eclipse and the rest of the process is automated.
In older Eclipse versions, before the era of P2, Eclipse had (still has) a class called InstallCommand which could be used to install pluings into the currently running platform.
While this still works in Eclipse 3.4 & 3.5, it is not behaving properly: most noticeably, plugins installed that way cannot be automatically uninstalled (it is dimmed).
The JavaDoc claims the InstallCommand is deprecated and should be replaced by a P2 alternative. However, I couldn't find the right tool for the job. There is the P2 director, but it is built for running as a separate application from the command line. It is possible to invoke it from within Eclipse but it is really not cut out for that. For example, progress monitoring and error reporting are not working well.
Does anybody know of a good alternative for that?
Thanks,
Zviki
Dropins seems very close to what you want, especially if they are just downloading jars without the associated metadata (ie the metadata will need to be auto-generated).
You could consider defining a second dropins area to manage yourself. Take a look at ProfileSynchronizer in org.eclipse.equinox.p2.reconciler.dropins, in particular the method createProfileChangeRequest. I expect the uninstall behaviour you don't like is a result of the IInstallableUnit.PROP_PROFILE_LOCKED_IU property being added.
The dropins are reconciled at startup, see the p2.reconciler.dropins Activator.watchDropins(), you can likely do the same from your own bundle to watch another folder.
I suggest to deploy your plugin as an executable JAR. The installer in the JAR should ask for the Eclipse install directory and unpack the plugin in the right place (plus some more checks as needed).
Optionally include a little "watchdog" plugin which doesn't depend on much and just checks that your main plugin loads correctly and displays a useful error message which the user can email to you for support.
According to information in bug 311590 1 which is referenced in the deprecation comment of InstallCommand an alternative is possibly to use P2 operations 2, 3.
I downloaded the source code for the EMF based UML2 Plugin and changed a class in the org.eclipse.uml2.uml.edit project to remove special characters when returning string representations. Now when I export the projects and place the jar files either in the dropins directory or replace my current uml2 plugin jar files in plugins directory, The UML files are no longer recognized, in short my modified plugin does not install correctly (no error is thrown and I can see the files being picked up under Plugins->Target Platform) .
However, When I run the plugin as an eclipse application (from the workspace) I can see the changes I made being reflected in the new instance of eclipse.
What can I do to ensure that the plugin installs correctly?
Is there a documented procedure of how to build the uml2 plugin (or any comparable plugin) after modification?
Select the project and open the context menu. There is an entry PDE near the bottom of the menu. In there, you can find an entry to build the plugin for deployment. This gives you the features and plugins directory with the fixed files. Copy both into your Eclipse install.
Unless the UML2 plugins require some kind of magic build script, exporting the one plugin you changed and overwriting the original in your Eclipse installation should be the easiest solution. One potential problem which comes to mind is conflicting plugin version numbers: make sure you don't have two identical versions of your modified plugin in your Eclipse installation.
When debugging plugins which apparently don't work properly at runtime, I always look at Help > About Eclipse Platform > Configuration Details. This lists all the plugins found by Equinox during startup, along with their status (see the Javadoc of the org.osgi.framework.Bundle interface for explanation).
I faced the exact same problem as you describe here . I dont have any answer to your problem but i am sharing what worked for me .
I created a local update site of the plugin on my system. Create update site for your plug-in article explains very very nicely the steps needed to accomplish this .