Polishing

spring-context/spring-context.gradle

@@ -34,8 +34,8 @@ dependencies {
 	testCompile("org.codehaus.groovy:groovy-test")
 	testCompile("org.codehaus.groovy:groovy-xml")
 	testCompile("org.apache.commons:commons-pool2")
-	testCompile("javax.inject:javax.inject-tck")
 	testCompile("org.awaitility:awaitility")
+	testCompile("javax.inject:javax.inject-tck")
 	testRuntime("javax.xml.bind:jaxb-api")
 	testRuntime("org.glassfish:javax.el")
 	// Substitute for javax.management:jmxremote_optional:1.0.1_04 (not available on Maven Central)

spring-context/src/test/java/org/springframework/context/annotation/ConfigurationClassPostConstructAndAutowiringTests.java

@@ -1,5 +1,5 @@
 /*
- * Copyright 2002-2019 the original author or authors.
+ * Copyright 2002-2021 the original author or authors.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -25,7 +25,6 @@ import org.springframework.beans.testfixture.beans.TestBean;
 
 import static org.assertj.core.api.Assertions.assertThat;
 
-
 /**
  * Tests cornering the issue reported in SPR-8080. If the product of a @Bean method
  * was @Autowired into a configuration class while at the same time the declaring
@@ -34,7 +33,7 @@ import static org.assertj.core.api.Assertions.assertThat;
  * 'currently in creation' status of the autowired bean and result in creating multiple
  * instances of the given @Bean, violating container scoping / singleton semantics.
  *
- * This is resolved through no longer relying on 'currently in creation' status, but
+ * <p>This is resolved through no longer relying on 'currently in creation' status, but
  * rather on a thread local that informs the enhanced bean method implementation whether
  * the factory is the caller or not.
  *