# MySQL

MySQL is the database service which is needed for the application. So we need to install it and configure it for the application to work.

## Manual Steps to Install MySQL

As per the Application need, we are choosing MySQL 5.7 version.

1. Setup MySQL Repo

# echo '[mysql57-community]
name=MySQL 5.7 Community Server
baseurl=http://repo.mysql.com/yum/mysql-5.7-community/el/7/$basearch/
enabled=1
gpgcheck=0' > /etc/yum.repos.d/mysql.repo

2. Install MySQL

# yum install mysql-community-server -y

3. Start MySQL.

# systemctl enable mysqld
# systemctl start mysqld

4. Now a default root password will be generated and given in the log file.

# grep temp /var/log/mysqld.log

5. Next, We need to change the default root password in order to start using the database service.

# mysql_secure_installation

6. You can check the new password working or not using the following command.

# mysql -u root -p

Git Branch

Branching means you diverge from the main line of development and continue to do work without messing with that main line.

Commands

List all the branch

 git branch

Create a branch

 git branch <<branch name>>
 git branch dev

Switch to a branch

 git checkout <<branch name>>
 git checkout dev

Find the current branch (The current branch should have * infront of current branch

 git branch

* dev
  master

Delete a branch

 git checkout master
 git branch -D dev

Git Merge

Git Merge command is used to integrate the changes of different branches into a single branch (mostly used for master branch).For example if we create a branch say dev branch from master branch (now dev branch will have a complete copy of all commited files of master branch) and in dev branch( git checkout dev command to swtich to dev branch) if we add some new files or modify existing files then at last we need to merge these files to master branch because in most of the cases master branch is considered as the branch which has latest project code.

Example

In below diagram there are 3 branches(master,Feature1 and Feature2) , after creation Feature1 branch, it has 2 commits(green color circles) and Feature2 branch also has 2 commits( blue color circles) and these changes are getting merge into master branch at merge commit, now master branch includes the commits of feature1 and feature2 branch ( you can check it with git log command)

command

git merge <branch_name>
git merge dev

Of course, you can move to DevOps and get jobs in this. You would have to add a couple of skills into your skillset which includes Cloud technology (AWS, Azure, GCP), Puppet/chef/Ansible, Jenkins/Bamboo/Teamcity, Docker and Kubernetes, Terraform, Git, Scripting, Python, Databases, etc.

You will required a couple of months to get on these skills.

*********** GIT ************

Git Index:
==========

1. Introduction to git
2. Terminology
3. Repo
4. gitignore
5. logs
6. Branching
7. Merging
8. stash
9. unstaging(rm, reset, revert)
10. Tags
11. bisect
12. HEAD
13. Hooks
14. git-hub

Git is a Source Code Management(SCM) / Version Control system(VCS) / Distributed version control  system

--> Types of SCM/VCS tools
    * Git,
    * CVS,
    * Perforce,
    * clearcase,
    * svn

git:- it is a process of tracking and controlling/maintaining changes of a software product

--> Download git from https://git-scm.com/
    which git --> path of git where it installed
    git --version -->to verify
    git help config

yum groupinstall "development tools" -y
yum install gettext-devel openssl-devel perl-CPAN perl-devel zlib-devel curl-devel
go to official git website-->> wget https://mirrors.edge.kernel.org/pub/software/scm/git/git-2.18.0.tar.gz
extract tarball-->> tar -xvzf git-2.18.0.tar.gz
remove tarball(git-2.18.0.tar.gz)
1.configure --->> ./configure --prefix=/usr/local/git
2.compile code --->> make
3.installation --->> make install
echo "export PATH=/usr/local/git/bin:SPATH" >> /etc/profile
source /etc/profile


git features compare to other tools:-
    1. Speed
    2. Support for non-linear development(thounds of parallel branches)
    3. distributed version control system
    4. Able to handle large projects efficiently

Why Git is Distributed Version Control system:-
    1. Speed
    2. Network Issues
    3. we cannot share the changes to any users and centralized server


Git Terminology:-
=================
1. client/server
2. workspace: - space where the client comm with server
3. Repository : - it is a container/Directory. for each product/project we've one repository in the server.
4. Branch :- parallel development
5. Checkin:- Once the changes done, storing back to the server to maintain perminentaly
6  Checkout:- Taking petmission from server to do modifications.    
7. Revision/Version id/commit id : - git will track all the info of changes done by a user like when,which repo,who,which file, what changes)

