Clean Up we never hade time for, but should be done
List of To-dos we want to clean up in AP products. Please describe them in a one liner heading and short explanatory description.
Should we create an application database(s)?
Where should we store application specific information? At the moment some of the Application information is stored in the LSA Database. This however complicates merging of changes and change management (like all the differences we introduce). We would prefer to remove tables from LSA that are not relevant for LSA itself.
have been already included in other TODO lists.
It was either moved to the LSA "long term" ToDo
Lsa Development ToDo
Or it was moved to the Backlock as a "short / mid term" Taiga Task:
Remove direct access to OPERDB
Two classes have direct access to the operdb schema using SQL like "select * from operdb.xxx ..." to access tables. This should be removed by either using the operdb connector service or we get rid of the functionality completely if we do not need it. The classes are de.gsi.cs.co.lsa.exploitation.spi.timing.TimingFinderImpl, de.gsi.cs.co.lsa.optics.spi.OpticsFinderGSIImpl
Why are FESA enums not imported properly
Fesa Enums are already Wrong in the FESA Database. The Property-Field should have an 'Enum' type, but already in the FESA DB we see an 'Int' type. Serveral FESA developers ensured me however that they have choosen 'Enum' in the design file. So this is not strictly something we can fix in LSA but something we should discuss / look at with our colleagues.
cleanup LSA codebase
- remove duplicate db column definitions in *ContextFinder / *ContextPersister
- Should we generate the signal type names currently hard-coded in SignalConstants (lsa-domain-gsi) from the database? (Note that signal name postfixes can NOT be generated, there is no information about them in the DB right now! -> Maybe they SHOULD be in the DB? Naming conventions are used for Storage Ring features!!)
- GsiTrimPerformerImpl / GsiParameterNodeProcessorImpl: Raphael suggested that we could create "extension points" for performing various additional checks after trim/for each parameter that could be shared with CERN/always included in the common core. We could then "hook" our checks into those extension points, while CERN could leave them empty. That might be nicer/cleaner/more reusable than extending the Performer/Processor classes.
- Make placing of loops and notifies in CouplingExtension more simple for the lsa core, might be a bit more work for the model though. (probably it should work on marker events placed by the model instead of 'guessing' and 'magicing' the best place for notify/wait loops)
- clean up datamaster core to pattern group assignment mechanism
- clean up TODOs and FIXMEs like "TODO: should be removed after beamtime 2016"
- clean up TimingUtils -> properly define constants in SI and afterwards precalculate them in different (needed) units OR use units framework
- RM: Keep in mind that switching from int/long to float/double may introduce rounding problems that need to be solved.
- clean up ContextService#findStandAloneBeamProcesses - why is this implemented as a default method in the interface? We also implement/override it in ContextServiceImpl.
- check if there is a nicer solution than implementing a "TrimServiceInternal" interface for making the TrimService#driveAfterTrim method accessible from StorageRingModeService (casting to Impl does not work because Spring injects proxy objects because of the transactional functionality)
- clean up JavaDoc, SpotBugs, Checkstyle, PMD
- move classes that are onle needed by make rules to lsa-ext-fair-gsi (e.g. GSIDeviceUtil)
- remove duplicated code from test classes (e.g. make(Non)Resident, (de)couple, ...)
- create utility methods for:
- "context contains Accelerator/ParticleTransfer" (e.g. "Pattern contains SIS18_RING" etc.)
- Clean up importers (maybe switch from liquibase to a unified / pluggable importer system)
- work on bugs.. here: disallow deletion of scheduled BPs (bug 1931)
- Clean up common API (some methods are implemented in LSA and in bss-commons).
- Check if it makes sense to move some code (e.g. Dot Graph Generation) away from LSA into BSS or into a dedicated library that can be used by both.
- make spring beans out of dot file generation extensions but keep them as method scoped variables (no singelton beans)
- rewrite dot generation to provide builders for nodes and edges
- Make sure that we cannot delete a Pattern Group that still contains patterns without BSS being performed (e.g. implement a check that pattern groups cannot be deleted while they still contain patterns, or supply BSS (empty Pattern Group before deleting it), etc. (Note: We should check the state of the Pattern Group in the database, not the state of the Pattern Group provided by the user...)
- Request Processor: As long as we still can disable/enable User Requests: If the REST API is used to change a signal state while user requests are disabled, it currently returns HTTP status code 200 (OK) with a flag rejectedByRequestProcessor=true. Should it instead return a non-OK HTTP status code?
- check if we want to clean up RequestProcessorAdapter#setDisabledByLsaSignals
- LSA trims take very long if the context contains many beam processes that have their length changed by the trim, e.g. initial trim in Scheduling App (8 minutes for ESR pattern with transfer line to Cryring), Energy trim (5 minutes for same pattern). Maybe there is a more efficient way of handling BP length changes?
- check, that in fcc-commons there is really no UI-dependency left
- clean up JavaDoc, SpotBugs, Checkstyle, PMD
- clean up dependencies -> maybe provide a bom defining all versions and excludes
- clean up config files:
- e.g. properties for bss-client-lib (LSA REST endpoint etc.) in default.properties
- find better solution for describing ParticleTransfer ordering
- use JGraphT
- find a solution for including the cooler particle transfers
- find a solution for ordering between multiple successors - e.g. if we had RING => PT_A and RING => COOLER, we may want to see RING => COOLER => PT_A etc.
- maybe also relevant for multiple sources, e.g. at UNILAC or Cryring
remove src/main/java entry in the pom.xml, restructure the project
remove javafx dependency, restructure
remove corresponding excludes, e.g. in common-remotelauncher-service
create lsa-utils-lib in fcc-commons, move all non-UI logic there
Packaged Name Renaming
Rename all the old package names to have a clear and consistent naming schema
RBAC-mock-ui GSI dummy implementation: adapt to CERN's newest version
- Document the current state of our release process (= clean up/mark as deprecated all pages containing obsolete information)
- update to JUnit 5
- Configure Checkstyle so that it does not show errors after applying the automatic formatting