Skip to content

dev_notes.md

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
Raw

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