it stores in the form of snapshots i.e diff b/n existing file data and currently modified file data.
         commit id/check in :- with 40 char long
        in workspace we've 3 stages before commit id get generated
            --> working dir:- where you working with files physically
            --> Staging Area:- it helps to create commit id(it is virtual area , here workspace don't know which one is existing and modified data)
            --> Repository:- where stores data (commited file)
git config:-
=========
git config --global user.name "vinodh machi"
git config --global user.email "vinodhk070@gmail.com
git config --global push.default simple
git config --list

local  : By default, git config will write to a local level if no configuration option is passed. .git/config
global : Global level configuration is user-specific, meaning it is applied to an operating system user.
         Global configuration values are stored in C:\Users\vinodh\.gitconfig
        Ex:- One of the most common use cases for git config is configuring which editor Git should use.
             editor = VIM
        Ex:- Merging Tools
             git config --global merge.tool kdiff3
system : System-level configuration is applied across an entire machine. This covers all users on an operating system and all repos.
     system configuration values are stored in C:\Program Files\Git\mingw64\etc\gitconfig

git config --edit/--list --local
git config --edit --global
git config --edit --system

creating Repositorys:-
1. bare repo: is the centrailized repository which is used to store and share the changes.
2. non-bare repo: user (or) workspace (or) local repository whih is used to modify the changes.

mkdir central.git
git init --bare
git clone central.git <source>  vinuspace <dest>
create file in workspace
move to staging area : git add java
move from staging repo : git commit -m "first chickin"

-->git log : list of all the commits will display
--> set of changes together with single version id: git add . (or) java, oracle...etc

if you don't have the same content then-->Modified/Untracked files
if you have same content in the file then --> Unmodified

--> git push <source> <dest>
--> git push enter : to push the changes to repository for sharing to other users
--> 2nd user access the repo and created new file and pushed it to central repo and now
     1user want to update things what user2 changed. then use
-->git pull

Git ignoring:
=============
--> .gitignore : is a conf file to ignore the unwanted runtime files like jar, war, log....
              1.class (Full name)
             *.class (pattern matching)
          
Log viewing:
============
--> git log -3
--> git log --oneline --grep "workspace"
--> git log --grep "stringmasg" --oneline
--> git shortlog
--> git log --stat
git show --stat 23rt459bf
git show --name-status 23rt45bf
git show --name-only abc


Branching:-
===========
--> parallel development
--> storing of files in a repo is in the form of branches
       ex:  android             windows
               file1                file1
               file2                file2
                  
       here the futures are same only slight diff i.e os
--> master is the default branch whenever we create repository/workspace
--> at any point of time you can work with  only one branch at a time
--> git branch : list of branches avilable
      git branch branch_name
      git checkout new_branch : switch to other branch
      git checkout -b new_branch_name : creating new and switching to new branch
--> when we create a new branch based on the master the same fiels and commit ids will come to new branch also.
# merging the 2 branches:-
--> git merge <sour> <dest>
--> git branch -d <branch_name> : to delete branch, use 'D' for forcely remove without fully merged.
--> git branch --merged:- lists the branches that have been merged into the current branch
--> git branch –no-merged:- lists the branches that have not been merged
--> git rebase :Alternate to merge

Note:- when we create,edit,delete in workspace, this shows same in all branches until you commit permanently.

--> bare repo  you will not have working dir, so i.e you not able to see

Merging:-
=========
--> Master(Target)<---------feature(source)   

checkout command:-
==================
1. git checkout <BRANCH>:<COMMITID> --> specific commit('detached HEAD')
2. git checkout branch_name --> to switch one branch to another  
3. git checkout -b <new-branch-name> --> creating and directly switching to new branch
4. git checkout -- file1 file2 --> to dicard the changes in working directory(when only files deleted,edited from work dir)

Stashing commited changes :-
============================

stashing will do 2 things
    1. whenever you modifing the changes it will take backup.
    2. and it revert back with orginal position of the file where you started.
git stash --> create stash, remove changes from working directory(when files create and edit)
git stash list--> list all stash available for the repository
git stash apply stash@{0} -->my 1st idea  is good (it only apply it not remove)
git stash pop --> it will apply and remove the last stash array
git stash clear --> remove all backup entrys

Note:- Here no need to move changes,files..etc to staging  or commiting

Removing files:
===============
rm
git rm filename
git clean -n(dry run means which are the file eligible to remove, very care full before running this)
note: removes untracked files
git clean -f( removes the untracked file instead of adding to .gitignore conf file)

Removing files in working Dir:-
===============================

git rm :- will remove the file from the index and working directory ( only index if you used --cached ) -
so that the deletion is staged for next commit.
When using git rm, the removal will part of your next commit. So if you want to push the change you should use git rm
rm:-However, if you do end up using rm instead of git rm. You can skip the git add and directly commit the changes using: git commit -a


Undo/Reverting Changes after adding to staging area :-      
=====================================================
i added a file into staging area, now i want to modify it before going to commit it?
Syntax: git reset HEAD <file>
sol is :      1. git reset (mixed is the default option)
              2. git reset --mixed --> revert back / undo the changes from staging area
              3. git reset --hard --> to remove changes from all the 3 areas
                        @ working directory
                        @ staging Area
                        @ Repository(once file came to staging area, it creats temperary commit id in repo)
              4. git reset --soft --> remove changes only in repo temp id (HEAD)
HEAD--> once we add file into staging area it create one temp id in the repo as a reference, this is the
            latest commit id which we working.

Undo/Reverting Changes after commiting:-
=======================================
   1. git revert 256ed01(1st 7char)  --> it revert only the content not the complete entry(commit id)  and create a new commit id and refering to previous.
 
HEAD:-
======
HEAD is the reference to the most recent commit in the current branch(In most of  the cases).
HEAD Doesn't point to most recent commit when we go into DETACHED HEAD State.
  git show HEAD --> to see head commit
  git difftool HEAD HEAD~1

Tags:-
-------
to identify/reference for a commitid to quick access/ creating specific point in history for our repository

create tag for particular commits:
git tag <tag-name> <reference of commit>

git tag <name-of-tag> --> light weight tag
git tag -a <tag-name> -m "comment" <commitid> --> annotated tag
git tag -n9 --> to see tag messgaes
git tag --> to list tags
git show --stat <tag_name>
git push origin v7.2 ---> pushing to remote(github)
git push origin --tags ---> pushing all tags at once to remote
git push --tags
Note:- when you working in folder in which github repository is cloned)

