1. LSA/InCA changes during LS1

2. LSA/InCA state during LS1
Keep the existing released versions of all LSA/InCA modules
We frozen these versions in a dedicated SVN branches
The PRO database won’t be changed and all LSA/InCA servers will be up and running
Until the moment when we complete all the modifications
We’ll not release anything as PRO except blocking fixes for LN4 or CTF

3. LSA DB schema change Why What Impact
Automate synchronization between CCDB and LSA DB
Improve lifecycle management of devices and parameters in LSA DB
Add support for missing setting types i.e. enum arrays
What
Change of LSA DB schema
First NEXT and TEST DB, later PRO DB
Impact
No need to change the code
Some attributes will be added to certain domain objects
Code from SVN Trunk won’t work with PRO DB
Released PRO code won’t work with NEXT DB

4. Repackaging of LSA modules
Why
Currently 18 modules
8 are necessary on the client side  compatibility issue between them
Not easy to setup and maintain the development environment in Eclipse
Especially for people from outside of the LSA team who contribute to the code
What
Client side  lsa-client, lsa-domain, lsa-domain-cern
Server side  lsa-core, lsa-core-cern
Impact - all apps depending on LSA
Remove dependency on the old packages from product.xml
Keep dependency only on lsa-client
Re-release to use the new products

5. LSA Client APIs cleanup
Why
The LSA API is huge and was growing over the last 10 years
There are a lot of deprecated and obsolete methods
Some of them were deprecated long time ago but are still in use
For a few different reasons
Some Domain Objects are not in the most logical java packages
Some methods are not in the most intuitive Client Controllers
What
Remove unused methods
Move some Domain Objects to different Java packages
Move some methods between Client Controllers
Deprecate methods that we want to suppress  in the first step
Remove deprecated methods  in the second step
Impact
The existing functionality won’t be removed but you might need to update your code to:
Fix the import of domain objects
Use the same method but from another Client Controller
Use another method

6. Suppress Context User Group concept
Why
Concept introduced about 7 years ago to have a dedicated set of cycles meant for “Expert Settings”
But finally it was used only partially in SPS
Complicates unnecessarily the API
What
The Context User Group selection will disappear from GUIs
The corresponding methods will be deprecated in the first step and removed in the second step
e.g. findCycles(String accelerator, String usergroup)
Impact
Applications have to adapt to not use the deprecated methods
The client code will simplify

7. Move Working Sets and Knobs configuration from CCDB to LSA DB
Why
The content of WS and Knobs is driven by LSA parameters
But the GUI layout and several attributes are in CCDB
Some of them are obsolete
Some of them are duplicates of what we already have in LSA DB
LSA DB is more natural place to keep also this config  one place to configure everything
What
The Working Set content (devices) and meta-properties will be moved to LSA DB
japc-ext-dirservice APIs will be adapted to fetch data from LSA DB rather than from CCDB
Impact
Any application which uses directly CCDB API or SQL to fetch info about WS and Knobs  adapt to use InCA APIs

8. Release plan Release the modifications in Q3 2013 as NEXT
For early adopters who want to test it using LSA NEXT database
Release the modifications as PRO in Q4 2013
At the same time update PRO database schema and redeploy all LSA and InCA servers
We’ll also provide a documentation (JavaDoc + Wiki) describing the changes
From this moment on – all applications can follow and adapt
Release again as PRO in March 2014
Deprecated methods will be removed