I am trying to deploy a version of Eclipse and would like control over the default repository list. See my earlier question.
In my other question, I learned that this is stored in the user's home directory under ".eclipse\org.eclipse.platform_3.7.0_525061626\p2\org.eclipse.equinox.p2.engine\profileRegistry\epp.package.cpp.profile\.data\.settings\org.eclipse.equinox.p2.metadata.repository.prefs".
I would rather not deploy this file to a user specific location because there might already be one from another Eclipse installation and there could be more than one user account.
Is there any way that I can avoid the user profile?
I did find an equivelent file under the main Eclipse folder "eclipse\p2\org.eclipse.equinox.p2.engine\profileRegistry\epp.package.cpp.profile\.data\.settings\org.eclipse.equinox.p2.metadata.repository.prefs" but changing this didn't make any difference.
Thanks,
Alan
You can use p2 touchpoints and the p2 director to install your feature to customize the version of eclipse you are trying to deploy.
See p2.inf for an example of touchpoint configuration instructions that add p2 repositories to the default install. This one is part of an sdk.product generation. If you are starting with an eclipse that already has a product, your touchpoint instructions would have to remove the repositories that were already included and then add your own.
instructions.configure=\
addRepository(type:0,location:http${#58}//download.eclipse.org/eclipse/updates/3.8,name:The Eclipse Project Updates);\
addRepository(type:1,location:http${#58}//download.eclipse.org/eclipse/updates/3.8,name:The Eclipse Project Updates);\
addRepository(type:0,location:http${#58}//download.eclipse.org/releases/juno,name:Juno);\
addRepository(type:1,location:http${#58}//download.eclipse.org/releases/juno,name:Juno);
The way that I ended up doing this was to create a lightweight plugin that starts when Eclipse loads. This then programatically adds the update site as detailed here: https://stackoverflow.com/a/7384954/101642
Related
I am really new in buckminster.
I have just downloaded from our repository an Eclipse RCP project that needs a plugin update (placed in its Target Platform). We are currently using a remote target platform.
I have downloaded the remote target platform configuring its path in the targetplatform.source project, then I did the update and reload it checking the plugin's version. I have changed the version number in feature.xml on my targetplatform.feature project (that contains the buckminster.properties file).
The problem comes when I right-click on the targetplatform.feature project, select Buckminster > Invoke action... > site.p2. This just rise an error and the console shows the Buckminster log with the same error:
java.lang.IllegalArgumentException: case variants of key: awt.toolkit: case variants of key: awt.toolkit
Thanks in advance!
Best regards,
I finally had to stop using a remote target platform as I could not solve the Buckminster problem. The workaround described below covered my plugin update needs.
In order to have a control version system, the plugin update problem can be managed by having a repository manager (for example Nexus). Then you can simply upload a zip of your target platform with the updated plugins. Nevertheless, this forces the configuration to set the target platfom as local and therefore you need to download and unzip it previously.
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 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 .
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.