Skip to content

Latest commit

 

History

History
142 lines (124 loc) · 5.78 KB

dev_notes.md

File metadata and controls

142 lines (124 loc) · 5.78 KB

Developer Notes

Controlling Log Levels

To control the log level of a class with a Logger, use properties. For example, use java options:

-Dorg.jlab.detector.helicity.HelicityGenerator.level=FINEST   # sets HelicityGenerator level to FINEST
-D.level=FINE   # sets the level of all loggers to FINE

Alternatively, make a logging .properties file, and set the level of each of your classes for which you want to use a non-default level; use the property name className.level, for example:

# my_levels.properties
org.jlab.detector.helicity.HelicityGenerator.level = FINEST
org.jlab.detector.calib.utils.RCDBProvider.level = FINER

or use .level for the global level:

# my_levels.properties
.level = FINE

To use this .properties file, run with the java option

-Djava.util.logging.config.file=my_levels.properties

Then, here are some examples for using it with recon-util:

recon-util [ARGS] -- -Djava.util.logging.config.file=my_levels.properties   # use your .properties file
recon-util [ARGS] -- -D.level=ALL   # set the global level to ALL (very verbose!)
recon-util [ARGS] -- -D.level=OFF   # silence the loggers

From high to low, the levels are SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST (see java.util.logging.Level documentation). You may also use levels ALL or OFF, for everything or nothing, respectively.

Note

These properties may compete with the log level set by OptionParser's option -l, potentially overriding that level. For example, postprocess and decoder use OptionParser.

Bumping Version Number and Deploying

Deploying a new version requires a new version number, named $VERSION in this document.

  • the release build will have version $VERSION
  • the git repository will have version ${VERSION}-SNAPSHOT
    • note that this is not conventional, since typically -SNAPSHOT is used for upcoming releases

General Procedure

  1. be on a machine from which you have permission to deploy (see deploy-coatjava.sh's scp commands)
  2. git switch development && git pull
  3. make sure you have no local changes (git status)
  4. ./deploy-coatjava.sh -v $VERSION
  5. git push -> open PR -> review PR -> merge
  6. make git tag and release

Note

Should deploy-coatjava.sh fail midway, your git repository may no longer be in the recommended initial state; here's how to revert:

  1. git switch development to switch back to development branch
  2. libexec/version-bump.sh $ORIGINAL_VERSION and be sure to include the -SNAPSHOT; alternatively, git reset --hard
  3. git branch -D version/$VERSION to delete the created version-bump branch

Legend:

  • magenta rectangle: manual step
  • green hexagon: automated
flowchart TB
    classDef manual    fill:#f8f,color:black
    classDef automatic fill:#8f8,color:black

    subgraph deploy-coatjava.sh
        deployScript[deploy-coatjava.sh -v $VERSION]:::manual
        bump1{{bump version to $VERSION}}:::automatic
        deployMaven{{deploy to Maven repo}}:::automatic
        deployTarball{{deploy tarball to clasweb}}:::automatic
        bump2{{bump version to $VERSION-SNAPSHOT}}:::automatic
        gitCommit{{new git branch and commit}}:::automatic
    end
    gitPush[git push]:::manual
    pullRequest[pull request and merge]:::manual
    gitTag[git tag and release]:::manual
    subgraph "Continuous Integration (CI)"
        bump3{{bump version to $VERSION}}:::automatic
        deployGit{{deploy git release tarball}}:::automatic
    end

    deployScript ==> bump1
    bump1 ==> deployMaven
    bump1 ==> deployTarball
    bump1 ==> bump2 ==> gitCommit
    gitCommit ==> gitPush ==> pullRequest ==> gitTag
    gitTag ==> bump3 ==> deployGit
Loading