Deleting tags from local repository:
git tag -d <tag_name>
git tag -delete <tag-name>
git tag -d v7.2 vinumaa v7.3 --> deleting multiple tags at once in local repository

Deleting tags from remote repository:
git push origin -d v7.2
git push origin -delete v7.2
git push origin :v7.2
git push origin -d v7.2 vinumaa v7.3 --> deleting multiple tags at once in remote repositor

we cannot checkout tags in git but, we can create a branch from tag and checkout the branch
git checkout -b <branch_name> <tag_name>(give already created tag names)

Diff:-
======
used to compare Changes,branches,and commits.
git diff --> diff b/n version in the working dir and version in the staging/index area
git diff HEAD --> diff b/n version in working dir and commiting dir
git diff --cached --> diff b/n staging and commit versions

git diff --stat 2b7889f4..08j86gj9
git diff master..new

Rewriting Commit Messages:-
===========================
--> git commit --amend : for latest commit
--> git rebase -i(interactive) HEAD~2 : for other commits
note: use reword option, while r=editing commit message
--> git ls-files : for latet commit in current branch to list all files
--> git show --name-only <commit id> : specific file to list
--> git commit --amend --no-edit : # Edit hello.py and main.py git add hello.py git commit
                   # Realize you forgot to add the changes from main.py git add main.py git commit --amend --no-edit

 p, pick = use commit
 r, reword = use commit, but edit the commit message
 e, edit = use commit, but stop for amending
 s, squash = use commit, but meld into previous commit
 f, fixup = like "squash", but discard this commit's log message
 x, exec = run command (the rest of the line) using shell
 d, Drop = remove commit

rebase --continue
rebase --abort
rebase --skip

Fetch and pull:-
----------------
git fetch origin: i.e all the repos in the github will come to local repository,
git merge origin/master : to integrate the commitids

workflow:-
=========
         |        Add           |    Commit           |                  |         
         |------------------------>|---------------------->|                   |                                   
         |----------------Commit -a ---------------------->|      git push            |
         |                   |               |----------------------------->|
    Working Dir             Index        Local Repository         Remote Repository
    (work space)               (Staging)                (HEAD)                  |     
         |                   |               |<----------git fetch----------|
         |<-------------------Merge------------------------|                  |    
         |                   |               |                  |    
         |<----------------------------------Pull-----------------------------------------|
         |<--------------------diff HEAD------------------>|                  |
         |<----------diff--------->|    


