Provide a mechanism to configure the source sets to which Java Format is applied

[jzheaux]

If I create a project that uses io.spring.javaformat and also the needed Boot and other plugins to support AOT compilation, then ./gradlew check and ./gradlew format fail. This ticket focuses on making ./gradlew check work.

Spring JavaFormat seems to scan the AOT-generated directories for formatting and checkstyle issues resulting in the following error on a vanilla AOT project that also uses JavaFormat:

...
  * build/generated/aotSources/org/springframework/boot/autoconfigure/ssl/SslProperties__BeanDefinitions.java
   * build/generated/aotSources/org/springframework/boot/autoconfigure/ssl/SslAutoConfiguration__BeanDefinitions.java
   * build/generated/aotSources/org/springframework/boot/autoconfigure/availability/ApplicationAvailabilityAutoConfiguration__BeanDefinitions.java
   * build/generated/aotSources/org/springframework/context/event/DefaultEventListenerFactory__BeanDefinitions.java
   * build/generated/aotSources/org/springframework/context/event/EventListenerMethodProcessor__BeanDefinitions.java
   * build/generated/aotSources/org/springframework/aop/framework/autoproxy/InfrastructureAdvisorAutoProxyCreator__BeanDefinitions.java
  
  Run `format` to fix.

Running checkFormat is not ideal against AOT sources since they don't follow the formatting guidelines. Also, I don't need to ensure that they follow my checkstyle rules.

I can fix this by disabling the corresponding tasks:

	tasks.matching { it.name == 'checkFormatAot' }.all { task ->
		task.enabled = false
	}

	tasks.matching { it.name == 'checkFormatAotTest' }.all { task ->
		task.enabled = false
	}

	tasks.matching { it.name == "checkstyleAot" }.all { task ->
		task.enabled = false
	}

	tasks.matching { it.name == "checkstyleAotTest" }.all { task ->
		task.enabled = false
	}

It seems the ideal would be that these tasks not exist, but I'm not sure what is reasonable to change.

For additional context, this comes up in the Spring Security Samples project, where we use JavaFormat to keep the samples uniform. When we recently added an AOT sample, we ran into this behavior.

[wilkinsona]

Unfortunately, Spring Java Format doesn't know anything about AOT and nor should it. Creating that knowledge would introduce a cycle between Java Format (which would have to know about the AOT plugin and source set created by Spring Boot) and Spring Boot (which uses Spring Java Format). Instead, I would recommend that you avoid this either as you have shown above or in the same way as other projects have done in the past. For example, the AOT smoke tests update the start parameters to exclude the unwanted tasks from execution.

[wilkinsona]

I've just remembered that Framework adds an annotation to AOT-generated classes to indicate that they've been generated and wondered if we could use this to skip the source when checking it. Unfortunately, this isn't a general-purpose annotation but org.springframework.aot.generate.Generated. Looking for this would therefore introduce a cycle as Framework uses Spring Java Format in its build.

That said, the Checkstyle configuration already has some knowledge of Framework types so maybe it's not a concern.

[wilkinsona]

I think we should provide a mechanism to configure the sources sets to which Java Format is applied. That could then either be used manually in projects that both apply Java Format and use AOT or perhaps we can explore ways of somehow doing it automatically. For example, Spring Boot's Gradle Plugin could react to the combination of Java Format and AOT by configuring Java Format to ignore the aot source set.

[philwebb]

I think a SourceSet is extension aware so I wonder if we can attach a general purpose ext.generated = true attribute in Spring Boot which we could then use to filter them out.