Table of Contents
This chapter describes how you, as a developer, compile CSS from source code. This allows you to execute CSS within the Eclipse development environment, where you can edit the source code and execute it in the debugger.
End users of CSS should not have to compile CSS. In the control room, they should already find it installed. For office use, a version of CSS that is already configured for the local site can be available on a local web site. CSS can self-update from that same web site via the Eclipse update mechanism.
To reach that stage, somebody at each institute that uses CSS obviously needs to prepare such a local down-load site, compile CSS with suitable settings and place the binaries on the web site. Note that in addition to the CSS application that end users will see, a complete installation will also require you to compile the Archive Engine, Alarm Server, tools to configure the archive and alarm system, maybe more.
As the amount of CSS source code grew, it has been split into several modules. To build a CSS product from these, there are two extreme approaches.
Obtaining and compiling the complete source code is time consuming. In practice, you often use an intermediate approach. You obtain the source code for modules that you want to investigate further, for example to fix a bug or to add new functionality. For the remaining modules, you rely on binaries in a remote P2 repository.
Which exact approach you use depends on your situation. You may want to configure a local Hudson/Jenkins instance to perform a complete nightly build for your site, obtaining all the source code and compiling it. Or you may prefer to configure your Eclipse IDE target platform to use remote P2 repositories, then import only the source code for a site specific product and run it in the IDE. Read through the remainder of this chapter to learn about the options and tools, then make your decision.
The complete CSS sources are in a shared GitHub repository using the GIT version control system. The project web site is https://github.com/ControlSystemStudio.
For GIT in general, see http://git-scm.com.
This module lists external CSS dependencies, for example MySQL client libraries or other common Java libraries. Their binaries are fetched from online repositories outside of CSS, for example Maven central, and they are wrapped into Eclipse bundles.
This module contains sources provided by others which needed minimal additions or modifications.
This source repository contains the bulk of CSS sources. It is structured into subdirectories “core” and “applications”, which each have further subdirectories.
A generic CS-Studio product.
Many sites create a set of products that combine desired common features with site-specific additions, for example support for a local log book or data sources.
Below is an example for fetching a complete copy of the source code. If you choose to rely on remote binaries for all but the product, you would only perform step 4.x.
# Define base URL GH=https://github.com/ControlSystemStudio # 1) Maven bundles git clone $GH/maven-osgi-bundles # 2) Third party git clone $GH/cs-studio-thirdparty # 3) Diirt git clone $GH/diirt # 4) Bulk of CSS sources git clone $GH/cs-studio # Depending on your site, you would only fetch one of the following # examples, or use one that you created for your own purposes # 5.1) 'common' product git clone $GH/org.csstudio.product # 5.2) SNS products git clone $GH/org.csstudio.sns # 5.3) NSLS2 product git clone $GH/org.csstudio.nsls2.product # 5.4) Your product? git clone you_would_need_to_know_what_to_get
master branch of each repository contains the most recent set
of sources. For each release, there is a numbered release branch, for example
New functionality and bug fixes are added to the master branch, while the release branches
are only updated for essential bug fixes.
To work on the CSS source code, i.e. to be able to submit changes, several steps are necessary:
When you compile CSS sources, building each module results in a P2 repository of artifacts. Compilation of a module typically depends on other previously created modules. For example, compiling the cs-studio sources requires access to P2 repositories for the maven-osgi-bundles and cs-studio-thirdparty artifacts.
When you compile from sources, these P2 repositories will be created in subdirectories
repository/target/repository of your source tree.
If you prefer to skip local compilation and instead use remote repositories,
these are under
In the following description of remote repository URLs, note that each URL contains a version number.
When working with a relased version, the URL simply contains the version number.
For the source code on the git
master branch, the URL uses the next to-be-released
Note that diirt uses a slightly different repository path and version numbering.
The CS-Studio sources are split into core and applications, which each result in their own repository.
# Use either the Eclipse IDE or a CSS product. # Both should include the Equinox launcher # plugin which in turn contains the P2 director export APP_PLUGINS=/path/to/my/eclipse DIRECTOR="java \ -jar $APP_PLUGINS/plugins/org.eclipse.equinox.launcher_*.jar \ -debug -consolelog \ -application org.eclipse.equinox.p2.director" # List content of a remote repository. $DIRECTOR -list -repository http://download.eclipse.org/releases/luna/ # List content of a local repository. # Path needs to start with 'file://' and be absolute. $DIRECTOR -list -repository \ file://path/to/maven-osgi-bundles/repository/target/repository
Assembling a product typically requires artifacts from
cs-studio/applications and maybe locally
created site-specific additions.
A composite P2 repository
is simply a list of other P2 repositories.
It can list local as well as remote repositories, which is useful because you typically need to
use a combined approach.
For example, you may want to use remote repositories for
cs-studio-thirdparty, but prefer locally created artifacts for the rest.
To create a composite repository,
create a directory
my_comp_repo in the same directory
that also contains the previously cloned source modules
with the following two files:
<!-- File my_comp_repo/compositeContent.xml --> <?xml version='1.0' encoding='UTF-8'?> <?compositeMetadataRepository version='1.0.0'?> <repository name='Local Composite Repository' type='org.eclipse.equinox.internal.p2.metadata.repository.CompositeMetadataRepository' version='1.0.0'> <properties size='1'> <property name='p2.atomic.composite.loading' value='false'/> </properties> <children size="5"> <child location="http://download.controlsystemstudio.org/maven-osgi-bundles/4.2"/> <child location="http://download.controlsystemstudio.org/thirdparty/4.2"/> <child location="http://diirt.download.controlsystemstudio.org/diirt/3.1.6"/> <child location="../cs-studio/core/p2repo"/> <child location="../cs-studio/applications/p2repo"/> </children> </repository>
<!-- File my_comp_repo/compositeArtifacts.xml --> <?xml version="1.0" encoding="UTF-8"?> <?compositeArtifactRepository version='1.0.0'?> <repository name="Local Composite Repository" type="org.eclipse.equinox.internal.p2.artifact.repository.CompositeArtifactRepository" version="1.0.0"> <properties size='1'> <property name='p2.atomic.composite.loading' value='false'/> </properties> <children size="5"> <child location="http://download.controlsystemstudio.org/maven-osgi-bundles/4.2"/> <child location="http://download.controlsystemstudio.org/thirdparty/4.2"/> <child location="http://diirt.download.controlsystemstudio.org/diirt/3.0.1"/> <child location="../cs-studio/core/p2repo"/> <child location="../cs-studio/applications/p2repo"/> </children> </repository>
In this example, we depend on remote repositories for
diirt, while using locally created artifacts for the rest.
For local child locations, entries starting in
file:/ refer to the root directory
and need to be absolute. The child locations in the example refer to locations relative
to the XML files.
For further examples, check the
which themselves are composite repositories.
p2.atomic.composite.loading controls how missing child locations
Setting it to
true will check if all listed child locations contain valid repositories.
This can be used to test the correctnes of the composite repository settings.
On the other hand, when we start out fresh and compile the
cs-studio/applications/p2repo will not exist, yet, because it is generated
in a later step, so we need to set
is a generic build tool for Java.
to define how a piece of software needs to be compiled, and to list its dependencies.
Eclipse plugin sources already include
files for almost the same purpose.
Tycho, a support module for Maven,
allows Maven to re-use the existing Manifest files to compile Eclipse source code.
From now on, we will refer to the Tycho/Maven Build as simply the Maven Build. To build CSS from sources with Maven, you need
Sources: The sources you want to compile. Obtain them from Github as described earlier in this chapter. You only need to fetch those sources that you want to compile.
java: A Java Development Kit (JDK) is necessary to compile the sources. It should be the JDK, not just a Java Runtime Environment (JRE). It should be the Sun/Oracle JDK. OpenJDK, the GNU Compiler for the Java (GCJ) and other environments are currently not fully compatible with the Sun/Oracle JDK. Google for “Oracle JDK”.
mvn: Maven. See http://maven.apache.org.
Add the desired version of Java to the
environment variable as well as the
export JAVA_HOME=/path/to/the/jdk export PATH=$JAVA_HOME/bin:$PATH
Verify that Maven is using the desired version of Java.
Note that the first Java found on your
$PATH may not be what Maven uses
because it checks
Verify by checking the output of
When obtaining the Maven Build tools and CSS sources,
you may have noted that we fetched neither Tycho nor Eclipse.
The beauty of Maven is that it will download all dependencies,
including Tycho and Eclipse, and work like a charm as long as it feels like doing so.
The horror of Maven is that it always appears to download the internet.
When the commands listed in the following instructions
are run for the first time, Maven will initially download Tycho.
It will place Tycho in a local Maven repository,
Subsequent calls will not require a complete download, but Maven will continue to check
remote sites for updates, even when invoking a simple
mvn clean command.
If you have used Maven on a previous project, you may be familiar with executing it as
This will compile the source code and place the results in the local
Maven repository. For compiling CSS, this is not recommended.
Do not invoke the Maven
install command, because this will
result in version conflicts between artifacts that Maven then installs in its local
repository and the current sources of CSS.
Instead, we use
mvn verify, and the generated CSS binaries
are placed in the previously described local P2 repositories within the source tree.
If you do not further configure Maven, all CSS compilation will default to
using remote repositories.
For example, if you only obtained the source code for the common CSS product,
the following will build it, obtaining all required depdendencies from
remote repositories which are configured in the
of the product:
# Compile common product (cd org.csstudio.product; mvn clean verify)
As you develop CSS, you might prefer to download more of the source code
so that you can inspect and maybe modify it. You then configure a composite
repository that lists your locally created repositories, based on locally edited
sources, over the remote repositories.
To configure Maven to use your composite repository as well as additional settings,
create either a global file
or in a user-specific file
You could also specify the properties listed in this file on the command line,
invoking Maven as
but to assert consistency are best placed in a
based on the following example:
<!-- Maven settings.xml --> <settings> <profiles> <profile> <id>my-css-settings</id> <properties> <!-- Optionally, configure a composite repo. By default, the Maven build will fetch all depenencies from remote repositories. In your composite repository, you can list local repositories. --> <!-- Path to your composite repo --> <csstudio.composite.repo>/path/to/my_comp_repo</csstudio.composite.repo> <!-- By default, even if you use a composite repo that lists local P2 sites, Maven will still consult the remote CSS repos. Setting this property DISABLES downloads from http://download.controlsystemstudio.org, so you use _only_ sites listed in your composite repo. If you still want to use selected entries from http://download.controlsystemstudio.org, you can list them in your composite repo. --> <cs-studio>false</cs-studio> <eclipse>false</eclipse> <!-- Ignore artifacts in ~/.m2/repository/p2, which some other "mvn install" may have placed there. --> <tycho.localArtifacts>ignore</tycho.localArtifacts> <!-- Issue warnings instead of aborting on error --> <baselineMode>warn</baselineMode> <jgit.dirtyWorkingTree>warning</jgit.dirtyWorkingTree> <!-- Skip unit tests --> <maven.test.skip>true</maven.test.skip> <skipTests>true</skipTests> </properties> </profile> </profiles> <!-- Enable the above settings --> <activeProfiles> <activeProfile>my-css-settings</activeProfile> </activeProfiles> </settings>
To verify that your Maven setup uses the properties as you define
them in your settings file, you can use these commands
in any of the CSS source tree locations that contain a Maven
# Should list "my-css-settings" (cd maven-osgi-bundles; mvn help:active-profiles) # In the long output, locate the <properties> and # verify they include what you entered in settings.xml (cd maven-osgi-bundles; mvn help:effective-pom)
Finally, to build CSS from sources, run Maven like this:
# To start fresh, clean your local repository # If you have accidentally invoked # mvn install # or want to assert that you start over fresh, # delete the Maven repository: rm -rf $HOME/.m2/repository # If you want to compile the maven-osgi-bundles # and listed its local repo in your composite repo, # do it. # Otherwise skip this step, and use the only repo # for this module. (cd maven-osgi-bundles; mvn -B -P my-css-settings clean verify) # Similarly, compile cs-studio-thirdparty unless # you prefer to use its binaries from a remote repo. (cd cs-studio-thirdparty; mvn -B -P my-css-settings clean verify) # Again if you prefer local mud (cd diirt; mvn -B -P my-css-settings clean verify) # If you want to compile core, .. (cd cs-studio/core; mvn -B -P my-css-settings clean verify) # If you want to compile applications, .. (cd cs-studio/applications; mvn -B -P my-css-settings clean verify) # Compile desired products (cd org.csstudio.product; mvn -B -P my-css-settings clean verify) # or: (cd org.csstudio.sns; mvn -B -P my-css-settings clean verify) # or: (cd org.csstudio.nsls2.product; mvn -B -P my-css-settings clean verify)where
my-css-settingsis the identifier of the active profile in your maven settings file.
After the last step, the created products can be found in the following locations, depending on which products you built:
org.csstudio.product/repository/target/products org.csstudio.sns/repository/target/products org.csstudio.nsls2.product/repository/target/products
Most products also create a P2 update repository from which the generated product can install optional features, for example
After changes to the source code, you do not need to recompile everything.
If you change for example code under
you can build only that sub-module of applications via
(cd cs-studio/applications/logbook; mvn -B -P my-css-settings verify)
It is possible to use 2 static libraries containing all the Eclipse Mars plugins and sources, and all the CS-Studio plugins to simplify and speed-up the compilation process.
To use these libraries the following procedures must be followed.
Procedure 4.1. Preparing cs-studio-eclipse-4.3 P2 Repository
cdon the cloned directory and execute
mvn -B clean install
target/cs-studio-eclipse-4.3-p2.zipinside the directory that will contain the static library.
cdin that directory and execute
unzip -u -q cs-studio-eclipse-4.3-p2.zip
Procedure 4.2. Preparing cs-studio-4.4 P2 Repository
cdon the cloned directory and execute
mvn -B clean install
target/cs-studio-4.4-p2.tar.gzinside the directory that will contain the static library.
cdin that directory and execute
tar -zxvf cs-studio-4.4-p2.tar.gz
Now put inside your composite files two additional child location lines similar to the following:
<child location="somewhere/cs-studio-eclipse-4.3/p2repo"/> <child location="somewhere/cs-studio-4.4/p2repo"/>
*.productfile for CSS, ArchiveEngine, ... and launch it.
The IDE allows you to run the products in debug mode, setting breakpoints, examining the source code.
Once the product is acceptable for use at your site, you can export it from the IDE and install the result on the desired computers.
Both the JDK and the RCP IDE need to be a specific version, ask other CSS developers for the currently supported versions.
Start the Eclipse IDE, and assert that it uses the JDK:
Preferencesmenu item. It is usually in the
Windowsmenu, except for Mac OS X which offers it in the
Addto add it, then select it as the default.
Deprecated and restricted APIand change the handling of “Forbidden reference (access rules)” from Error to a Warning, or Ignored.
The Eclipse IDE includes Maven support, but not Tycho. Since the CS-Studio sources are now based on Tycho pom.xml files, the IDE needs to create the original IDE files when the sources are imported. Add Tycho support to the IDE:
Open Catalog, enter
tycho, select the
Finishand restart Eclipse when prompted.
Tycho Configuratorlisted under the menu
The IDE may still not understand all the maven commands found in the
This is not a problem, because several commands are only meant for maven execution outside of the IDE.
To ignore such errors:
Plugin execution not covered by lifecycle configuration.
Even if you import the complete CSS source code into the Eclipse IDE,
you still need certain external dependencies that are not included in the source code.
The Maven Build obtains external resources from online repositories listed in the
While the Eclipse IDE reads the
pom.xml files to some extend,
it will not fetch external resources.
Target Platform lists a set of plugins that the IDE
uses when compiling source code.
By default, the target platform of the IDE includes only the IDE itself.
For CSS development, you need a target platform that includes the following:
pom.xmlfiles, the IDE requires them to be included in the target platform.
Once you completed the Maven Build from the command line as described earlier in this chapter, you can use that as your target platform.
Add, then the option to base the new target on the
Directory. Browse to the
repository/target/repositoryof your product build tree, or to the actual binary product which has a
Finish, and assert that your new target platform is selected as the active one.
This option has the advantage that your IDE target platform contains only locally available plugins, avoiding the sometimes problematic resolution of remote dependencies.
On the downside, this approach requires you to first build everything from sources using the Maven command line. The resulting target will only contain those artifacts that were required to build a specific product.
You only need to import the sources on which you want to work.
For example, you can import just the product sources, then start the product
within the IDE. All its dependencies, for example required
plugins, will be obtained from the target platform.
If you want to work on plugins from
cs-studio/core, you can later import them as needed.
To import the desired sources into the IDE:
Existing Maven Project.
org.csstudio.productdirectory. For the
cs-studiosource tree, select either the
cs-studio/applicationssubdirectory, or a specific sub module like
Add Projects to Working Setand enter a suitable name.
.classpathfiles, see below.
The IDE should now compile the imported sources. There should be no compilation errors.
Open one of the
*.product files, for example
You can use the Eclipse
File menu to
locate all available product files as shown in Figure 4.1, “Locating all Product Files”
When you open an Eclipse product file, it will be displayed as per Figure 4.2, “Eclipse Product Editor”.
Overview tab, first press
Launch an Eclipse Application to run the product from within the IDE.
The product should start up.
When running a product from within the IDE for the first time, the main goal is that the product should start. It may then stop because of missing command line arguments, but there should be no errors regarding missing plugins or compilation problems.
The product may not start up, instead reporting errors like “Product ....could not be found” or “Missing required bundle ...”, even though the Maven Build resulted in a product that starts without errors. This results from the Maven Build automatically including required plugins, while the IDE expects each plugin that you want to include in the product to be listed in the product file or its features.
Ideally, all products would include their dependencies such that the same
product file can be used by the Maven build as well as the IDE without changes.
Meanwhile, you can invoke the menu
Locate the configuration for the product, open its “Plug-ins” tab.
Validate Plug-Ins to identify unresolved plugins, i.e. missing dependencies.
Either manually add the plugins that were reported as missing,
or try the
Add Required Plug-ins button to add them automatically.
Add Required Plug-ins button is easier to use than the manual approach,
it tends to overzealously add test fragments to the procuct which are not actually required.
In the case of the command-line products like the Alarm Server it might soon exit with an error message indicating
that it requires command-line arguments.
It is of course trivial to provide command-line arguments when invoking such tools as intended from the shell.
During development and initial testing, though, it can be more convenient to execute CSS products
from within the IDE.
To add command-line arguments
to products executed in the IDE,
invoke the menu
Locate the configuration for the product, open its “Arguments” tab.
The “Program Arguments” section may already contain entries like
Add your desired command-line arguments to the end of the program arguments.
Once you get the product to run: Congratulations!
Almost as easy as running the product is debugging it:
Instead of running the product again from the menu
Debug History to start the product in debug mode.
You can browse the source code, set breakpoints by double-clicking at the start of a source line,
then step through the code from the breakpoint on.
The Eclipse IDE has good support for executing JUnit tests and test-driven development in general. You can start many programming tasks by first implementing the JUnit test, using the IDE “Quick Fix” feature to create skeletons for the required classes and interfaces, which you then fill with the actual code until the test passes.
You will find several JUnit tests in the CSS plugin code because
a lot of it was implemented in a test-driven fashion.
These classes are often found in a
test/ source folder,
and the source files will be named
To execute a JUnit test, you simply right-click on the class file in the
Project Navigator and select
Some tests will need configuration files to specify database URLs or other
site-specific parameters. Refer to comments in the source code for details.
Eclipse supports a special type of JUnit test to allow testing
within the Eclipse runtime environment. This is necessary for tests that depend
on the Eclipse plugin registry and preference system.
Tests that require the plug-in runtime should be in source files
To execute them, select
JUnit Plug-in Test
from the file context menu.
When you invoke such a JUnit Plug-in Test for the first time, the IDE will create a run configuration that loads all the plugins found in your workspace. If the plugin containing your test refers to Eclipse user interface plugins, the plugin test configuration will in addition start an instance of the complete Eclipse IDE with all your workspace plugins, then execute the test. This can take a long time and be overkill for what you want to test.
plugin test is a test that requires the Eclipse plugin runtime environment
but not the complete IDE user interface.
Such test source files are typically named
To invoke such a test, you can once execute it via
JUnit Plug-in Test
to create the basic run configuration, but then you should edit it as follows:
JUnit Plug-in Testthat was created for your headless test.
Main tab, select
Run an application with the option
[No Application] - Headless Mode.
This will significantly reduce the startup time of your test because you avoid a copy of the Eclipse IDE.
Arguments tab, you might need to add a program argument
if your test needs certain preference settings.
Plug-ins tab, by default all plugins in your workspace will be included.
You can change that to only include selected plug-ins, which can reduce the startup time
and might also be necessary to test the behavior of your test in case it depends
on certain other plugins being available or not.
End users of CSS cannot be expected to open the IDE, install the source code, and then run CSS from within the IDE. They need a product that executes from their “start” menu or a desktop link. The preferred way to create standalone products is via the Maven Build described earlier in this chapter, because that results in a complete set of products for all target architectures. Occasionally, however, it can be faster to create a single standalone product for testing by “exporting” the product from the IDE.
To export a product, open the product file that was already shown in Figure 4.2, “Eclipse Product Editor”
and press the
Eclipse Product export wizard link in the Overview tab.
This will open the Eclipse product export dialog, see Figure 4.3, “Product Export Dialog”,
where you enter the following:
As a Root Directory, enter the name of the product, for example ArchiveEngine, CSS, ... You could include a version number, for example MyCSS-4.0.
Use only a directory name, no path! This is the name of the directory that will contain the generated executable and associated files.
Enter a Directory path where the exported product should be placed,
Enter a full path for this option! In the end, the name from the previous option
will be appended to this directory path, so your product will end up in a directory
Also assert that the directory that you selected is empty! When you export a product into a directory that already contains a product, maybe an older version of the same product, Eclipse will attempt to add the new code to the existing content, similar to an online update of an existing product. That is probably not what you want, so export into a an empty directory.
You should now have a directory like
that contains a
You can copy that directory to other computers and run it there.
One method of deployment would be to offer a ZIP file of the exported product on a web page.
If you left the option to “Generate metadata repository” checked, Eclipse will generate also an update repository, see Chapter 18, Update Repository.
Command-line applications, in Eclipse called “headless” RCP applications, are invoked from a terminal window, i.e. the Linux shell, Mac OS X terminal, or Windows Command Prompt. They are configured via command-line arguments, and they print information to the terminal.
Note that there is currently a limitation for command-line products on Windows!
Headless RCP applications work fine on Linux and Mac OS X, but in the Windows command line tool
cmd.exe you will by default not see any output from headless RCP applications.
is related to the fact that Java for Windows includes both
java.exe because Windows distinguishes
between GUI and console applications.
javaw -version invoked in
will not display any output, either.
Eclipse for Windows likewise includes launchers
Headless products like an
eclipsec.exe as their launcher, but there is currently no
way to specify this in the product configuration, see also
the bug report on “Support for exporting eclipsec.exe in RCP apps”,
For the time being, the only solution is to manually replace the generated launcher, for example
AlarmServer.exe, with a copy of
copy \path\to\eclipsec.exe AlarmServer.exe
After replacing the original executable with a copy of
you can invoke the
AlarmServer.exe from within the Windows Command Prompt,
and you will see its command line output inside the Command Prompt window.
If you start the
AlarmServer.exe via double-clicks from the Windows Explorer,
i.e. not from within a Command Prompt, it will actually open a new Command Prompt in which it can
then display command line output.
The product that you export from the IDE is by default limited to the operating system on which it was exported because of the OS-dependent launcher and SWT libraries, see the section called “Java, Eclipse, RCP”. To export code for different platforms, you need the Eclipse “Delta Pack”. With the Delta Pack installed, Eclipse on OS X can for example build products for Windows, Linux, and OS X. Same for Linux and Windows.
To obtain the delta pack:
To use the delta pack:
eclipsedirectory with sub-directories
When you now export a product from the IDE, there will be a new option “Export to multiple platforms”.
In the Mars release, delta pack zip file is no longer available on the download page. The reason for removing it was that p2 can be used instead, so it saves complications in the Platform build, and does not take up redundant space making the same stuff available in multiple ways.
Goto Multi-platform build wiki page for more information about it and the full instructions to setup multi-platform build on the new Eclipse releases.
A side effect of the headless build and a P2-managed product is that it is no longer possible to simply replace plugins in a product with new versions. If you replace a plugin JAR file with a different version, even if the names exactly match, P2 will recognize the change because of checksums. It will refuse to load the modified plugin, because it was part of the original configuration. In the spirit of maintaining a well defined product with known content, this makes sense. Occasionally, however, it is a big nuisance: Fixes to small bugs are no longer possible via basic plugin updates. Instead, you have to create a new product by incrementing all version numbers, perform a complete headless build, then publish the new product and its repository on the update site.
A feature patch can be used to update only part of a product
while maintaining full configuration control.
Assume our current product contains a plugin
with version number 3.0.1
that we intend to replace with a newer version 3.0.2.
We need to determine which feature provides that plugin
in the product-to-update, and we need to determine
its exact version, including a possible date/time qualifier.
If you do not know which feature provided the original plugin,
search the files in the
of the installed product. Assume we find that the plugin was
provided as part of the feature
Create a new Feature Patch project in the Eclipse IDE:
org.csstudio.trends.databrowser2. The feature that we are patching might contain many more plugins, but in the patch we only include what we want to add or replace. Assert that the version numbers of all the plugins that you want to replace have been incremented from their installed version.
You can now export the feature patch, using an archive file
databrowser3.0.1.patch.zip as the target,
and then use that ZIP file to install the patch into your product
via the menu item
Install New Software...
by adding the ZIP file to the available software sites.
As a result, the original
plugin is replaced with the new one, while P2 remains fully aware of what
version of which plugin was installed from where, so it will for example
allow you to un-install the patch, or later add additional feature patches.