Note:- the above commit -a option will only work for already known files to staging area(i.e old files)    
               
reflog:-
========
it shows when we commit,checkout branch, reset....etc
git reflog
git reflog --relative-date
git reflog show -all (or) <branch_name> for particular branch reflogs
git reflog show/HEAD@{5}

** Basically "git blame <file_name>" is used to show what revision and author last modified each line of a file.
   It's like checking the history of the development of a file.

Bisect:-
--------
first it will bisect/divide the given range into 2 parts and start executing
    1. range between culprit/bug is there
    2. pass Script file
         git bisect file_name.rb
         exit status 0(success) 1(failure)


commit 10 < fail
commit 9
commit 8
commit 7
commit 6 < fail
---------
commit 5 < fail
commit 4 < START<<----
commit 3 < pass
commit 2
commit 1




Hooks:-
-------
hooks are programs which are auktomatically trigger at certail points in the git execution cycle.


GitHub:- (ORS)
========
    @ is a website to upload repositories online
    @ Provides backup
    @ Provides visual interface to repo
    @ makes collaboration easier


* Through browser you can create, or upload files into github
* git clone https://github.com/vinodhk070/Machi.git
* change some data and add, commit
* git push (or) git push origin master

git init
git add README.md
git commit -m "first commit"
git remote add origin https://github.com/vinodhk070/hello.git
git push -u origin master


git remote add origin https://github.com/vinodhk070/gitsample.git
git push -u origin master

            ################### Maven ####################
Maven Index:
============
1. Introduction To Maven
2. Installation
3. Architecture
4. Default lifecycle
5. Directory standards
6. GAV
7. Test project
8. one by one goals executions
9. jar, war files
10. Plugins
11. Maven Profile
12. Dependencies


Build Tools/Build Automation/Management/Process
================================================

--> Build Management: is a process that we compile and assemble all the source code(written by developers) into object files.
        ex: 100 app.java files
            100 object files(.class files)

>>Grunt
>>Gulp
>>Ant--> Java(Apache Foundation)
>>Gradle--> Alternative for Maven
>>Maven--> latest and updated one

Ant and Maven:
--------------
>> actions are defined in ant(so much of scripting)  >> in maven say what to do not how to do
>> sequences are defined in ant              >> how to build is defined in maven (life cycle)
>> no default directory layout                >> it fallows standard directory structure
>> ant fallows you                           >> you need to fallow maven
>> librarys are part of source code                  >> librarys are not part of source code
    (difficult to maintain)

>> Compiling Source Code               
>> Packing Biniries/artifacts
>> running Automated tests                         
>> Deploying to production system
>> Creating Documentation    

--> diff with other tools
    >> open source
    >> it is not only build tool and also project management tool
    >> it has set of standards and object modules,so no need to instruct     
    >> default project lifecycle
    >> dependency management

Variables:
---------
Environment Variables
    # user
    # system ($PATH)
echo $HOME
echo $SHELL
env
VARIABLENAME=vinodh
unset VARIABLENAME

-->if we want to use variables globals(in all shel windows)then
export name=vinodh (in bashrc file)

Maven Installation in Windows:  
------------------------------
--> install java
--> Download java JDK & JRE (or)  http://www.oracle.com/technetwork/java/javase/downloads/index.html
--> Go to-->mycomputer-->properties-->Advanced system settings-->environment variables-->system variables
--> path    ;C:\Program Files\Java\jdk1.8.0_131\bin;C:\Program Files\Java\jre1.8.0_131\bin  ---> to system variables PATH by seperater ;
            JAVA_HOME should point to JDK(without bin)

--> install Maven
Go to this website to downloab(Zip)--> maven.apache.org/download.cgi
    D:\Apache_Maven ---> MAVEN_HOME in system variables
    path--> ;D:\Apache_Maven\bin

