|
|
| As part of this scenario you will be downloading
and installing various versions of the Eclipse components into the running
Eclipse. The update site is populated with features that have their version
numbers modified as part of the build process. They are generally of the
form 2.0.0.QUALIFIER, where the qualifier differs build to build. Note,
however, that when you install base Eclipse (.zip downloaded from eclipse.org),
all of its features and plugins only use 3 part version identifiers (generally
2.0.0). So all the 2.0.0.Q updates in fact appear more recent that the
build you are running, even though they may in fact be an older build.
Note, that when you update the Eclipse components from the update site
and restart you may in fact now be running DIFFERENT
CODE THAN WHAT YOU STARTED WITH. So it is
really important that you start each of the test scenario steps with a
clean install of eclipse. It is suggested
that you always use a second install of Eclipse running with a different
workspace (than what you use to do development) to actually run through
these scenarios.
When openning Bugzilla defects, use the platform/update component. Please ALWAYS specify the failing scenario step, and include a .zip of the <workspace>/.metadata/ directory |
|
|
| When openning Bugzilla defects, use the platform/update component. Please ALWAYS specify the failing scenario step, and include a .zip of the <workspace>/.metadata/ directory |
path=<some new install directory>
Note: the path should be an absolute path using local file system syntax. The .link file is loaded as a Java properties file, so on Windows you need to double up the back-slashes (eg. path=c:\\temp\\install)