My workflow to create / build / deploy / debug a Fesa binary

Create and build the class

• File --> New --> Project --> FesaClass Project creates a new project folder and fesa *.design XML file, according to the selected template (and some eclipe specific files)
• The "insert property" / "insert RT action" wizards are convenient to save some work, though not strictly required
• "Add child"/"Add attribute" menu items on the eclipse XML tree view are used to add all required XML nodes

• FESA specific Toolbar Items:
  • Combo-Box "development/productive/inUse/Integration": Super annoying, I just set it to "development" since that seems to get my XML validated --> Should be dropped
  • "validate" button (or script) to check that the XML is valid. Note: Afaik currently there are XSD rules validated with java-jaxon, Clix Rules and Plain-Java Rules. --> Use XSD1.1 validation in order to port everything to XSD ?
  • "Sync Source Code" --> can be done via fesa3-yocto
  • Now time to tinker on the C++ code
  • "Build" --> can be done via fesa3-yocto
  • "Synchronize Class Doc" --> Superfluous? It is nice to have the doc as well as html ... though personally I never do that step and nobody so far complained.
    • Afaik generates html files out of a fesa design XML file. The "description" XML-elements will be used to give info for all the elements.
    • IMO Sufficient to have the doc only in the XML (and more consistent).
  • "Release" --> Superfluous? I don't use it. Seems to check if the class is in a specific git repo / possibly would create a branch/tag? "Release" IMO is only relevant for a DeployUnit.
  • "Update Fesa Version" --> Replaces the Fesa class version string in the XML file with some new string. Convenient, though not really required … I only use it because eclipse does not like it when I edit that XML entry "by hand".
  • "Export Fesa Class to DB" --> Currently Required. Though could be dropped if a separate script is available
  • "Show Info from FESA DB" --> Superfluous, that as well can be done via webpage: https://websvcpro.acc.gsi.de/groups/cscosv/fesaweb/
  • "Create Deploy Unit" --> Superfluous. Never used that … same as via File --> New --> Project (see below)
  • "Open Associated DU's" --> Superfluous, never used it.
  • "Launch Fesa Explorer" --> Superfluous, only makes sense for DU.
  • "Create Subset" --> Superfluous, never used this, I suppose can be done "by Hand" as well
  • "Handle GSI Conditions" --> Superfluous, never used that, seems to create some XML file with few translated error messages.
    • IMO a horrible idea to get the error numbers and strings from some external dependency.
    • IMO a bad idea to mess with translations on the FEC side.
    • I just ignore that and create my own errors texts and id's ... so far nobody complained.
  • "Show Help" --> Shows help for the selected XML element in the eclipse browser. I don't use it, but it looks handy for newcomers.

Create, build and release the DU

• File --> New --> Project --> FesaDeployUnit Project creates a new project folder and fesa *.deploy XML file, according to the selected template (and some eclipe specific files)
  • Nice, but not really required to select the class via drop-down box ... can as well be added "by hand" later on
• "Add child"/"Add attribute" menu items on the eclipse XML tree view are used to add all required XML nodes