Maven Installation in Linux::
-----------------------------
 Step1. yum install -y java-1.8.0-openjdk-devel
 Step2. java -version
 Step3. cd /usr/local/src
 Step4. wget http://www-us.apache.org/dist/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.tar.gz
 Step5. tar -xf apache-maven-3.5.4-bin.tar.gz
 Step6. mv apache-maven-3.5.4/ apache-maven/
 Step7. cd /etc/profile.d/
 Step8. vim maven.sh
             >> export M2_HOME=/usr/local/src/apache-maven
             >> export PATH=${M2_HOME}/bin:${PATH}
 Step9. chmod +x maven.sh
 Step10. source /etc/profile.d/maven.sh (for loading the configuration)
 Step11. mvn --version
           o/p:- Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T19:33:14+01:00)
               Maven home: /usr/local/src/apache-maven
               Java version: 9.0.4, vendor: Oracle Corporation, runtime: /opt/java/jdk-9.0.4
               Default locale: en_US, platform encoding: UTF-8
               OS name: "linux", version: "4.17.6-1.el7.elrepo.x86_64", arch: "amd64", family: "unix"


vi /etc/profile
vi /etc/bashrc

verify whether java/maven is installed or not in CMD prompt by typing below commands
Javac --> compiler
java -->keyword
java -version --> runtime environment
mvn --version

How Maven works:(Architecture)
==============================
                    Build System
                  ---------------------------    
                      |                 |          
                          |    POM.XML    (conf file)  |       HTTP            
     local repository <<------|    (goals)             |--------------->> Remote Repository     
                  |                 |            (maintained by Maven opensource Community)
                  |        Maven         |
                  ----------------------------
--> it works as a GOALS, internally goals as plugins/jar files which has the future of when and what it has to do
    eg:- maven do testing; --->>  then it call plugin to do testing
    
Default lifecycle:   
==================
    1. generate-source/resource (.java files)
    2. compile -->all .java files into .class files
    3. test  ---> Unit test (a peace of code)
    4. package --> deliveriable or executable or Artifacts(which contains all)
    5. integration-test(pre and post)
    6. install                            
    7. deploy
    --> clean :- it deletes all runtime files
    --> site : - documentation(99% we will not use, very rare cases like audits...)

Example Maven Goles:
--------------------
To invoke a Maven build you set a lifecycle “goal”
mvn install
note:- mvn -f pom.xml <goal>
Invokes generate and compile, test, package, integration-test, install

mvn clean
Invokes just clean

mvn clean compile
Clean old builds and execute generate, compile

mvn compile install
Invokes generate, compile, test, integration-test, package, install

mvn test clean
Invokes generate, compile, test then clean

Note:
diff source and binary code
    1. source code which we can customize
    2. binary code is a product which we can buy directly

Standard Directory Layout:
--------------------------
>> if you want to work with maven project, then we need to follow the maven standard directory structure through which maven will work.
main-->actual source code, lib files,additinal info, property files....etc
test --> unit testing files

once you start compile, maven will go to src/main folder to compile (what are the files you gave over there)

GAV:
====
--> how maven identify which plugin or project to select when we instruct a goal. (G.A.V)
    G(groupid) -- string rep company name / group name / business org on which u doing project.
    A(artifactid) -- string rep product or deliverable(final output of your product)
    V(versionid) -- Major.Minar.Patch/Maintanance( add SNAPSHOT to identify in development)
    packaging -- build type identified using the packaging element
    eg : - pom ,jar(default),war,ear
 note: - by keeping pom in packaging it acts as a parent pom of all modules
mvn archetype:generate

--> jar - java archive(default package maven uses which contains group of .class files, so we group this to get a particular behaviour)
--> war - web archive - contain group of jar + config + xml (for web based projects)
--> ear - enterprice application

Note:- How maven knows,where java files,what it has to do,where to keep files and fetch files....etc this all done by below two files
  to run maven default life cycle
1)dir structure
2) pom.xml file in dir

--> remote maven repository located in - http://repo1.maven.org/maven2
--> local repo located in c:/user/vinodh --> .M2 --> Repository

POM:(conf file)
---------------
Project object model is fundamental unit of work in maven,POM is an xml file that contains information about project and configuration
details used by maven to build project. pom conf file contains below list.
--> atlest one pom.xml file should be there in product/project
    @ Describe a project
    @ name and Version, Artifact type,source code location, Dependencies
    @ Plugins
    @ Profiles(Alternate build configuration)    
    @ it uses XML by default


Plugins:-
----------
if we want instruct anything to maven through goals we will do, goals internally have plugins/jar files.
    1. Build Plugins : we will use this for entire life cycle
    2. Reporting Plugins : create documentation of product (for site phase only)

<build>
     <plugins>
              <plugin>
      1. GAV - what is plugin (identify the plugin)
      2. when you have to run the plugin
      3. how to use plugin(like conn DB, insall, disconnect...etc)
      4. what exactly to do
              </plugin>
      -- plugin 2 infomation
    </plugins>
