Maven is based around the central concept of a build lifecycle.
There are three built-in build lifecycles

There are three lifecycle phases in maven

  1. clean
  2. build (default)
  3. site

You can Either trigger a phase or goal in maven

When the clean lifecycle is called it has three phases internally.For example, the clean life cycle has 3 phases (pre-clean, clean, post-clean).

For example the default lifecycle comprises of the following Build Phases:

◾validate – validate the project is correct and all necessary information is available
◾compile – compile the source code of the project
◾test – test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
◾package – take the compiled code and package it in its distributable format, such as a JAR.
◾integration-test – process and deploy the package if necessary into an environment where integration tests can be run
◾verify – run any checks to verify the package is valid and meets quality criteria
◾install – install the package into the local repository, for use as a dependency in other projects locally
◾deploy – done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.

So to go through the above phases, we just have to call one command:

>> mvn

i.e

>> mvn install

For the above command, starting from the first phase, all the phases are executed sequentially till the ‘install’ phase. A command can be used in a multi-module scenario mvn clean install.

A Build Phase is Made Up of Plugin Goals
Most of Maven’s functionality is in plugins. A plugin provides a set of goals that can be executed using the following syntax:

mvn [plugin-name]:[goal-name]

For example, a Java project can be compiled with the compiler-plugin’s compile-goal by running mvn compiler:compile

Build lifecycle is a list of named phases that can be used to give order to goal execution.

Goals provided by plugins can be associated with different phases of the lifecycle

mvn test

When the preceding command is executed, Maven runs all goals associated with each of the phases up to and including the test phase. In such a case, Maven runs the resources:resources goal associated with the process-resources phase, then compiler:compile, and so on until it finally runs the surefire:test goal.

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).

mvn clean dependency:copy-dependencies package

If this were to be executed, the clean phase will be executed first (meaning it will run all preceding 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 preceding build phases of the default lifecycle).

Furthermore, a build phase can also have zero or more goals bound to it. If a build phase has no goals bound to it, that build phase will not execute. But if it has one or more goals bound to it, it will execute all those goals.

The image showing various plugins goals used for different phase during execution.To take the other way round plugins executing goals at different phases.

Maven is a “build management framework”

You could define how your .java files get compiled to .class, packaged into .jar (or .war or .ear) files, (pre/post)processed with tools, managing your CLASSPATH, and all others sorts of tasks that are required to build your project.

 Though it doesn’t give fine grain control like  Apache Ant or Gradle or Makefiles in C/C++, but it attempts to be completely self-contained in it that you shouldn’t need any additional tools or scripts by incorporating other common tasks like downloading & installing necessary libraries etc.

It is also designed to around “build portability” so that you don’t get issues as having the same code with the same buildscript working on one computer but not on another one (this is a known issue, we have VMs of Windows 98 machines since we couldn’t get some of our Delphi applications compiling anywhere else). Because of this, it is also the best way to work on a project between people who use different IDEs since IDE-generated Ant scripts are hard to import into other IDEs, but all IDEs nowadays understand and support Maven.

There are few inflexibility in maven and some developers stick with Ant or similar, but a growing number of them are people who have moved on to Maven successors such as Gradle and Buildr. These successors inherit from Maven the idea of providing a powerful set of build steps out of the box, but make it immensely easier to add custom steps too.

​How to apologise if you are late to meeting

Instead of offering up a reason or excuse for why you were late, focus your apology on the impact you’ve made or the problems you’ve caused. Say something like “Sorry for keeping you waiting” or “I’m so sorry for taking up more of your time” or even “Thank you for your flexibility.” If you show everyone that you’re sorry for using up their valuable time, your apology will sound much more sincere.

Spring vs EJB

App servers written to support the EJB standard can, in theory, be ported from one compliant Java EE app server to another. But that means staying away from any and all vendor-specific extensions that lock you in to one vendor.

Spring ports easily between app servers (e.g., WebLogic, Tomcat, JBOSS, etc.) because it doesn’t depend on them

Spring Boot offers an even better way to write applications without Java EE app servers. You can create an executable JAR and run it on a JVM.

The Spring framework sits on top of the application servers and service libraries. Service integration code (e.g. data access templates) resides in the framework and is exposed to the application developers. In contrast, the EJB 3 framework is integrated into the application server and the service integration code is encapsulated behind an interface. EJB 3 vendors can thus optimize the performance and developer experience by working at the application server level. For example, they can tie the JPA engine closely to JTA transaction management. Another example is clustering support which is transparent to EJB 3 developers

Spring vs J2EE

Strictly speaking, Spring is a framework while Java EE is a specification which is implemented by various softwares such as JBoss and Glassfish.
The greatest difference is that Spring is an actual library while JavaEE is an API that has to be implemented. Depending on the JAVA EE container you could find a full implementation (e.g. Glassfish), a partial implementation (e.g. Tomcat) a full implementation with extra sugar (e.g. JBoss and others).

