Develop Reference

Is #SpringBootApplication able to find and AutoConfigure all dependency's beans without META-INF/spring.factories?

Why do we need META-INF/spring.factories when create starters for Spring Boot applications? What if omit it at all or leave empty?
Doesn't the target application's #SpringBootApplication which is
a combination of three annotations #Configuration (used for Java-based
configuration), #ComponentScan (used for component scanning), and
#EnableAutoConfiguration
scan everything and find all beans from all the starters with no help of META-INF/spring.factories?

Component Scanning would scan the packages that you give it. You could technically tell it to scan all the packages of your dependencies, too, and it would start loading up any beans defined in them. If you don’t specify any packages to scan, then Spring will use the base package where the annotation is applied, which would very likely not include beans defined in any dependency libs.
There’s another layer to this- a lot of the libraries you use may be using annotations like “#AutoConfigureBefore” to give spring instructions on the order of bean creation. Component Scanning will not respect that, which could result in some weird behaviors if some dependency tries to override a bean from another which is annotated with #ConditionalOnMissingBean (I.e. create this bean only if it doesn’t exist.) You could easily end up with name collision issues where that bean actually gets created first, and then the override bean is created, too.
So the answer seems to be no. You need spring.factories.

Doesn't the target application's #SpringBootApplication scan everything...
No, it doesn't scan everything because if it was it could take a lot of time and resources. Think about it in a way that in order to understand whether the file with an extension *.class contains a bean (something annotated with #Component for example) it needs at least to read a class and analyze the byte code or even load it into memory to check the annotation by reflection.
So if your application's root package is in com.sample.app (the package with the class annotated with #SpringBootApplication), then spring boot by convention scans only the beans in this package and the packages beneath it. This means that it won't scan any thirdparties (assuming they won't be placed in com.sample.app anyway).
Now Its true that you can change the rules of component scanning, but again, you don't want to scan everything for performance reasons at least.
So Autoconfiguration modules (technically implemented with META-INF/spring.factories can specify an additional place (classes annotated with #Configuration) that spring boot will load despite the fact that they are not placed under the packages of your application
or, in other words, they do not obey the default component scanning rules.
In addition, spring.factories file allows to specify much more than auto configuration rules, you can specify environment post processors there for example, and other stuff that can be useful for your application, probably mostly beneficial at the level of application infrastructure, but still.

Internal Implementation of IOC and DI in Spring Boot

Whenever spring boot application runs it sees the #SpringBootApplication annotation and runs the #ComponentScan which scans the classes with the annotations such as #Component etc and makes the object in the container.I have a little bit of idea that it might be using reflections internally to create the objects but I am not able to connect all the dots .I want to know what exact information does #AutoConfiguration gives to the container that it is able to get all the information of all the component annotated clases of any component ?
P.s. I have edited the wrong question

First of all #AutoConfiguration is responsible for setting up the default configurations for a Spring boot application depending on the dependencies we have added in the pom.xml.
The thing you are looking for is #ComponentScan which is what performs the component class scanning within the default package and all of its sub packages. It does this by going through each class in the package and looking for the #Component,#Service or #Repository annotations. If any of them is present then the container adds this as a bean.
#SpringBootApplication internally has the #ComponentScan annotation added to it along with two others.

How to find entry point of a Spring Boot application?

What is the entry point of a spring boot application?
While going through a Spring Boot application code, all that it says is there is a code
public static void main having - SpringApplication.run(Application.class, args)
Example - SpringBoot2RestServiceApplication.java .
But how to get to know what is the entry point, just by going through the code. Earlier, if we go through applicationContext.xml - example - applicationContext.xml, we could understand the flow.
Is there any way, or maybe a standard to follow to make this understanding self-explanatory?
My question was more of understanding the flow of the application than finding the main class. One option could be separating configurations(#Configuration) to a separate class having multiple #Bean annotations, this would help in finding all bean wirings at one place. Is there a standard that large projects use to make code flow understandable?

The easiest thing to do would probably be to search for #SpringBootApplication in your code.
But, a guaranteed way to get this information would be to build the Spring Boot JAR. From there, you can open the resulting JAR and find the main class defined in the manifest, under META-INF/MANIFEST.MF. You'll see it under the Start-Class attribute:
Start-Class: com.example.foo.Application

I think the OP is studying an existing Spring Boot application, and is asking how to locate any runner, such as Application Runners, Command Line Runners, MVC controllers, Rest controllers, etc.
I don't know if there is an easy way to locate those, unless they are grouped together in the original design.
It's a difficult problem to do programmatically, because threads can be launched outside of Spring, for example in a constructor or a #PostConstruct.
It would be nice though if there were IDE support to easily locate anything that gets launched by Spring Boot

search #SpringBootApplication annotation in your project, the class with #SpringBootApplication annotation will automatically do the component-scan for the sub packages.
if no #SpringBootApplication annotation found, search the class extending "SpringBootServletInitializer" which is also a starting point for the spring boot application

The Entry of any spring boot application has an annotation of #SpringBootApplication

Spring - separate directory for controllers

I'm a newbie in Spring and have one question about inserting all controllers in another directory than an executable spring boot file.
This tutorial
I have to have GreetingController.java and Application.java in one directory because if not, then I can't run mvn spring:boot-run
Is there a way to have Application.java in /java directory and all controllers in /java/controllers? Can I create some config file to inform Application.java where all the files are?
Thank you

I am little bit confused. But first point - It is good to have all controllers in separate directory, it is best practise, but better is using /rest directory.
Second point - You have to define application context and enable few things (for example via annotation). Try to look here http://docs.spring.io/spring-boot/docs/current/reference/html/using-boot-structuring-your-code.html, here you can see annotations and basic structure.
For you, set this annotations to your Application.java:
#Configuration
#EnableAutoConfiguration
#ComponentScan
More information and where to write it you can find in link what I posted.
If you configure application context and you set EnableAutoconfiguration and ComponentScan, Spring will look up for all annotated components and your controllers (if you annotated you controller class by #Controller annotation.

What is the difference between the use of #Import and #ImportResource annotations in Spring framework?

I am studying for the Spring Core certification and I have a doubt related to the #import and the #importresource annotations use.
So for example I have a configuration class named RootConfig.java, this one:
#Configuration
#Import({AppConfig.class,DbConfig.class})
#ImportResource("classpath:/config/security-config.xml")
#EnableTransactionManagement
public class RootConfig {
}
So I know that in this example the:
#Import({AppConfig.class,DbConfig.class})
are importing 2 others configuration classes (something like including these configurations into the main configuration represented by my RootConfig.java configuration class.
Ant I understand that the:
#ImportResource("classpath:/config/security-config.xml")
are importing an XML file.
So my doubt is: why exist 2 differents annotations that do a very similar task? Why don't use a single annotation to import both configurations classes and resources (such as xml files or property files?)
This is only a semantic differentiation or there are something else?

#Import
Indicates one or more #Configuration classes to import. For import Java code-based configuration. e.g.
#Configuration
#Import({ DataSourceConfig.class, TransactionConfig.class })
public class AppConfig { ... }
See more in Using the #Import annotation.
#ImportResource
Indicates one or more resources containing bean definitions to import. For import XML-based configuration or other non-#Configuration bean definition resources. e.g.
#Configuration
#ImportResource({"classpath:spring-security.xml"})
public class SecurityConfig { ... }
See more in #Configuration class-centric use of XML with #ImportResource.

#ImportResource is meant to be used in java-centric configuration context. The docs say,
In applications where #Configuration classes are the primary mechanism
for configuring the container, it will still likely be necessary to
use at least some XML. In these scenarios, simply use #ImportResource
and define only as much XML as is needed. Doing so achieves a
"Java-centric" approach to configuring the container and keeps XML to
a bare minimum.
One important aspect is that when using #ImportResource XML configuration you can override the java-centric configuration using the #Bean annotation. This means that you can override the configuration (by changing the configuration XML) without impacting the code. This semantic gives you one context where you can consider using #ImportResource, and its in my view a very valuable asset 'cause one of the most common critique of the java-centric configuration is that it requires code recompile.
The second context is providing the means to gradually move from the XML centric to a java-centric configuration.