2020-06-01: Release 15 for DryRun on 8th June

1 Introduction

Dear ACO Community,

in preparation for the next dry run on 8th June we will release and rollout our software stack in the weeks before. This is ACO release "r15" which was post-poned a bit since we do not do major releases during beam-time.

This release has to include all API changes that affect the whole controls software stack, e.g. everything that does not only affect LSA but also the applications. Just to name a few things that affect the stack (as an example): New timing events or timing zones, particle transfers, accelerator zones or beam process purposes.

LSA will have major changes related to our merge with the latest CERN codebase, especially around parameter types (including changes to domain objects), and in preparation of the Oracle database migration from version 12.1 to 19c. Also the LSA Rest interface v1 (https://restpro00a.acc.gsi.de/lsa/client/v1/) was deprecated and will be removed, please use v2 instead.  

We recommend to test thoroughly.

According to the current beam time schedule, there will be no further breaks or shutdowns. We need to prepare the whole dry run / r15 release during beam-time and/or machine experiments. So the current dry run evironment will probably be prepared in the integration system, to not impact the current production environment.

Thank you all for contributing!



2 Roadmap for release 15

The proposed release timeline looks like this:


11th May: As you see, after 11th May we will start moving the development and integration environment to the new codebase and merge. So please try not to commit big changes during this time to the master / int branches. If possible keep changes on your own branch until we are finished.
master / int branches will be incompatible with r14 branch after this point!
18th May: You test and adapt your software.
25th May: Final branching of all software for release r15.

3 Java Build System

3.1 Updated Maven Parents

The Maven parents provided by ACO have been released in version 15.0.0-SNAPSHOT for the current development version:
  • csco-parent
  • csco-parent-java
  • csco-parent-java-service (replaced by csco-parent-java-bundle)
  • csco-parent-java-bundle

Please check all your projects to see whether you use our Maven parents, and if yes, update them to 15.0.0-SNAPSHOT for the development version of your application.

Here is an example:

Note that a 15.0.0 version (without "-SNAPSHOT") to be used in production will not be provided yet, but in the first week of June when the R15 release takes place. Nevertheless, it is vital that you check whether your application still works properly with the new Java / library versions beforehand.

3.2 Updated default Java version

The default Java version for source code has been updated to Java 11 (the compilation target was already Java 11). Please test that your artifacts are still compiling and running with the new Java version setting: mvn clean compile exec:java


The RBAC replacement at GSI (accsoft-security-rba-util-gui-gsi) was not updated, since it will not be used any more, and is now incompatible with the recent RBAC implmenetation. It is foreseen to use the real RBAC library starting in 2020.

So this dependency will not work anymore:

We switch to using the full RBAC implementation, therefore please use:


If you get RBAC login pop-ups for some applications you just have to press "Cancel".


Service/Class/Method How to migrate

Get class design information from parameter:







Find parameters of certain device-type property fields triplet.
It was possible to search by collection of parameter type names if they are in the form of <device class>/<property>#<field>:

parameterService.findParameters( ParametersRequestBuidler.byParameterTypes( parameterTypeNames ) )

It is still possible to search by parameter types, while it is not really correct for the cases when the search actually should be done by device design information.

When the search should be done by device design infromation:

propertyFields = deviceService.findPropertyFields(PropertyFieldsRequest);
parameterService.findParameters( ParametersRequestBuidler.byPropertyFields( propertyFields ) )
contextService.findCoupledPatterns(patternGroupPatterns); storageRingModeService.findCoupledPatterns(patternGroupPatterns);
SuperCycle deleted
CommonSettingService.findContextSettings(...) CommonSettingService.findContextSettings(ContextSettingsRequest)
SettingFinderGSI.findKnobComponentInterpolation(String opticsTableName, String knobName, String componentName) OpticFinderGSI.findKnobComponentInterpolation(String opticsTableName, String knobName, String componentName)

6 Miscellaneous

Change How to migrate
Dependency to org.apache.commons:commons-lang is not provided anymore Replace usages of org.apache.commons.lang.StringUtils to org.apache.commons.lang3.StringUtils for example. But after adding the dependency, optimize imports should take care of it.

Add dependency to more recent dependency directly if needed (should be provided by lsa-core)

    <version>3.8.1</version> <!-- LSA Version, verify if already available by now and use it instead of your own -->
If using Batik for SVG parsing: Some packages (e.g. org.w3c.dom) may be found twice (in named and unnamed modules).

Add exclusions to Batik dependency:


7 Tests

App test documentation
Topic revision: r13 - 13 May 2020, BenjaminPeter
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback