[Fredrik Lindqvist]

I’m looking for suggestions on how to best handle our Eclipse situation.

We have alot (50+) of different projects that could basically be handled by one SDC Eclipse Java package. Their requirements on Eclipse aren’t that different.

They do however have very varied requirements on what internal frameworks are needed on their classpaths, aswell as different projectsets etc. So I’d like to create a situation where each developer can download an eclipse instance and everything is already configured exactly as they need it to be.

The paths and other project specific details can be handled in a preference, projectset or workspace file.

My original plan:
Create one SDC Eclipse package with configurations that are similar for every project. Then make one on-demand secure delivery package for each project that contained the specific configurations. Users would then install the package relevant for them. Unfortunately I just learned this isn’t how the delivery packages work, so this wont work.

Plan B:
I guess the way this is meant to be handled is to create one SDC Eclipse package for each project. Then just define the package to be contain all the project specifics it needs to. But as the number of projects grow this will lead to alot of maintenance and an upgrade of Eclipse will take unecessary long time.
If I wanted to, say, change the java arguments to Eclipse I would have to go throught each package, make the change, build, commit, promote. This would very quickly become time consuming.

Any suggestions or ideas?

Another aspect is that most developers work in more than one project and will need to switch between project.

[sdc-support]

Hello Fredrik.

SDC Let you achieve what you want an a very easy way. Lets say you have two teams Team1 and Team2. Both Teams share a lot of common configurations but you want Team2 to have some extra software or configuration that Team1 should not have. You can achieve this in the following way:
1. Create two packages: “MyEclipse for Team1” and “MyEclipse for Team2”.
2. Create an Environmental policy called “Common configurations”, set up all the common configurations such as Software, Launching Properties, JVM properties and Workspace Tasks Files on this environmental policy.
3. Associate the new environmental policy on the Configuration Tab of both packages (or as many as you need).
4. Now you can configure the per-project workspace settings on each particular package without requiring any reconfiguration / duplication of settings for the common software.

In this way all the common configuration will be handled via the environmental policy which can be shared for all the packages you need. And any specific configuration can be done on the package itself.

If you need more details I will be glad to do a quick skype call if required.

Best Regards.
Héctor – SDC Support

[Author]

Posts