Geek Answers Handbook

Terms of use for update sites in Eclipse?

Do you know any documentation about the rules for using update sites? For the last two and a half years I have been updating the site of our company, and these are the problems that I have to solve:

  • Not all projects use the same version of eclipse. 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.
  • Our company’s update site basically brings things together. So I wrote litte plugins (sometimes fragements) to pack, for example. Checkstyle configuration for our company along with the current version of Checkstyle.
  • We release twice a year new versions of what has changed. Therefore, if I have 1 update site or 4, this will dramatically change the load that I have to fulfill.

So the question is: how many update sites should I use, and if the number is more than 1, how can I minimize the work that needs to be done to support update sites?

+6
eclipse automation
source share
2 answers

I suggest placing 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
and etc.

This will simplify the deployment so that everything is aloof, and it will make it easier for users to see "oh, this is for me."

+4
source share

You should probably use functions and categories segmented by the 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 to maintaining multiple update sites, although you might think:

  • sticks to the lowest common denominator that works and minimizes errors.
  • that plugins written for Eclipse 3.4 cannot be reasonably expected to work in Eclipse 2.1.
  • some version errors between versions of Eclipse cause some pain in updating for plugins (for example, from 3.0 to 3.1 - a big leap).
  • The configuration between different versions of the same product may not be compatible.
  • Versions of the same plugin may have a different set of functions, but may not work with all versions (for example, Checkstyle 5 supports Java 5, but may not work with the Checkstyle plugin that works with Eclipse 2.1)

However, if it is impossible or desirable to have several levels of categories, moving forward with the categories proposed above to separate update sites is the way forward.

This has deployment benefits, as users can point to the update site for the version of the IDE that they use, but this is what you avoid.

+1
source share

More articles:


All Articles