jensdietrich / yamf Goto Github PK

Consider for instance MVNActions::getTestClassFile -- if the target/test-classes exist this will return an instance of File no matter whether the respective class file exists, if the folder does exist, it will return null if FailedExpectationHandler:Ignore is used. This is confusing and for most schemes using this would require two checks: file!=null && file.exists . It would be better to always return null to indicate that the file does not exist to make the API easier to use.

only direct inheritance is supported:
nz.ac.wgtn.yamf.checks.jbytecode.JByteCodeChecks::assertDirectlyExtendsOrImplementsAny

Thus is not straight forward as some representation of the byte code of the project must be passed to analyse the direct super types ! It will prevent some missed marks though.

Tests in classes not ending with Tests? will be ignored.

SHould be able to address this by using the -N parameter, see https://junit.org/junit5/docs/5.0.0-M5/user-guide/#running-tests-console-launcher-options

MVNActions the binary should not be mvn but mvn.cmd

merge functionality of nz.ac.wgtn.yamf.reporting.AbstractSimpleReporter (in core) and nz.ac.wgtn.yamf.reporting.msoffice.AbstractReporter (in msoffice-reporting)

reporters often reference file locations, when absolute paths are used, the name of the marker can often be inferred. It is therefore desirable to remove or replace path elements in order to remove this information

in MVNActions::getProjectClassPath, split by System.getProperty("path.separator") does not work correctly under windows, "\r?\n"

The use case is as follows:

• we want to penalize storing mvn target/ , IDE meta data (.project etc) in the repo
• however, during marking, those files get generated
• rerunning marking scripts will therefore change results (unless the project is cloned and checked out again)
• solution: store those properties in a cache, perhaps inside a .yamf folder