ascopes / katana-old Goto Github PK

When processing an annotation mirror, it appears that annotation attributes left as default values and unspecified explicitly do not appear in the mirror of that annotation.

Investigate whether I could use this as the mechanism for default values.

If this works:

• I can replace Toggle with a boolean.
• Default attributes can replace the DefaultValue annotation (leaving just ImmutableDefaultValue and MutableDefaultValue).
• We no longer will need INHERITED in enums.

Remove use of automatic modules and use explicit module declarations instead.

This may require baselining at Java 9, 10, or 11 instead of 8.

This will also require #17 to be able to be tested properly, I guess.

I want to be able to define a custom annotation that is annotated with Settings and allow it to be detected from the alias.

This will allow me to enforce standard settings on projects that share a common library without redefining my desired settings per project.

E.g.

@Settings(
    className="*Impl",
    packageName="*"
)
@Documented
@Target({TYPE, PACKAGE})
public @interface UseCommonKatanaSettings {
}

I may want to be able to specify defaults for mutable and immutable types separately. This could be achieved using something similar to:

@ImmutableModel(
    @Settings(
        className="*Impl",
        packageName="*"
    )
)
@Documented
@Target({TYPE, PACKAGE})
public @interface UseCommonKatanaSettings {
}

Remove Google Compile Testing dependency, and add test utility to perform Java 9-compatible module-based compilation in tests instead.

I propose to disallow the use of ImmutableModel and MutableModel on packages and to remove the Settings within that annotation.

Instead, I propose to make Settings repeatable, and to add a member "target" to define whether to apply to a Mutable or Immutable model or both.

E.g.

@Settings(
    target=ImmutableModel.class,
    className="Frozen*"
)
@Settings(
    target=MutableModel.class
    className="Mutable*"
)
package my.company.models;

The "target" member would then be defined as follows:

Class<? extends Annotation>[] target()
    default { ImmutableModel.class, MutableModel.class }

The settings annotation itself would be updated to have the @Repeatable(SettingsList.class) and a new annotation would also be defined:

@Retention(SOURCE)
@Target({PACKAGE, TYPE})
public @interface SettingsList {
    Settings[] value();
}

The SettingsResolver would need updating to accommodate for this type.

This would likely change the solution to #4 slightly.

Integrate checkerframework annotation processor.

Required dependencies:

      <dependency>
        <!-- Checkerframework annotation processor. -->
        <groupId>org.checkerframework</groupId>
        <artifactId>checker</artifactId>
        <version>3.19.0</version>
        <scope>provided</scope>
      </dependency>

      <dependency>
        <!-- Checkerframework JDK 8 support. -->
        <groupId>org.checkerframework</groupId>
        <artifactId>jdk8</artifactId>
        <version>3.19.0</version>
        <scope>provided</scope>
      </dependency>

Will need to move the META-INF/*Processor file into gen and get build-helper-plugin to move it once compilation has completed so that we can re-enable annotation processing on the katana-annotation-processor module again...

Codegen for the settings descriptors and checkstyle appears to run after tests as well as before, which is unnecessary.

I want to be able to use annotations similar to ones like @Equality.Include which, when used, will allow the generated class to implement Comparable.

This should also be applied if the interface extends comparable and does not provide a default implementation for compareTo.

When implicitly including all attributes, only those that implement comparable internally, or are primitive, should be considered.

The include annotation may want to allow the specification of either an int-returning binary operator, or a method that returns the corresponding comparator.

If it does not implement Comparable on an interface level, it should allow the use of an annotation such as @Comparison.Custom to allow specifying a custom static compareTo method (with signature static int compare(T t1, T t2), OR to annotate a static comparator field, OR to annotate a custom static comparator-returning method with signature static Comparator<T> comparator();