Exclude endpoint mapping from Swagger documentation in Springfox

 Exclude endpoint mapping from Swagger documentation in Springfox

By default, Swagger ui shows all the endpoint defined via a controller in SwaggerConfig using Docket.

But there are situations in which you dont want those endpoints to be visible in swagger ui.

To achieve this, we can do this following way:

@Bean
    public Docket productApi() {
        return new Docket(DocumentationType.SWAGGER_2)
                .select().paths(Predicates.not(PathSelectors.regex("/|/error|/swagger.yml"))).apis(RequestHandlerSelectors.basePackage("com.daimler.datalayer.apistreamintegration.controller"))
                .paths(PathSelectors.any())
                .build().apiInfo(apiInfo());


Just provide all regex which you want to exclude.
Here in the example i have excluded all mapping /, /error and /swagger.yml

Cheers!!!

Get me Git

Some useful terms

master: this is the main code branch, equivalent to trunk in Subversion. Branches are generally created off of master.

origin: the default remote repository that all your branches are pull'ed from and push'ed to. This is defined when you execute the initial git clone command.

unpublished vs. published branches: an unpublished branch is a branch that only exists on your local workstation, in your local repository. Nobody but you know that branch exists. A published branch is one that has been push'ed up to github, and is available for other developers to checkout and work on.

fast-forward: the process of bringing a branch up-to-date with another branch, by fast-forwarding the commits in one branch onto the other.

rebase: the process by which you cut off the changes made in your local branch, and graft them onto the end of another branch.

repo, repository: This is your object database were your history and configuration is stored. May contain several branches. Often it contains a worktree too.

a git, "the git": never heard of, sorry. "the git" probably describes the software itself, but I'm not sure

index, staging area: This is a 'cache' between your worktree and your repository. You can add changes to the index and build your next commit step by step. When your index content is to your likes you can create a commit from it. Also used to keep information during failed merges (your side, their side and current state)

clone: A clone of a repository ("just another repository") or the act of doing so ("to clone a repository (creates a new clone)")

commit: A state of your project at a certain time. Contains a pointer to its parent commit (in case of a merge: multiple parents) and a pointer to the directory structure at this point in time.

branch: A different line of development. A branch in git is just a "label" which points to a commit. You can get the full history through the parent pointers. A branch by default is only local to your repository.

tree: Basically speaking a directory. It's just a list of files (blobs) and subdirectories (trees). (The list may also contain commits in case you use submodules, but that's an advanced topic)

upstream: After cloning a repository you often call that "original" repository "upstream". In git it's aliased to origin

HEAD: A symbolic name to describe the currently checked out commit. Often the topmost commit

tag: A descriptive name given to one of your commits (or trees, or blobs). Can also contain a message (eg. changelog). Tags can be cryptographically signed with GPG.

patch: A commit exported to text format. Can be sent by email and applied by other users. Contains the original auther, commit message and file differences

stash: Git allows you to "stash away" changes. This gives you a clean working tree without any changes. Later they can be "popped" to be brought back. This can be a life saver if you need to temporarily work on an unrelated change (eg. time critical bug fix)

object: can be one of commit, tree, blob, tag. An object has associated its SHA1 hash by which it is referenced (the commit with id deadbeaf, the tree decaf). The hash is identical between all repositories that share the same object. It also garuantees the integrity of a repository: you cannot change past commits without changing the hashes of all child commits.

(module,) submodule: A repository included in another repository (eg. external library). Advanced stuff.

revspec: A revspec (or revparse expression) describes a certain git object or a set of commits through what is called the extended SHA1 syntax (eg. HEAD, master~4^2, origin/master..HEAD, deadbeaf^!, …)

refspec: A refspec is pattern describing the mapping to be done between remote and local references during Fetch or Push operations

history: Describes all ancestor commits prior to a commit going back to the first commit.

Note: Use This for more detailed info of git glossary: 

git help glossary

Simple Git Guide:

        Your local repository consists of three "trees" maintained by git.  The first one is your Working Directory which holds the actual files. The second one is the Index which acts as a staging area and finally the HEAD which points to the last commit you've made.

                                                  

ADD and Commit:
     You can propose changes (add it to the Index) using
          git add <filename>
          git add *

This is the first step in the basic git workflow. To actually commit these changes use
         git commit -m "Commit message"

Now the file is committed to the HEAD, but not in your remote repository yet.

Pushing changes to remote repository:
Your changes are now in the HEAD of your local working copy. To send those changes to your remote repository, execute 
        git push origin master
Change master to whatever branch you want to push your changes to.

If you have not cloned an existing repository and want to connect your repository to a remote server, you need to add it with
       git remote add origin <server>   
Now you are able to push your changes to the selected remote server

Branching:

Branches are used to develop features isolated from each other. The master branch is the "default" branch when you create a repository. Use other branches for development and merge them back to the master branch upon completion.

create a new branch named "feature_x" and switch to it using
       git checkout -b feature_x
switch back to master
       git checkout master
and delete the branch again
       git branch -d feature_x
a branch is not available to others unless you push the branch to your remote repository
       git push origin <branch>

Update & Merge
To update your local repository to the newest commit, execute 
       git pull
in your working directory to fetch and merge remote changes.
to merge another branch into your active branch (e.g. master), use
      git merge <branch>
in both cases git tries to auto-merge changes. Unfortunately, this is not always possible and results in conflicts. You are responsible to merge those conflicts manually by editing the files shown by git. After changing, you need to mark them as merged with
      git add <filename>
before merging changes, you can also preview them by using
      git diff <source_branch> <target_branch>

logging

    git log

Replace local changes:
In case you did something wrong, which for sure never happens ;), you can replace local changes using the command
       git checkout -- <filename>
this replaces the changes in your working tree with the last content in HEAD. Changes already added to the index, as well as new files, will be kept.

If you instead want to drop all your local changes and commits, fetch the latest history from the server and point your local master branch at it like this
        git fetch origin
        git reset --hard origin/master