Rules for using update sites in Eclipse?

Question

Do you know any documentation about the rules of using update sites? I have managed the last 2 and a half years the update site of our company, and these are the problems I have to address:

• Not all projects use the same eclipse version. We had projects that used eclipse 2.1 (WSAD), eclipse 3.0 (RAD 6), eclipse 3.2 (RAD 7), eclipse 3.3 and eclipse 3.4.
• The update site of our company mostly packages things together. So I have written litte plugins (sometimes fragements) to package e.g. the configuration of Checkstyle for our company together with the current version of Checkstyle.
• We release two times a year new versions of what has changed. So if I have 1 update site or 4, this will change dramatically the load I have to take.

So the question is: How many update sites should we use, and if the number is more than 1, how can I minimize the work to do to maintain the update sites?

Answer 1

I suggest to put everything on one web server and deploy the packages for each version of Eclipse to a different URL:

http://your.server/eclipse-3.3/site.xml
http://your.server/eclipse-3.4/site.xml
etc.

This will make it easy to deploy, to keep things apart and it will make it simple for users to see "ah, this is the one for me".

Answer 2

You should probably be using features and categories, segmented by eclipse version.

|
+-WSAD-2-1 Category
|   |
|   +- Checkstyle 3.1 Feature
|   |
|   `- Team Checkstyle configuration for Checkstyle 3.1
|   
`-Eclipse-3-4 Category
    |
    +- Checkstyle 4.4 Feature
    |
    `- Tema Checkstyle configuration for Checkstyle 4.4

This may be isomorphic with maintaining multiple update sites, though one may consider:

• sticking with the lowest common denominator that works, and minimizes bugs
• that plugins written for Eclipse 3.4 cannot be reasonably expected to work for Eclipse 2.1.
• some version bumps between Eclipse versions cause a certain amount of upgrade pain for the plugin writers (e.g. 3.0 to 3.1 was a big jump)
• Configuration between different versions of the same product may not be compatible.
• Versions of the same plugin may have a different feature set, but not work on all versions (e.g. Checkstyle 5 supports Java 5, but may not work with the Checkstyle plugin which works with Eclipse 2.1)

However, if it isn't possible or desirable to have multiple levels of categories, then promoting the categories suggested above to separate update sites is the way forward.

This has deployment advantages, as users can be pointed to the update site for the version of IDE they're using, but is exactly what you're seeking to avoid.