QUE: What is the difference between Spring Boot and the Spring

framework?
ANS:
Spring framework is a Injection dependency framework at first targeting managing life-cycle of
Java components (beans). Today, Spring framework is pretty bloated with tons facilities/helpers
on top of it. But if you look at the big picture, it is still a framework that glue things together, a
middle man to MVC frameworks (Struts 1,2, JSF etc), ORM frameworks (Hibernate, iBatis, JOOQ
etc) and other necessary facilities (Quartz, Email, you can tell, whatever you need, most likely,
there's a Spring support). It takes quite a lengthy tutorial to set Spring framework up and
running because Spring framework nature is to provide flexibility of choices to you.
Spring boot on the other hand is built on a totally different mantra. It's basically a suite, pre-
configured, pre-sugared set of frameworks/technologies to reduce boiler plate configuration
providing you the shortest way to have a Spring web application up and running with smallest
line of code/configuration out-of-the-box. As you can see from there Spring Boot page, it took
less than 20 lines of code to have a simple RESTful application up and running with almost zero
configuration. It definitely has a ton of way to configure application to match your need.

The basis of Spring Spring Boot

comparison
Between
Spring vs
Spring Boot

Configuration To design any spring based application, a
developer needs to be taken care on
manual set up on Hibernate data source,
Entity Manager, Session Factory,
Transaction Management everything.
To Design all those common set up, a
developer doesn’t need to define
everything individually,
SpringBootConfiguration annotation
enough to manage everything at the
time of deployment.

XML Spring MVC application some of the XML Configuring Spring Boot Application
definition mandatory to manage. nothing needs to be managed, the
only annotation managed everything.

Controlling As configuration can be easily handled by In case of Spring Boot, it automatically

manually, so Spring or Spring MVC can handled on default loading part, so the
 manage to not loading some of the developer doesn’t have as such
unwanted default features for that concept of not loading some of the
specific application. specific unusable spring default
features.

Use Better to use if application type or
characteristics are purely defined.
Better to use where application type
of functionality for future use not
properly defined. As integrating any
Spring specific feature will be auto-
configured in here, so no need any
additional configuration.

QUE: MAVEN LIFE CYCLE

ANS:

Maven Life Cycle:

"Maven is based around the central concept of a build lifecycle. What this means is that the
process for building and distributing a particular artifact (project) is clearly defined."
" For the person building a project, this means that it is only necessary to learn a small set of
commands to build any Maven project, and the POM will ensure they get the results they
desired."
Apache Maven Project - Introduction
There are three built-in build lifecycles:
1. default lifecycle handles project deployment.

2. clean lifecycle handles project cleaning.

3. site lifecycle handles the creation of project's site documentation.

Default lifecycle:
The default lifecycle has the following build phases:

1. validate: validate the project is correct and all necessary information is available.
2. compile: compile the source code of the project.
3. test: test the compiled source code using a suitable unit testing framework. These tests
should not require the code be packaged or deployed.
 4. package: take the compiled code and package it in its distributable format, such as a
JAR.
5. integration-test: process and deploy the package if necessary into an environment
where integration tests can be run.
6. verify: run any checks to verify the package is valid and meets quality criteria.
7. install: install the package into the local repository, for use as a dependency in other
projects locally.
8. deploy: done in an integration or release environment, copies the final package to the
remote repository for sharing with other developers and projects.
These lifecycle phases (plus the other lifecycle phases not shown here) are executed
sequentially to complete the default lifecycle.

To do all those, we only need to call the last build phase to be executed, in this case, deploy:

That is because if we call a build phase, it will execute not only that build phase, but also every
build phase prior to the called build phase.
mvn clean install
The following command tells Maven to do the clean action in each module before running
the install action for each module.

In other words, mvn clean install clears any compiled files we have, making sure that we're
really compiling each module from scratch.

Note that clean is in a separate lifecycle, so it's not called by default.

A target folder holds Maven-generated temporary files and artifacts. There are times when the
target folder becomes huge or when certain files that have been cached need to be cleaned out
of the folder. The clean goal accomplishes exactly that, as it attempts to delete the target folder
and all its contents.

Maven goals vs phases

"Build processes generating artifacts typically require several steps and tasks to be completed
successfully. Examples of such tasks include compiling source code, running a unit test, and
packaging of artifacts. Maven uses the concept of goals to represent such granular tasks." - ref
#2
Goals in Maven are packaged in plug-ins, which are essentially a collection of one or more
goals. For example, the compiler is the plug-in that provides the goal compile.
Some phases have goals bound to them by default. And for the default lifecycle, these bindings
depend on the packaging value.
Goals are executed in phases which help determine the order goals get executed in.
This simplifies project dependency management greatly.
The default Maven lifecycle bindings show which goals get run in which phases by default. The
compile phase goals will always be executed before the test phase goals which will always be
executed before the package phase goals and so on.
A goal not bound to any build phase could be executed outside of the build lifecycle by direct
invocation.
The order of execution depends on the order in which the goal(s) and the build phase(s) are
invoked.
For example, consider the command below. The clean and package arguments are build phases,
while the dependency:copy-dependencies is a goal (of a plugin).

If this were to be executed, the clean phase will be executed first (meaning it will run all
preceeding phases of the clean lifecycle, plus the clean phase itself), and then
the dependency:copy-dependencies goal, before finally executing the package phase (and all
its preceeding build phases of the default lifecycle).

QUE: Properties of POJO Class.

ANS:
A POJO must not :
 Extend pre-specified classes: Ex- public class Test extends javax.servlet.http.HttpServlet
is not considered to be a POJO class.
 Contain pre-specified annotations: Ex- @javax.persistence.Entity public class Test{..} is
not a pojo class.
 Implement prespecified interfaces: Ex- public class Test implements javax.ejb.EntityBean
{ … } is not considered to be a POJO class.

POJO:- POJO is a Java object not bound by any restriction other than those forced by the Java
Language Specification.

Properties of POJO :

1. All properties must public setter and getter methods

2. All instance variables should be private
3. Should not Extend prespecified classes.
4. Should not Implement prespecified interfaces.
5. Should not contain prespecified annotations.
6. It may not have no argument constructor