In the context of creating a custom Eclipse distribution for a development team.
How would I go about building a custom Eclipse distribution containing a specific set of plugins? Would it be difficult to also add a kind of update site to put specific versions of the plug-ins from which the customized eclipse would update?
Answer
I realize this is an old post, but it keeps coming up on searches I do and I’d like to put in some more details given all the changes and maturity that has occurred when it comes to delivering Eclipse plug-ins... So, for those who end up on this page, hopefully the following will help you out!
To summarize my personal findings:
- There have been many improvements in this space both in open source and commercially
- The complexities of distribution are often greater than expected
- Build on the backs of others, it is worth it!
And while I work for a company offering a commercial solution (http://genuitec.com/sdc), I’ve tried to answer below with the practicalities of Eclipse delivery using free solutions.
So, without further adieu...
The absolute minimal solution is to download an Eclipse package from Eclipse.org, add the plugins you want, set the -clean parameter in the eclipse.ini, zip up the directory and hand it around your team. As long as you added the features from your internal update site (and the URL remains constant), Eclipse will be able to update from it.
This will work the first time, and since it's easy, it's what most people start out doing. But it ignores the lifecycle of your tool stack. Here are some pain points I've encountered while helping customers with their Eclipse tooling:
Eclipse Packages: You have to be an Eclipse/p2 guru to set up and maintain Eclipse packages. The EPP tools allow you to build your own packages, but you need a lot of domain knowledge around Eclipse packages, p2, and the EPP tooling. A place to start is http://wiki.eclipse.org/EPP/How_to_build_a_package_locally
Plugins: Finding plugins involves lots of hunting for update sites and then you can never be sure you got the exact right binaries. Sometimes update sites go down, or you lose support for your Eclipse version when the plugin developers release a new update site. One suggestion is to make local copies of update sites to mitigate your exposure to such problems.
Eclipse Updates: If you want your team to switch Eclipse versions, you'll end up just rebuilding your tool stack on the next version and having everybody reinstall. There's no way around this when just shipping a zip.
Plugin Updates: Eclipse is designed to keep installing the new version of plugins, but in large production teams that can be counterproductive. Local mirrors of update sites can help with this as long as your team doesn't go out and add their own update sites.
Security: Do you need to prevent your team from installing some software? What about requiring signed tools? You'll have to write plugins to limit the features of your package and you may have to sign plugins yourself. The PDE build has some support for signing.
Long Term Maintenance: Rebuilding a tool stack in a few years (or sometimes a few months) can be close to impossible as support for different versions of Eclipse and different plugin versions comes and goes dynamically in the Eclipse ecosystem. Save off copies of your Eclipse packages. Buy big hard drives. Mirror the update sites you use.
Workspace Setup: You can deploy an Eclipse to your team, but that's just the first step in the process. Automation for workspace setup, e.g. preferences, projects, Checkstyle or PMD configuration, goes a long way in reducing the amount of time your team spends getting ready to work. Additionally, these settings change often as you add projects creating continuous management hassles. When passing around a zip, I've seen teams also pass around a corresponding WIKI page or something similar. It's usually up to each developer to make sure they follow the steps.
Managing Multiple Packages: Maybe you have one package for your dev team and another for your QA team. And then your dev team grows and splits into two groups with slightly different tooling needs and now your QA team needs multiple packages too. And then you start shipping your own plugin on top of Eclipse so that's another package that you are managing. After a few years of this, you spend all your time building Eclipse packages and you became a Eclipse/P2/Update Site guru without even trying. Clearly, the solution here is to hire somebody to do this for you. :)
SMS Distribution: This works reasonably well with a zip file, but pushing out updates gets messy. Usually, people use SMS to drop down the first install, and then it's the developer's job to keep it up to date.