how to repackage eclipse for my team

Question

Hi all,

I'd like to set up eclipse with a bunch of plugins and DB connection configurations, etc and re-zip it up so my team-mates and new starters can all be working on the same platform easily.

It seems that installing plugins is fine, but when I add in custom jars (e.g. ivy2, ojdbc, etc) they all save with full, absolute paths which probably dont exist on others machines (particularly if they unzip in a different location to me).

Anyway, I'm hoping that this idea is not silly and am working if this sort of process is documented somewhere or if anyone has any tips in general.

Thanks,

Answer 1

We did a similar thing with our development environment (it needed both Eclipse and our own plug-in which, in the early stages, had to run in a known location).

We just put it in c:\eclipse_<projName> and made that a requirement for the team. That's probably the easiest solution for you.

It's your team, you can dictate this as a requirement. Unless your team members are absolute idiots, they'll work with you.

Answer 2

Although not exactly in line with the direction of the question, you could use Yoxos OnDemand. It allows you to "roll-your-own" Eclipse distro and download it as a zip. They add in their own perspective where you can add more plugins (direct from their repo), or update the plugins that you have.

Although I've never used the feature, you can make make your own stacks and name them, allowing anyone to go to the site later and download it (with the most up-to-date versions of the plugins). Also, dependencies for plugins are resolved automatically if need be.

Answer 3

I found Yoxos really good and it does very good work in determining dependencies. Its really a good tool and worth giving a look.

Answer 4

In eclipse - in many places it's possible to use workspace relative paths or system environment infos to reference external files, too. Another option could be to place your jars into a workspace project so that every team member can check it out from cvs/subversion/whatever and start working. Working like this ensures a reproducible environment for server builds or for desktops even after years.

Talking about Yoxos... it provides "Workspace Provisioning" as well. This means you can attach Eclipse Preferences, checkstyle configurations and Mylyn setups additionally to your list of needed tools/plugins for your IDE to your yoxos profile. This means your team could share a profile and would be able to start working with the same setup regardless of their OS or whatever. (Its possible to use multiple profiles at once, too.)

Answer 5

I would recommend against requiring all developers to place eclipse in the same location. There are times when some developers may want to try an alternate version of eclipse to explore a technology that requires a different set of plugins or a different eclipse base version.

Let developers install eclipse where they would like.

However, for jars that you need to run plugins (external dependencies that you need to configure for proper plugin usage):

Hardwire a directory for those jars (as opposed to the entire eclipse dir), like c:\eclipse-helpers or something.

---

To deal with third-party library dependencies (in the code you're developing), you have a few good choices:

1. Create project(s) to hold the third-party libs and check them into your source version control system (which you are using, right?). You can then add the libs to the build path(s) of the project(s) - make sure you mark them for export in the "order and export" tab of the build path page. You can then simply add these third-party projects as project dependencies.

2. Reference the third-party jars as CLASSPATH variables when adding them to the build path of your projects. This allows other developers to store the dependencies in different locations. Perhaps define a CLASSPATH variable (in eclipse's Window->Preferences->Java->Build Path->Classpath Variables) called THIRD_PARTY_JARS; each developer can map it to a different path where they want to hold their deps.

3. Reference the third-party jars as a "user library" (Window->Preferences->Java->Build Path->User library). This is similar to classpath variables, but acts as an explicit set of jars.

4. Include the third-party jars directly in your projects. Use this option only if you need the deps in a single location.

Answer 6

I just started using git to manage my eclipse install. I did a write-up. The approach might work for you, and it's probably worth looking at.

Answer 7

If developers all don't have the same paths on their machine, instead of adding independent JAR files you could create what Eclipse calls a "library" and include a bunch of jars in that. Then another developer just has to change the location of the library and it'll pick up all the jars in there.