Design Thinking is not about problem solving. Its about making things better. Fixing a Car which got broke down is problem solving. Fixing a Car to run smoothly and fuel efficiently is Design Thinking

Key Points

  • Learn to Fail Early
  • Test your end result.Make sure you are doing the right one
  • Don’t spend too much time on Planning. Start working

Other Notable Things

  • Ask questions not with solutions which you already have in your mind
  • Questioning Basics

    • What you think about It
    • What you feel about It
    • What you do about It
  • People hesitate to tell No.So you need to change the question according to that. Eg – Petrol Bunk Story – There was high turn around in petrol bunk for special petrol when “Shall I put Special Petrol” was asked instead of asking “Sir special or normal petrol” to customer. Instead of giving option to choose from ask shall I offer that. The one which you offer is the one which you like to sell
  • Empathy – Understanding how other people feel, communicating your understanding, Apathy – a state of not caring, being unsympathetic or not empathetic, Sympathy – feelings of pity and sorrow for someone, Antipathy – Glad they have those problems
  • Convert Implicit needs to Explicit Requirements Eg – TV not clear is a Implicit need to someone and TV to be bought is a requirement to someone.Turn Implicit needs of customers to explicit needs to make it as selling point

Is it possible to create Object for abstract class?

abstract class my {
    public void mymethod() {
        System.out.print("Abstract");
    }
}

class poly {
    public static void main(String a[]) {
        my m = new my() {};
        m.mymethod();
        System.out.println(m.getClass().getSuperclass());
    }
}

No, we can’t.The abstract super class is not instantiated by us but by java.

In the above code we are creating object for anonymous class.

my m = new my() {};

When the above code is compiled will result in following class file creation

My.class
Poly$1.class  // Class file corresponding to anonymous subclass
Poly.class

anonymous inner type allows you to create a no-name subclass of the abstract class

When the above code is run the output would be

Output

 Abstract
 class my

Now lets override the method in anonymous inner class like one below.

abstract class my {
    public void mymethod() {
        System.out.print("Abstract");
    }
}

class poly {
    public static void main(String a[]) {
        my m = new my() {
          public void mymethod() {
               System.out.print("Overridden in anonymous class");
           }
        };
        m.mymethod();
        System.out.println(m.getClass().getSuperclass());
    }
}

Output

 Overridden in anonymous class
 class my

Anonymous inner class with same name as abstract class are child classes of abstract class.

There may be times where one may think that I can extend parent class instead of implementing interface. Lets see whats When to choose inheritance over an interface and interface over inheritance.

inheritance over an interface
The main drawback of interfaces is that they are much less flexible than classes when it comes to allowing for the evolution of APIs. Once you ship an interface, the set of its members is fixed forever. Any additions to the interface would break existing types implementing the interface.

A class offers much more flexibility. You can add members to classes that you have already shipped. As long as the method is not abstract (i.e., as long as you provide a default implementation of the method), any existing derived classes continue to function unchanged.

interface over inheritance
Lets take the following code

Mammal.java

public abstract class Animal
{
 public void abstract mate();
 public void abstract feed();
}

Now the above abstract class has two methods mate() and feed().

public class Dog extends Animal
{
}

public class Cat extends Animal
{
}

Now we have Dog and Cat concrete classes extending Animal.

we have few more classes extending Animal

public class Giraffe extends  Animal{}
public class Rhinoceros extends  Animal{}
public class Hippopotamus extends  Animal{}

Now the classes Dog and Cat are pet animals. So it should implement pet behavior. This can be done in two ways.

  1. By defining isPet() method in base class and overriding in child class
  2. By implementing pettable interface.

Now implementing interface is easy compared to overriding method defined in base class because

  1. Interface favours clean code. Defining and Overriding the class may increase code redundancy
  2. Now you get a parakeets which is again a pet and could also fly.If you are inheriting the base class then you need to add canFly() method in base class and set it to return false and override in the parakeets class to return true.

    public class  parakeets extends Animal
    {
      .
      .
        public boolean canFly()
        {
            return true;
        }
    }
    

    Instead you can declare a interface flyable and implement the interface method without making changes to base class

    public class  parakeets extends Animal implements flyable 
    {
      .
      .
        public boolean canFly()
        {
            return true;
        }
    }
    
  3. Interface may be completely not related to class in which it is implemented. Say lets define a carpenter ants class which always moves one after another.Now this can be represented to implement queuing interface which has nothing to do with other animals other then carpenter ants since only ants of this type follows a queue system when they migrate from one place to another

Scenario 1:
If you have a clear analysis and Design in UML then you can start with the interface.

Scenario 2:
The interface shows up when you need to refactor common features out of several classes.Until you have multiple classes with common features, it’s hard to foresee what the interface should be.

Write a class and extract interface later. Usually the reason for extracting an interface is the need for a second implementation of that interface (often as a mock for unit testing)