Prior to this commit, the following compilation error presented itself
when importing buildSrc ('spring-build-src') into Eclipse:
Groovy:missing type for constructor call @ line 36, column 49.
This commit replaces the use of the diamond operator with typical
generics syntax in order to work around the problem. It is assumed that
the underlying problem is to do with the Groovy compiler in use. This
change ensures that any contributor / committer importing
spring-framework into Eclipse has a straightforward experience without
being required to tweak Groovy settings.
If selection of the correct Groovy compilation settings can be made
automatic, then we should of course feel free to use Java 7-style syntax
there in the future.
Note that this was *not* a problem when importing buildSrc into IDEA 12.
Move code from spring-build-junit into spring-core/src/test along with
several other test utility classes. This commit removes the temporary
spring-build-junit project introduced in commit
b083bbdec7.
Develop a gradle plugin to automatically update testCompile dependencies
to include the test source sets of project dependencies.
Allows the gradle build to more closely mirror the way that tests run
inside eclipse.
Fix deprecation compiler warnings by refactoring code or applying
@SuppressWarnings("deprecation") annotations. JUnit tests of
internally deprecated classes are now themselves marked as
@Deprecated.
Numerous EasyMock deprecation warnings will remain until the
migration to mockito can be completed.
The intention of ExtendedBeanInfo, introduced with SPR-8079 in
v3.1.0.M2, was to support dependency injection against non-void
returning write methods. However, it also inadvertently introduced
support for injection against static setter methods.
When use of ExtendedBeanInfo was made optional with SPR-9723 in
v3.2.0.M2, ExtendedBeanInfo continued to support static write methods,
but its new BeanInfoFactory-based approach to testing whether or not
a given bean class contains candidate write methods was written in a
fashion exclusive of static methods, and this thereby introduced a
regression - a regression in an otherwise undocumented and unintended
feature, but a regression nevertheless.
The reporting of SPR-10115 proves that at least one user has come to
depend on this behavior allowing injection against static write
methods, and so this commit fixes the regression by ensuring that the
candidacy test includes standard and non-void setter methods having a
static modifier.
Issue: SPR-10115, SPR-9723, SPR-8079
Prior to this change, SpEL was capable of handling getter methods for
property names having a lowercase first letter and uppercase second
letter such as:
public String getiD() { ... }
However, setters with the same naming arrangement were not supported,
e.g.:
public void setiD() { ... }
This commit ensures that setters and getters are treated by SpEL equally
in this regard, such that "iD"-style property names may be used anywhere
within SpEL expressions.
Issue: SPR-10122, SPR-9123
* cleanup-3.2.x: (21 commits)
Update Apache license headers for affected sources
Ignore performance-sensitive tests by default
Introduce 'spring-build-junit' subproject
Replace EasyMock with Mockito in test sources
Add @Override annotations to test sources
Update test source and target JDK compatibility
Update -Xlint compiler warning output
Fix various compiler warnings in spring-context
Fix "unnecessary @SuppressWarnings" warnings
Fix [rawtypes] compiler warnings
Fix [dep-ann] warnings with @Deprecated
Fix [cast] compiler warnings
Fix [serial] compiler warnings
Fix [varargs] compiler warnings
Fix warnings due to unused import statements
Replace <code> with {@code} throughout Javadoc
Fix various Javadoc warnings
Replace space indentation with tabs
Remove trailing whitespace in source files
Various updates to support IDEA
...
Make use of the new JUnit functionality introduced in the previous
commit to 'Assume' that perfomance- and timing-sensitive tests should
run only when TestGroup.PERFORMANCE is selected, i.e. when
-PtestGroups="performance" has been provided at the Gradle command line.
The net effect is that these tests are now ignored by default, which
will result in far fewer false-negative CI build failures due to
resource contention and other external factors that cause slowdowns.
We will set up a dedicated performance CI build to run these tests on
an isolated machine, etc.
Issue: SPR-9984
Introduce new 'spring-build-junit' subproject containing shared
JUnit utilities and classes to be used by other test cases. This
project is for internal use within the framework, and therefore
creates no artifacts to be published to any repository.
The initial code includes support for JUnit Assumptions that can
be used to determine when a test should run. Tests can be skipped
based on the running JDK version, logging level or based on specific
'groups' that have activated via a Gradle property.
It is intended that sources within the spring-build-junit project be
folded into spring-core/src/test/java, pending some Gradle work that
will facilitate sharing test output across subprojects; therefore this
commit should be seen as a temporary solution.
Issue: SPR-9984
"test" source and target compatibility has been upgraded to 1.7 except
where noted, allowing us to use 1.7 language features such as
diamond-style (<>) generics declarations, automatic resource management
and multi-catch. More importantly, we will be able to upgrade to 1.8
once it is available in order to make use of lambda expressions, etc in
our test cases.
IDE configurations must be relaxed to allow 1.7 across the board, as
neither Eclipse nor IDEA are clever enough to allow for different
language levels across production and test resources. See [1] for a
feature request on that front.
spring-oxm is a special case here, and has been pinned at 1.6
compatibility even for its test sources in order to avoid a class
verification error that JibX throws when encountering 1.7-level
bytecode [2].
Likewise with spring-orm, toplink encounters a similar class
verification error, so has been pinned to 1.6 for the time being.
When we remove the (already deprecated since 3.2) Toplink support
we can restore compatibility to 1.7.
[1]: http://youtrack.jetbrains.com/issue/IDEA-97814
[2]: http://jira.codehaus.org/browse/JIBX-465
Issue: SPR-10129
Enable output for the compiler warnings that have been eliminated so
far. 'rawtypes', 'deprecation', and 'unchecked' remain suppressed until
these warnings can be fully eliminated as well.
- Suppress rawtypes warnings for src/main
- Enable rawtypes warnings for src/test
This commit attempts to to resolve all rawtypes problems across tests as
aggressively as possible, i.e. without regard for binary compatibility,
whereas main sources must be treated much more cautiously with an eye
toward compatibility.
Fix serialization warnings by applying @SuppressWarnings("serial")
when appropriate.
In certain cases and for unknown reasons, a correctly-placed
@SuppressWarnings("serial") annotation will fix the warning at the
javac level (i.e. the Gradle command-line), but will produce an
"unnecessary @SuppressWarnings" warning within Eclipse. In these
cases, a private static final serialVersionUID field has been added
with the default value of 1L.
Remove the 'final' modifier from SingletonBeanFactoryLocatorTests
to work around the "cannot extend final class" error issued when
running all tests. The error was due to confusion with IDEA between
the two variants of SingletonBeanFactoryLocatorTests across
spring-context and spring-beans.
Rename one of the GroovyMessenger classes to GroovyMessenger2.
Previously there were multiple Groovy classes named
'GroovyMessenger', causing a compilation error in certain IDE
arrangements.
Update import-into-idea.md documentation
Add various IDEA artifacts to .gitignore
- ignore derby.log wherever it is written
- ignore IDEA's test-output directory
- ignore IDEA's Atlassian connector config file
Chris Beams
Phillip Webb
Tom Mack
Sam Brannen