stuie / papercut Goto Github PK

After annotating a class/function/variable in Java file with @debt, running mvn clean install doesn't generate any warning about tech debt.
POM is updated with both dependencies for compiler and annotations v 0.9.1

Use the values of addedDate, reason, and description from @Debt annotations when present.

Ideally they should be logged during the build, or as part of a separate task that prints a report.

I need something for find all code that need refactoring or delete. How I can do this?
Maybe you will do integration with TODO plugin? Or create new way for find @refactor and @removethis.

Something like this:

Generate documentation with Dokka and publish it via gh-pages branch on GitHub.

It would be nice to have it generated via GitHub Actions.

This is very similar to #1 but I think it would be great if the build were to fail if you were to be in the release build flavor of the Android build, but would otherwise be fine on debug builds.

You could achieve it in a similar way to LeakCanary where the user could have a debugCompile which uses the no-op version of the library, and releaseCompile where it uses the normal version of the library.

Annotations should support Java 8 to avoid warnings when used in projects that use Java 8

Warning:Supported source version 'RELEASE_7' from annotation processor 'ie.stu.papercut.compiler.AnnotationProcessor' less than -source '1.8'

👋 After updating our app to Kotlin 1.6, we started getting the following build warning:

The following annotation processors are not incremental: papercut-compiler-0.9.1.jar (ie.stu:papercut-compiler:0.9.1).
Make sure all annotation processors are incremental to improve your build speed.

It seems incremental builds of the app are now performing a full build because of this. I think updating this library to use Kotlin 1.6 will resolve this.

compile: 'ie.stu:papercut-annotation:0.0.4' => please add "s" trailing symbol to "-annotation"

Hi,

It would be nice to be able to process these annotations with PMD and get an estimated cost (e.g in minutes) of fixing them (debt). What do you think?

Replace the @Refactor and @RemoveThis annotations with a new @Debt annotation.

The @Debt annotation should have the following values regardless of usage mode:

value - A one-liner that describes what the annotation is highlighting. This should be something like the first line of a git commit message.
reason - A reason for adding the tech debt instead of addressing it during development.
description - A more in-depth description of what is being highlighted.
id - An identifier for this debt. Most likely this will be a GitHub issue number, a Jira story/epic/task ID, or a URL that points to where this debt is being tracked.
cost - What is the cost estimate of adding this debt? TODO Determine how to handle units, integrate with other systems. Time in minutes? Complexity points? T-shirt sizes?
addedDate - The date on which the debt was added to the codebase, in YYYY-MM-DD format.

When Papercut is being used in a more aggressive manner, the following values can be used together to break the build:

stopShip - Setting this to true will break the build, setting it to false will result in a warning, defaults to false.
removalDate - The date by which the tech debt should be removed.
milestone - The milestone by which the debt should be removed (see @Milestone).
versionCode - An integer that increases with each build/release of your product (e.g. Android's versionCode) by which the debt should have been removed.
versionName - A semantic versioning string (e.g. 3.1.4) by which the debt should have been removed.

I have a few use cases where I think a generic annotation like @todo makes more sense than @removethis or @refactor. For example, when I do a release build but forget to change the placeholder strings resources to final ones.

Thanks!

The description string might be very long, and may not be suitable for typical build output. Only print it if it's explicitly requested.

By default Papercut assumes stopShip = true and fails the build if anything is annotated. I suggest to add some kind of global configuration option to invert this behavior. Instead, don't fail the build unless stopShip = true is specified.

I understand that such option is opposing the initial idea that probably made you develop this but I see myself taking advantage of such thing if the behavior is inverted.

Just a suggestion :)

#goodjob

Include as many AnnotationTargets as make sense to be flagged as debt, or a milestone.

Pretty much anything can be Debt. These are the options:

    /** Class, interface or object, annotation class is also included */
    CLASS,
    /** Annotation class only */
    ANNOTATION_CLASS,
    /** Generic type parameter (unsupported yet) */
    TYPE_PARAMETER,
    /** Property */
    PROPERTY,
    /** Field, including property's backing field */
    FIELD,
    /** Local variable */
    LOCAL_VARIABLE,
    /** Value parameter of a function or a constructor */
    VALUE_PARAMETER,
    /** Constructor only (primary or secondary) */
    CONSTRUCTOR,
    /** Function (constructors are not included) */
    FUNCTION,
    /** Property getter only */
    PROPERTY_GETTER,
    /** Property setter only */
    PROPERTY_SETTER,
    /** Type usage */
    TYPE,
    /** Any expression */
    EXPRESSION,
    /** File */
    FILE,
    /** Type alias */
    @SinceKotlin("1.1")
    TYPEALIAS

These seem like good choices:

CLASS,
PROPERTY.
FIELD,
LOCAL_VARIABLE,
VALUE_PARAMETER,
CONSTRUCTOR,
FUNCTION,
PROPERTY_GETTER,
PROPERTY_SETTER,
TYPE,
EXPRESSION,
FILE,
TYPEALIAS,

Not everything makes sense as a Milestone. These seem like good choices:

PROPERTY,
FIELD,
LOCAL_VARIABLE,

Would be awesome if this supported failing the build when a certain app version is reached:

@RemoveThis(version = "1.0.1")

The reason for the failure should be mentioned in the output. Currently there's no mention of versionCode or versionName in the output, but they can still cause the failure.