Refer to "Spring Tools" instead of "Spring Tools for Eclipse"

Closes gh-35901

Author: sbrannen

framework-docs/modules/ROOT/pages/core/beans/dependencies/factory-properties-detailed.adoc

@@ -50,9 +50,8 @@ XML configuration:
 
 The preceding XML is more succinct. However, typos are discovered at runtime rather than
 design time, unless you use an IDE (such as https://www.jetbrains.com/idea/[IntelliJ
-IDEA] or the {spring-site-tools}[Spring Tools for Eclipse])
-that supports automatic property completion when you create bean definitions. Such IDE
-assistance is highly recommended.
+IDEA] or the {spring-site-tools}[Spring Tools]) that supports automatic property
+completion when you create bean definitions. Such IDE assistance is highly recommended.
 
 You can also configure a `java.util.Properties` instance, as follows:
 

framework-docs/modules/ROOT/pages/core/beans/java/composing-configuration-classes.adoc

@@ -338,11 +338,11 @@ In the preceding scenario, using `@Autowired` works well and provides the desire
 modularity, but determining exactly where the autowired bean definitions are declared is
 still somewhat ambiguous. For example, as a developer looking at `ServiceConfig`, how do
 you know exactly where the `@Autowired AccountRepository` bean is declared? It is not
-explicit in the code, and this may be just fine. Remember that the
-{spring-site-tools}[Spring Tools for Eclipse] provides tooling that
-can render graphs showing how everything is wired, which may be all you need. Also,
-your Java IDE can easily find all declarations and uses of the `AccountRepository` type
-and quickly show you the location of `@Bean` methods that return that type.
+explicit in the code, and this may be just fine. Note that the
+{spring-site-tools}[Spring Tools] IDE support provides tooling that can render graphs
+showing how everything is wired, which may be all you need. Also, your Java IDE can
+easily find all declarations and uses of the `AccountRepository` type and quickly show
+you the location of `@Bean` methods that return that type.
 
 In cases where this ambiguity is not acceptable and you wish to have direct navigation
 from within your IDE from one `@Configuration` class to another, consider autowiring the

framework-docs/modules/ROOT/pages/core/expressions.adoc

@@ -7,14 +7,14 @@ similar to the https://jakarta.ee/specifications/expression-language/[Jakarta Ex
 Language] but offers additional features, most notably method invocation and basic string
 templating functionality.
 
-While there are several other Java expression languages available -- OGNL, MVEL, and JBoss
-EL, to name a few -- the Spring Expression Language was created to provide the Spring
-community with a single well supported expression language that can be used across all
-the products in the Spring portfolio. Its language features are driven by the
-requirements of the projects in the Spring portfolio, including tooling requirements
-for code completion support within the {spring-site-tools}[Spring Tools for Eclipse].
-That said, SpEL is based on a technology-agnostic API that lets other expression language
-implementations be integrated, should the need arise.
+While there are several other Java expression languages available -- OGNL, MVEL, and
+JBoss EL, to name a few -- the Spring Expression Language was created to provide the
+Spring community with a single well supported expression language that can be used across
+all the products in the Spring portfolio. Its language features are driven by the
+requirements of the projects in the Spring portfolio, including tooling requirements for
+code completion within the {spring-site-tools}[Spring Tools] IDE support. That said, SpEL
+is based on a technology-agnostic API that lets other expression language implementations
+be integrated, should the need arise.
 
 While SpEL serves as the foundation for expression evaluation within the Spring
 portfolio, it is not directly tied to Spring and can be used independently. To