In my project we control the plug-ins through the "Manage Configuration" possibility.
Downloaded plu-ins etc. are loaded thorugh an extension point from a file location (managed by SVN)
This has proven to be a reliable way of making sure all developers in a team share the same configuration.
I am now updating our project to Juno, and even after enabling the "Classic Update" in preferences, the menu item Help->Software Update->Manage Configuration is missing.
It also seems to be missing in the documentation for juno at http://help.eclipse.org/juno/index.jsp
Any help?
The Update Manager was deprecated a while ago, and has finally been removed in Juno (4.2). You can use the p2 director to perform command-line based installs.
There are other command line apps that can assist with mirroring features in existing update sites to a local directory that can be shared within a company or creating a composite repo that points off to multiple separate update sites (kinda one-stop-shopping) and even publishers that can take featuers and plugins without metadata and prep them for use with the p2 director.
EDIT: A quick tour of options is available here: http://pweclipse.blogspot.ca/2011/06/p2-cheatsheet.html
Related
I need to develop a plugin for OWASP-Zap, but I can not build the project. There is a Quick Set Up for Eclipse but when I try to Team Project Set up then it fails and I have no idea why. Is there anybody here done something like that? I would appreciate if someone can help me.
The quickest way to set up a ZAP development environment is as follows:
1. Ensure you have a recent version of Eclipse - the Eclipse IDE for Java Developers is a good option (Ensure you have a version of Eclipse 4.2 or later installed or if using an earlier version, the "EGit - Git Team Provider" plug-in installed.)
2. Start Eclipse and select a new (empty) workspace
3. Select the menu: "File / Import"
4. Select "Team / Team Project Set" and click "Next >"
5. Select URL and enter: https://raw.githubusercontent.com/zaproxy/zap-admin/master/ZAP-projectSet.psf
6. Click "Finish" and wait for Eclipse to pull down all of the projects and build them.
I see, the psf was removed.
Check out these instructions > https://github.com/zaproxy/zaproxy/wiki/Contributing-Changes keep in mind that for the time being the master/beta/alpha branches in the extensions repo are all completely separate things (based on the status/quality of the extension(s)).
There's also a whole series of Blog posts that you might be interested in:
https://zaproxy.blogspot.com/2014/03/hacking-zap-1-why-should-you.html
https://zaproxy.blogspot.com/2014/03/hacking-zap-2-getting-started.html
https://zaproxy.blogspot.com/2014/04/hacking-zap-3-passive-scan-rules.html
https://zaproxy.blogspot.com/2014/04/hacking-zap-4-active-scan-rules.html
Edit 2022-05-03: There are updated Developer docs here: https://www.zaproxy.org/docs/developer/ including Creating a New Add-on in zap-extensions
Edit 2022-05-24: There is now an example add-on repo available: https://github.com/zaproxy/addon-java
I got a task about replacing Workspace Mechanic in Eclipse since there are no commits since 2014 and sometimes it doesn't work without reason.
I could create and configure a installation.setup file successfully on my local machine with some code clean-up formatting and save actions preferences which are loaded each start automatically. :)
The last step is to centralize the setup-file on a network drive.
Workspace mechanics enables to configue a directory with the settingfiles inside.
Oomph may not support the way I thougt. There is a way to synchronize to Eclipse.org but we want to keep the information inside the company due to policy reason.
Is there any way to store a central (Oomph) setup-file which synchronizes to each Eclipse client at start up?
You can use the Eclipse plugin yatta. It "manages your Eclipse setups – for yourself, your team, or within the community.". Of course, you can simply share the Preferences - other options it provides is share repos and projects.
https://www.yatta.de/profiles/help
With yatta you will create an Eclipse Installer, that can be installed on different clients. The clients will receive Updates of the 'master-settings' and there is the option to fork as well. Settings will be not be saved in local network but in the clould. From scratch, your profile will be private, you can share it with single persons, a group (*#yourcompany.com) or you can share it to public as well.
While Yatta is a handy to use plugin, it is based on Oomph, which is the complex way (you have several 'ontop' configurations for product, project, installation & workspace). In fact, both can do what you want.
I'm building an Eclipse RCP application, and am in the process of setting up the target platform.
In "Eclipse Rich Client Platform" 2nd edition it is noted that one should uncheck the "include required software" option when adding the RCP SDK to the target definition, and install the Delta Pack. This is mentioned across the web as well.
A second option, however, is to uncheck the "include required software" option, so that one can select "include all environments". This isn't mentioned in the book, but it is mentioned acros the web.
So my question basically is: When unchecking the "include required software", should I then (in terms of a "best practice" or similar)
leave the "include all environments" unchecked, and install a Delta Pack, or
check the "include all environments" option?
And furthermore, if 2. is preferrable, do I still have to install the Delta Pack, or is checking the option "include all environments" a full replacement for installing a Delta Pack?
Further info that might (?) influence answers: I plan to build with Tycho...
Many thanks in advance to all who help me!
I have not actually used this (because it's very new), but I think your suspicions are correct according to the documentation. Option 2 is the best choice and you therefore don't need the delta pack.
The delta pack has been around for ages and that's how you get the plugins that are specific for all environments. It looks like with this new thing based on getting stuff from p2 that it can easily get the plugins for all environments that way, eliminating the need to manually install the delta pack.
You can certainly verify this when you build to make sure you have the os-specific plugins for your desired environments (look at the SWT plugins for example).
When installing or updating plug-ins, the update system of Eclipse always fetch some jar/xml files from eclipse.org, this annoying behavior slows down the update process.
Is there any way to disable it?
Eclipse should only contact the sites declared in the "Available Softwares Sites" list:
alt text http://img805.imageshack.us/img805/1044/eclipseavailsites.png
For instance, in the list above, we have removed all references to eclipse.org, and disabled direct p2 repo addresses, and left only references to out own internal Nexus pro repository (which is able to mirror remote p2 site)
We have an RCP application and we are looking for a better way to do installation/updates. Currently to install, they just unzip a zip file. The zip file also contains scripts in it that are not java code. We were running into some bugs when updating if they don't first delete the old folder that was previous unzipped. The issue with deleting the folder is that the user loses the plugin preferences that were set. The installation would also need to register a COM server. The update would have to update the plugins and also replace the current script folder. What are some of the best options that could be used for installing and updating rcp apps? Thanks!
An option is to use the eclipse update mechanism. In this case the user would simply update like in the eclipse ide using help->software update. I have not used it myself yet ,but I have visited a tutorial from kai tödter, just google "eclipse rcp adanced kai tödter" und you will find some stuff, e.g. slides where he explains the updated mechanism as well as an example project "MP3 Manager" where you can find an example