OpenArbor Maintenance
New releases of Eclipse are available every 3 months or so (www.eclipse.org). The decision to upgrade a 3rd party plugin may require a new Maven Repo, or to migrate to a new version of Eclipse.
Migrating to a New Version of Eclipse
When migrating to a new version of Eclipse, it's important to remember to install only 64bit versions of Eclipse, the Java JDK & JRE and any 3rd party plugins. There are several steps involved in migrating. The end goal is to:
- Create a new OpenArbor devkit for DDC-I developers to use for their work
- Build a working set of plugins to distribute to customers using the new environment
- Test the newly build plugins using SWTBot
- Upgrade the test harness to the new version of Eclipse
Upgrade to Luna
OpenArbor_Maintenance_Upgrade_to_Luna
Upgrade to Neon
OpenArbor_Maintenance_Upgrade_to_Neon
Upgrade to Oxygen
OpenArbor_Maintenance_Upgrade_to_Oxygen
Upgrade to 2019-12-R
OpenArbor_Maintenance_Upgrade_to_2019-12-R
Upgrade to 2020-12-R
OpenArbor_Maintenance_Upgrade_to_2020-12-R
Upgrade to 2023-03-R
OpenArbor_Maintenance_Upgrade_to_2023-03-R
Upgrade to 2025-03-R
OpenArbor_Maintenance_Upgrade_to_2025-03-R
Update the Maven Repo
If you're upgrading to a newer version of a 3rd party plugin (i.e. SWTBot), delete the old version from the repo first.
- make unreleased
This will make a workspace/build directory containing the existing maven-repo zip file.
- delete 3rd party plugins
The SWTBot plugins are found here: ../workspace/build/downloads/maven-repo/p2/osgi/bundle
Configure the pom.xml files with the appropriate sources.
- There are two pom.xml files to update:
- pom.xml
- com.ddci.openarbor.product/pom.xml
- Update the pom_xml_template in build-utils/generate_build_numbers.py
If you're upgrading to a newer version of a 3rd party plugin (i.e. SWTBot), update pom.xml file to point to new url for latest version of swtbot per the website
Force the download of components (see note below):
- make MAVEN-OFFLINE=""
- make all
- make mavenresolve
- In the maven-repo directory (ie workspace\build\downloads\maven-repo), and zip up everything except
com/and.timestamp. Name it appropriately (ie maven-repo-swtbotn.n.n.zip) and put it in<branch>\BuildResources. - Update the makefile with the new repo name, if necessary.
- In the maven tmp directory (ie workspace\build\downloads\tmp), and zip up the p2 directory. Name it appropriately (ie maven-tmp.zip) and put it in
<branch>\BuildResources.
Note: You will likely need to execute the Makefile using the "-MAVEN_OFFLINE=" at least once to force the download of any new plugins etc. By default, the Makefile is set to only download from the local maven repository in the BuildResources directory.
Install the LDRA Plugins
DDCI Support Case: KLED-BUEK4N
LDRA sent their plugin files that are being used on the Durants program. DDCI is not required to provide any support for issues related to the LDRA plugin; however, in order to foster a good relationship, it would be good to fire up their plug-in anytime you make an update to OA that could potentially impact the plugin's functionality.
I tested the sent plugin files with a harrys dds release I had installed.
I had to make modifications to the config.ini file (see attached copy below)
Lines 3 and 11 are modified from the default OA version.
The supplied LDRA plugins were placed in the OA plugins folder:
Com.ldra.toolsuite_2.7.5.jar
Com.ldra.toolsuite.activeproject_2.0.2.jar
The content of the OpenArbor/configuration/config.ini: (I had to upload it as configIni.txt for the wiki)
Media:configIni.txt
I added "-clean -debug -consoleLog" options to the launching of OA to aid in seeing an errors during the plugin loading process.
Here are the updated plugin files from the customer:
\\nx3000\Deos\support\KLED-BUEK4N_LDRA_plugin_5fRX6pkWzq
I updated the filenames to be correct as indicated by the customer.
After launching OpenArbor, the LDRA plugins are installed and the LDRA perspective can be opened:
Media:ldra-perspective-installed.png
Media:ldra-perspective-opened.png
