## Why is this an issue?

`@ComponentScan` is used to determine which Spring Beans are available in the application context. The packages to scan can be configured thanks to the `basePackageClasses` or `basePackages` (or its alias `value`) parameters. If neither parameter is configured, `@ComponentScan` will consider only the package of the class annotated with it. When `@ComponentScan` is used on a class belonging to the default package, the entire classpath will be scanned.

This will slow-down the start-up of the application and it is likely the application will fail to start with an `BeanDefinitionStoreException` because you ended up scanning the Spring Framework package itself.

This rule raises an issue when:

- `@ComponentScan`, `@SpringBootApplication` and `@ServletComponentScan` are used on a class belonging to the default package
- `@ComponentScan` is explicitly configured with the default package

### Noncompliant code example

    import org.springframework.boot.SpringApplication;

    @SpringBootApplication // Noncompliant; RootBootApp is declared in the default package
    public class RootBootApp {
    ...
    }

    @ComponentScan("")
    public class Application {
    ...
    }

### Compliant solution

    package hello;

    import org.springframework.boot.SpringApplication;

    @SpringBootApplication // Compliant; RootBootApp belongs to the "hello" package
    public class RootBootApp {
    ...
    }