</build>    
================================================================================
<project>
  <build>
        <plugins>
          <plugin>
             <groupId>org.apache.maven.plugins</groupId>
             <artifactId>maven-antrun-plugin</artifactId>
             <version>1.1</version>
             <executions>
               <execution>
                   <id>id.clean</id>
                   <phase>clean</phase>
                   <goals>
                   <goal>run</goal>
                   </goals>
                   <configuration>
                   <tasks>
                      <echo>hallo world=============</echo>
                   </tasks>
                   </configuration>
              </execution>
            </executions>
         </plugin>
       </plugins>
    </build>

<plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>exec-maven-plugin</artifactId>
        <version>1.6.0</version>
        <configuration>
           <executable>mvn</executable>
                <arguments>--version</arguments>
        </configuration>        
</plugin>

</plugins>
</build>
</project>

Note:- what plugin we selecting, what syntax(GAV) of plugin, And how to call....    
--> maven ant plugin, maven exec plugin....

how to call a individual plugin:
---------------------------------
mvn <GOAL>
mvn <PLUGIN>:<GOAL_NAME>
mvn exec:exec
mvn exec:java
--> mvn <plugin>:<goal> ---> we can call plugin directly without phase/goal

SNAPSHOT:
=========
  1. it is under development build (or) dev copy which is not yet finalized(only we will change before releasing client)
  2. other projects are depend on this, if i rebuild the jar name other proj looking for this

Maven Profile:
==============
def:- buid profile is a set of configurationns values which can be used to set or override dafault values of maven build.
using a build profile, you can customize buid for different environments such as production v/s developmennt.

--> some times you want to execute only default plugins not all mentioned in build, at that time we can use.
    mvn clean (default)
    mvn -Pdemo  specify goal(all plugins)

<profiles>
       <profile>
    <id>demo</id>
             <build>
              </build>
       </profile>
</profiles>

--> profile can activate many types like env, os, settings.xml in repo...etc

<profile>  
  <id>test</id>
    <activation>
       <property>    
      <name>env</name>   
       <value>test</value>
      </property>
    </activation>
</profile>  
---------------------------------------------
Multy-Module Projects:
======================

--> if you have 1000 files in app.java project it is diffcult to maintain, so make modules/components like add, sub, dev of calculater project and copy src,pom file in each.
 note: - by keeping pom in packaging it acts as a parent pom of all modules (parent and child relationship)     demo (parent) > add, sub (child)
<modules>                                        
    <module>add</module>
    <module>sub</module>
</modules>

Maven has 1st class multi-module support
Each maven project creates 1 primary artifact
A parent pom is used to group modules

issues -1:
 >> executing all modules every time

overcome:
parent and child relationship, by keeping 'pom' file in "packaging"
Ex:-

  <groupId>EBU</groupId>
  <artifactId>Parent-module</artifactId>
  <version>1.0-SNAPSHOT</version>
  <packaging>pom</packaging>
    <modules>
        <module>Child-jar</module>
        <module>child-war</module>
    </modules>

issue-2:
>> Dependencies
-->adding add.jar to subtract for dependency..

<dependencies>
    <dependency>
      <groupId>training</groupId>
      <artifactId>subtract</artifactId>
      <version>1.0 SNAPSHORT</version>
    </dependency>
  </dependencies>

note:-
<dependencies>                |
    <dependency>            |
      <groupId>junit</groupId>        |
      <artifactId>junit</artifactId>    |------------>> junit plugin is default plugin for performing test phase
      <version>3.8.1</version>        |
      <scope>test</scope>        |
    </dependency>            |
  </dependencies>            |

by using "install" phase in add module, then add.jar will move to local repo

mvn install--> copying jar file form local project folder to local repository

giving parent gav in child ==>>complete parent and child rel

Dependencys how maven know:
------------------
--> if sub is depend on add file then we need to keep add file GAV into sub file dependency.
--> error :- not able to find add file, then install add file from local project folder to local repository
              mvn install





















    

Hi Murali,

You can takeup a  course which can gives you a knowlede on CI/CD tools, process and integration.

Apart from that, if you can work on the scenarios you can get a good hands on the tools.

In my trainings, i generally share knowledge on tools along with scenarios which i deal at my office on a day-to-day basis. This has helped my students to get hands on the tools.