• FESA specific Toolbar Items:
  • "validate" button (or script) to check that the XML is valid. Note: Afaik currently there are XSD rules, Clix Rules and Java Rules. --> Use XSD1.1 validation in order to port everything to XSD ?
  • "Sync Source Code" --> can be done via fesa3-yocto
  • Now time to tinker on the C++ code
  • "Build" --> can be done via fesa3-yocto
  • "Release" --> I use that occasionally (or the yocto script), though currently it is rather cumbersome, so for some classes I currently rather use my own release script
    • Currently seems to:
      • Ask the user if
        • the release should happen for dev/pro/int
        • For which CPU to release (only x86_64 available currently)
        • For which FECs to release
        • If RT-functionality is used on the FEC (Not sure what that checkbox actually does, IMO can be dropped)
        • If some custom timing script should be used (Not sure either on this one --> IMO can be dropped)
        • If some custom shell script should be executed after release (Why do we have a checkbox for that ... just always check if "customRelease.sh" is available and execute it, if so)
        • If "fec comfort functions" should be used. I guess that is about a link in /common/export/nfsinit/ to ../global/cscofe (Link IMO should just always be generated)
      • Optionally (opt out in settings) does check if the DU/Class is in some specific git repo. Afaik it will check if the current working directory is in sync with the HEAD on the remote and exit with error if not so.
        • IMO should be dropped … not the job of the plugin (or some yocto script) to manage git
      • Optionally (opt out in settings) generate the source code
        • IMO rather annoying. If I want to generate code, I use the "gen code" button/script
      • Optionally (opt out in settings) build the project
        • IMO rather annoying. If I want to build things, I use the "build" button/script
      • Optionally (opt out in settings) export to the database for each selected FEC
        • I have it disabled, since I don't see the point in exporting to DEV-DB during development. If I want to export to some DB, I do it explicitly.
      • Creation of directory structure for NFS fesa release folder /common/export/fesa/local/[FEC] for each selected FEC
        • Copies over the binary, instance file, start script to start manually and few other config files
      • Creation of directory structure for NFS fesa release folder /common/export/nfsinit/[FEC] for each selected FEC
        • Creates symlinks to relevant nfs init scripts (timing, fesa, maybe cscofe)
    • In addition IMO, "release" should
      • Create a version specific release folder! [DUName]-[Version] (or [DUName]-master on dev release) ... very important to be able to switch back to older versions without re-build (since rebuild is a pain with Fesa)
      • automatically execute a "custom_release.sh" when available (list of FECs and dev/pro/int as argument) in order to as well release class-specific stuff
  • "Add FEC" --> Used often, creates new FEC folder in the project dir and adds an instance file template. "Clone existing instance" is a very convenient option.
  • "Add Instance" --> Never used, IMO can be dropped (Adds another instance file for a FEC ?)
  • "Promote Instances" --> Needed, updates instance file XML inside the project according to changes in Fesa Class/DU XML
  • "Update Fesa Version" --> Convenient, since the Fesa Version/Class Version/DU Version are present in many XML files.
    • Replaces all occurrences of some version string with some other version string in multiple XML files via XML-Tools
    • Imo not needed to bump versions FEC-specific. Either all of them, or none. (can be done by hand if required)
  • "Export Fesa Class to DB" --> Currently Required. Though could be dropped if "DB export" is part of a pro-release, or if a separate script is available
  • "Show Info from Fesa DB" --> Superfluous, that as well can be done via webpage: https://websvcpro.acc.gsi.de/groups/cscosv/fesaweb/
  • "Create Deploy Unit" --> Superfluous. Never used that ... can create a DU via File --> New --> Project
  • "Open Associated Designs" --> Superfluous, never used it.
  • "Open Associated Instance File" --> Superfluous, never used it.
  • "Launch Fesa Explorer" --> Often used. Automatically generates the zip file which is required for FEX and starts FEX
  • "Create Subset" --> Superfluous, never used this, I suppose it generates some XML-elements which can be added "by Hand" as well
  • "Show Help" --> Shows help for the selected XML element in the eclipse browser. I don't use it, but it looks handy for newcomers.

Debugging and Testing

• For debugging I strongly depend on the "startManually_[DUName].sh" script, which starts my binary without any fuss and allows semi-automated GDB-debugging
• More or less repeat the above steps until everything is in order and the C++ code runs fine

Productive Rollout

• When I think my Fesa Class/DU is ready for productive usage, I set (or bump) the Versions in the XML(s), push git tags to both projects and release it with that version (aka press the "Release" button or exec the fesa-yocto sript)
• On the release location I create a symlink [DU-Name] --> [DU-Name].[Version], so that it is started automatically and call the fesa nfs init script (or reboot)
• If the binary requires some extra config file(s) to run, some additional magic is needed to pass the correct path as argument to the Fesa binary
• Now I export the XML files to the pro-DB (via some script, since the toolbar-button often returns unreadable errors in case of a problem)
• I tell App that they can test the GUI now.