Maven

• Maven

Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information
http://maven.apache.org/

• What is Maven?

Maven is a project management and comprehension tool
To summarize, Maven simplifies and standardizes the project build process
Maven provides developers ways to manage following:

Builds

Documentation

Reporting

Dependencies

SCMs

Releases

Distribution

mailing list

Maven History
Maven was originally designed to simplify building processes in Jakarta Turbine project. There were several projects and each project contained slightly different ANT build files. JARs were checked into CVS.

Apache group then developed Maven which can build multiple projects together, publish projects information, deploy projects, share JARs across several projects and help in collaboration of teams

Maven project structure and contents are declared in an xml file, pom.xml referred as Project Object Model (POM),

Convention over Configuration
Developers do not have to mention each and every configuration detail.
When a Maven project is created, Maven creates default project strcture. Developer is only required to place files accordingly and he/she need not to define any configuration in pom.xml.


Maven POM
It is an XML file. It always resides in the base directory of the project as pom.xml.
The POM contains information about the project and various configuration detail used by Maven to build the project(s).
POM also contains the goals and plugins
Before creating a POM, we should first decide the project group (groupId), its name(artifactId) and its version as these attributes help in uniquely identifying the project in repository.

It should be noted that there should be a single POM file for each project.
Projects notation in repository is groupId:artifactId:version.

Maven already added Junit as test framework. By default Maven adds a source file App.java and a test file AppTest.java in its default directory structure
C:\MVN\consumerBanking>mvn clean package
Maven will start building the project

consumerBanking contains src folder and pom.xml
src/main/java contains java code files under the package structure (com/companyName/bank).
src/main/test contains test java code files under the package structure (com/companyName/bank).
src/main/resources it contains images/properties files (In above example, we need to create this structure manually).

POM.xml file with following contents.

<project xmlns="http://maven.apache.org/POM/4.0.0"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
   http://maven.apache.org/xsd/maven-4.0.0.xsd">
      <modelVersion>4.0.0</modelVersion>
      <groupId>com.companyname.projectgroup</groupId>
      <artifactId>project</artifactId>
      <version>1.0</version>
      <dependencies>
         <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>3.8.1</version>
         </dependency>
      </dependencies>
</project>


Packaged jar is available in consumerBanking\target folder as consumerBanking-1.0-SNAPSHOT.jar.
Test reports are available in consumerBanking\target\surefire-reports folder.
Maven compiled source code file(s) and then test source code file(s).
Then Maven run the test cases.
Finally Maven created the package.

open command console, go to C:\MVN\consumerBanking\target\classes directory and execute the following java command.

C:\MVN\consumerBanking\target\classes>java com.companyname.bank.App
You will see the result
Hello World!

http://www.tutorialspoint.com/maven/maven_quick_guide.htm

• The differences between Ant and Maven in this example are:

Apache Ant

        Ant doesn’t have formal conventions like a common project directory structure or default behavior. You have to tell Ant exactly where to find the source and where to put the output. Informal conventions have emerged over time, but they haven’t been codified into the product.
        Ant is procedural. You have to tell Ant exactly what to do and when to do it. You have to tell it to compile, then copy, then compress.
        Ant doesn’t have a lifecycle. You have to define goals and goal dependencies. You have to attach a sequence of tasks to each goal manually.

Apache Maven

        Maven has conventions. It knows where your source code is because you followed the convention. Maven’s Compiler plugin put the bytecode in target/classes, and it produces a JAR file in target.
        Maven is declarative. All you had to do was create a pom.xml file and put your source in the default directory. Maven took care of the rest.
        Maven has a lifecycle which was invoked when you executed mvn install. This command told Maven to execute a series of sequential lifecycle phases until it reached the install lifecycle phase. As a side-effect of this journey through the lifecycle, Maven executed a number of default plugin goals which did things like compile and create a JAR.


mvn is the Maven 2 command. archetype:generate is called a Maven goal


(1)

The Maven Archetype plugin creates a directory simple/ that matches the artifactId. This is known as the project’s base directory.

(2)

Every Maven project has what is known as a Project Object Model (POM) in a file named pom.xml. This file describes the project, configures plugins, and declares dependencies.

(3)

Our project’s source code and resources are placed under src/main. In the case of our simple Java project this will consist of a few Java classes and some properties file. In another project, this could be the document root of a web application or configuration files for an application server. In a Java project, Java classes are placed in src/main/java and classpath resources are placed in src/main/resources.

(4)

Our project’s test cases are located in src/test. Under this directory, Java classes such as JUnit or TestNG tests are placed in src/test/java, and classpath resources for tests are located in src/test/resources.




http://books.sonatype.com/mvnex-book/reference/installation-sect-compare-ant-maven.html

• 1. In traditional way

    Visit http://logging.apache.org/log4j/
    Download the Log4j jar library
    Copy jar to project classpath
    Include it into your project dependency manually
    All manages by yourself, you need to do everything

If there is a Log4j version upgrade, you need to repeat above steps again.


2. In Maven way

    You need to know the log4j Maven coordinates, for example

     <groupId>log4j</groupId>
     <artifactId>log4j</artifactId>
     <version>1.2.14</version>

    It will download the log4j version 1.2.14 library automatically. If the “version” tag is ignored, it will upgrade the library automatically when there is a newer version.
    Declares Maven coordinates into pom.xml file.

    <dependencies>
        <dependency>
     <groupId>log4j</groupId>
     <artifactId>log4j</artifactId>
     <version>1.2.14</version>
        </dependency>
    </dependencies>

    When Maven is compiling or building, the log4j jar will be downloaded automatically and put it into your Maven local repository.
    All manages by Maven.

http://www.mkyong.com/maven/how-to-use-maven-dependency-to-download-library-automatically/

• Maven Build Life Cycle

Phase Handles Description
prepare-resources resource copying Resource copying can be customized in this phase.
compile compilation Source code compilation is done in this phase.
package packaging This phase creates the JAR / WAR package as mentioned in packaging in POM.xml.
install installation This phase installs the package in local / remote maven repository.

http://www.tutorialspoint.com/maven/maven_quick_guide.htm

• Generating Maven Java project compatible with Eclipse

mvn archetype:generate -DgroupId=net.javabeat.hibernate -DartifactId=HibernateHelloWorldXML -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

To make this project compatible with eclipse
mvn eclipse:eclipse

http://www.tuicool.com/articles/3QBJnu

• "pluginManagement" 

Within the pom.xml file of the parent project, we use the pluginManagement section to define plugins that should be available to the child modules.
The pluginManagement mechanism is an excellent way to avoid the DRY problem and not to duplicate Maven configuration within the inheriting projects.

Like "dependencyManagement" the "pluginManagement" in parent contains plugin elements intended to configure child project builds that inherit from this one. However, this only configures plugins that are actually referenced within the plugins element in the children. The children have every right to override pluginManagement definitions.
http://java-success.blogspot.com/2011/10/maven-interview-questions-and-answers.html

• Maven Build Profiles

A Build profile is a set of configuration values which can be used to set or override default values of Maven build.
Using a build profile, you can customize build for different environments such as Production v/s Development environments.
Profiles are specified in pom.xml file using its activeProfiles / profiles elements and are triggered in variety of ways. Profiles modify the POM at build time, and are used to give parameters different target environments (for example, the path of the database server in the development, testing, and production environments).

Types of Build Profile
Per Project Defined in the project POM file, pom.xml
Per User Defined in Maven settings xml file (%USER_HOME%/.m2/settings.xml)
Global Defined in Maven global settings xml file (%M2_HOME%/conf/settings.xml)

http://www.tutorialspoint.com/maven/maven_build_profiles.htm

• A profile in Maven is an alternative set of configuration values which set or override default values. 

Using a profile, you can customize a build for different environments.
Profiles are configured in the pom.xml and are given an identifier
you can run Maven with a command-line flag that tells Maven to execute goals in a specific profile

a profile named production that overrides the default configuration of the Maven Compiler plugin

<profiles> (1)
            <profile>
                <id>production</id> (2)
                    <build> (3)
                            <plugins>
                                <plugin>
                                    <groupId>org.apache.maven.plugins</groupId>
                                    <artifactId>maven-compiler-plugin</artifactId>
                                    <configuration>
                                        <debug>false</debug> (4)
                                            <optimize>true</optimize>
                                    </configuration>
                                </plugin>
                            </plugins>
                    </build>
            </profile>
    </profiles>


1
The profiles element is in the pom.xml, it contains one or more profile elements.
Since profiles override the default settings in a pom.xml, the profiles element is usually listed as the last element in a pom.xml

2
Each profile has to have an id element. This id element contains the name which is used to invoke this profile from the command-line. A profile is invoked by passing the -P<profile_id> command-line argument to Maven.

3
we’re overriding the behavior of the Compiler plugin and we have to override the plugin configuration which is normally enclosed in a build and a plugins element.


$ mvn clean install -Pproduction -X


you still don’t know exactly what a Maven profile is allowed to override. The short-answer to that question is that a Maven profile can override almost everything that you would have in a pom.xml.

the default build was designed for development and the production profile exists to provide configuration for a production environment.

What happens when you need to provide customizations based on variables like operating systems or JDK version?
Maven provides a way to "activate" a profile for different environmental parameters, this is called profile activation.

http://books.sonatype.com/mvnref-book/reference/profiles-sect-maven-profiles.html

• Don’t use deprecated references like ${artifactId} or ${pom.artifactId}. Use the new ${project.artifactId} syntax.

Try to avoid using inherited properties. Developers can easily forget that a certain property is used by a child POM and change the value breaking the build in an unexpected place. Secondly, its quite annoying not to be able to easily lookup a property without having to find and examine the parent POM.

Use properties to define the dependency versions. This way you can get an overview of all versions being used without having to scroll through multiple pages of dependency sections.


Use the pluginmanagement section of the parent pom to define versions for *all* plugins that your build uses, even standard maven plugins like maven-compile-plugin and maven-source-plugin. This way your build will not suddenly behave differently when a new version of a plugin is released


When using a parent POM that is not located in the directory directly above the current POM define an empty relativePath element in your parent section.


Use the dependency plugin to check your project for both unnecessary dependencies and undeclared-but-used-none-the-less dependencies. The goal is called ‘analyze’, so run the following command on the console: “mvn dependency:analyze”

Make sure the pom files contain all the repository references needed to download all dependencies. If you want to use a local repository instead of downloadin strait from the internet then use the maven settings file to define mirrors for the individual repositories that are defined in the poms.

Make sure the pom files contain all the repository references needed to download all dependencies. If you want to use a local repository instead of downloadin strait from the internet then use the maven settings file to define mirrors for the individual repositories that are defined in the poms.

http://www.javacodegeeks.com/2012/06/maven-best-practices.html

• Maven Continuous Integration Best Practices 

Here are seven tips for running Maven builds in a CI system such as Hudson.

#1 Automate Snapshot Deployment
it is best to let your CI system deploy your snapshots.
you need to couple CI with a repository manager like Nexus that can automatically purge snapshots.

#2 Isolate Local Repostitories
The main reason I like to have a local repository per project is that it’s the only way to test that your project is build-able against the artifacts in the corporate repository.

#3 Regularly Purge Local Repositories
To further validate the contents of the repository, and to manage the disk space, I purge the local repostories every night. This way if changes in the repository or artifacts are removed, the CI system will detect this. To keep it easy to purge all the local repositories


#4 Enable Batch Mode: maven -B
Tip: Enable -B (batch) mode on the build. This will make the logs shorter since it avoids the dependency download progress logging. It also ensures that the build won’t hang due to waiting for user input. (to enable globally in settings.xml:<interactiveMode>false</interactiveMode>)


#5 Enable Full Stack Traces
Tip: Enable -e to cause Maven to produce the full stack trace if there’s a build exception

#7 Always check for Snapshots
Tip: Enable -U to cause Maven to always check for new snapshots. (to enable globally in settings.xml: <updatePolicy>always</updatePolicy>….this goes on a repository definition)

http://blog.sonatype.com/people/2009/01/maven-continuous-integration-best-practices/#.UlZevF1jG70

• POM Best Practices

3.6.1. Grouping Dependencies

For example, let’s assume that your application uses Hibernate, a popular Object-Relational mapping framework.
Every project which uses Hibernate might also have a dependency on the Spring Framework and a MySQL JDBC driver.
Instead of having to include these dependencies in every project that uses Hibernate, Spring, and MySQL you could create a special POM that does nothing more than declare a set of common dependencies.
You could create a project called persistence-deps (short for Persistence Dependencies), and have every project that needs to do persistence depend on this convenience project:

If you create this project in a directory named persistence-deps, all you need to do is create this pom.xml and run mvn install.
Since the packaging type is pom, this POM is installed in your local repository. You can now add this project as a dependency and all of its dependencies will be added as transitive dependencies to your project.

When you declare a dependency on this persistence-deps project, don’t forget to specify the dependency type as pom.
  <dependency>
            <groupId>org.sonatype.mavenbook</groupId>
            <artifactId>persistence-deps</artifactId>
            <version>1.0</version>
            <type>pom</type>
        </dependency>

If you later decide to switch to a different JDBC driver (for example, JTDS), just replace the dependencies in the persistence-deps project to use net.+sourceforge.jtds:jtds+ instead of mysql:mysql-java-connector and update the version number. All projects depending on persistence-deps will use JTDS if they decide to update to the newer version.

3.6.2. Multi-module vs. Inheritance

There is a difference between inheriting from a parent project and being managed by a multimodule project.

A parent project is one that passes its values to its children.
A multimodule project simply manages a group of other subprojects or modules.

The multimodule relationship is defined from the topmost level downwards.
When setting up a multimodule project, you are simply telling a project that its build should include the specified modules.
Multimodule builds are to be used to group modules together in a single build

The parent-child relationship is defined from the leaf node upwards.


http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html#pom-relationships-sect-grouping-deps

• Maven's command-line options

    -B - runs Maven in batch mode, which is particularly useful when invoking Maven from a continuous server such as Bamboo because it avoids Maven's reporting of downloading progress
    -e - configures Maven to report detailed information about errors, which is particularly useful to debug problems that occur when Maven is invoked from a continuous server such as Atlassian Bamboo

The target folder is automatically deleted when you run mvn clean. Therefore, it's the best place to put all build artifacts, such as Java .class files, JAR files, and temporary files created during the build process

Maven's dependencyManagement section allows a parent pom.xml to define dependencies that are potentially reused in child projects.

For example, suppose a multi-module Java project makes extensive use of JUnit for unit testing. To specify the project dependency on JUnit, the project's parent pom.xml can use a dependencyManagement section as follows:
Dependency Management in parent pom.xml

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</dependencyManagement>


Note that each child project that uses JUnit must still specify its dependency on JUnit. However, the version and scope of the dependency should be omitted as this avoids duplication and ensures that the same dependency is used throughout the project.
Dependency in child pom.xml (version and scope inherited from parent)

<dependencies>
  <dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
  </dependency>
</dependencies>



The Maven Dependency Plugin has an analyze goal that identifies two types of dependency issues in a project:

    Dependencies that are directly used but are not declared. (The project still compiles because it gets the dependencies transitively.)
    Dependencies that are declared but are unused.


http://www.kyleblaney.com/maven-best-practices/

• Maven Profile Best Practices

One way to activate a profile is to simply launch Maven with a -P flag followed by the desired profile name(s)
they can also be activated automatically according to a range of contextual conditions: JDK version, OS name and version, presence or absence of a specific file or property.


http://java.dzone.com/articles/maven-profile-best-practices

• When setting up a maven project consisting of multiple modules there are multiple ways to define the project dependencies.

1-    Use one top level directory containing only module subfolders. The parent/module-POM resides in it's own module subdirectory (e.g. project-parent)
2-    Use one top level directory containing module subfolders  and the parent/module-POM.
3-    Use one top level directory containing module subfolders and a POM file defining the modules of the project. The parent-POM resides in a submodule folder.


Approach 3
Plus Side:

    Parent POM is easily defineable as project in your IDE
    Module definitions are separated from project configuration enabling the project to have multiple module set definition, e.g. have a definition to build only a subset of all modules - for impatient developers(like myself ;-)).
    Good integration with continuous integration systems because module definitions do not interfere with standalone module builds.

Minus Side:

    POMs containing module definitions may be difficult to integrate in IDE.

Especially the compatibility with both IDEs and continuous build systems like Hudson make your work a lot easier.

A sample minimal project can be downloaded from https://github.com/jabbrwcky/sample-maven-structure

http://maventweaks.blogspot.com/2010/10/best-practices-for-multi-module-project.html

• Maven: The Aggregator vs. The Parent 

Aggregator POM
A top-level module serving for joining multiple modules under one roof is called aggregator.
Its purpose is only represent more or less independently existing modules as a parts of a greater whole.

 aggreator pom.xml:

<project xmlns="...">

<modelVersion>4.0.0</modelVersion>

<groupId>org.bithill</groupId>
<artifactId>aggregator</artifactId>
<packaging>pom</packaging>
<version>1.0</version>
<name>Project Aggregator</name>

<modules>
 <module>project1</module>
 <module>project2</module>
</modules>

</project>


Parent POM

aggregator does not include any information about dependencies
Parent POM includes all the properties, dependencyManagement and pluginManagement sections stating versions of projects dependencies and plugins and some plugin configurations when it comes handy.
http://rostislav-matl.blogspot.com/2011/12/maven-aggregator-vs-parent.html

• we create a multi-module project that combines the examples  simple-weather code and simple-webapp.A multi-module project is defined by a parent POM referencing one or more submodules.

http://books.sonatype.com/mvnex-book/reference/multimodule-sect-simple-parent.html

• Dependency scope is used to limit the transitivity of a dependency, and also to affect the classpath used for various build tasks.

<scope>compile</scope>

This is the default scope, used if none is specified. Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects

Compile means you need the JAR for compiling and running. For a web application, JAR will be placed in the WEB-INF/lib directory

<scope>provided</scope>

This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.

Provided means that you need the JAR for compiling, but at run time there is already a JAR provided by the environment.Mostly environment is container and JAR will not be placed under WEB-INF/lib

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

• versions:display-property-updates scans a projectand produces a report of those properties which are used to control artifact versions and which properies have newer versions available.

versions:display-plugin-updates scans a project's plugins and produces a report of those plugins which have newer versions available.

versions:display-dependency-updates scans a project's dependencies and produces a report of those dependencies which have newer versions available.

versions:use-latest-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the latest release version.

versions:update-properties updates properties defined in a project so that they correspond to the latest available version of specific dependencies. This can be useful if a suite of dependencies must all be locked to one version.

http://mojo.codehaus.org/versions-maven-plugin/

• Maven Jetty Plugin Configuration Guide

mvn jetty:run

This will start Jetty running on port 8080 and serving your project.

It is extremely convenient to leave the plugin running because it can be configured to periodically scan for changes and automatically redeploy the webapp.

This makes the development cycle much more productive by eliminating the build and deploy steps:

you use your IDE to make changes to the project and the running web container will automatically pick them up, allowing you to test them straight away.

• Finding duplicate classes in your WAR files with Tattletale

http://blog.csanchez.org/2011/03/23/finding-duplicate-classes-in-your-war-files-with-tattletale/

• Tattletale is a tool that can help you get an overview of the project you are working on or a product that you depend on.

http://tattletale.jboss.org/

• JBoss Tattletale integrates with Apache Maven such that you can generate the reports directly from your build environment.

To be able to use the Tattletale Maven plugin in your Maven project, you will have to add the following plugin declaration in the pom.xml of your project:

http://docs.jboss.org/tattletale/userguide/1.2/en-US/html/maven.html

• Have you ever found all sorts of weird errors when running your webapp because several jar files included have the same classes in different versions and the wrong one is being picked up by the application server?

http://java.dzone.com/articles/finding-duplicate-classes-your

• There are two locations where a settings.xml file may live

    The Maven install: $M2_HOME/conf/settings.xml    also called global settings

    A user's install: ${user.home}/.m2/settings.xml        referred to as user settings.

   

If both files exists, their contents gets merged, with the user-specific settings.xml being dominant.

Tip: If you need to create user-specific settings from scratch, it's easiest to copy the global settings from your Maven installation to your ${user.home}/.m2 directory. Maven's default settings.xml is a template with comments and examples so you can quickly tweak it to match your needs.

https://maven.apache.org/settings.html#Servers

Builds were typically done straight from the developer’s IDE and manually deployed to one of our app servers.  We had a manual process in place, where the developer would do the following steps.

    Check all project code into Subversion and tag

    Build the application.

    Archive the application binary to a network drive

    Deploy to production

    Update our deployment wiki with the date and version number of the app that was just deployed.

The problem is that there were occasionally times where one of these steps were missed, and it always seemed to be at a time when we needed to either rollback to the previous version, or branch from the tag to do a bugfix.  Sometimes the previous version had not been archived to the network, or the developer forgot to tag SVN.  We were already using Jenkins to perform automated builds, so we wanted to look at extending it further to perform release builds.

The Maven Release plug-in provides a good starting point for creating an automated release process.

We have also just started using the Nexus Maven repository and wanted to incorporate that as well to archive our binaries to, rather than archiving them to a network drive.

http://rterp.wordpress.com/tag/build-pipeline/

• The Maven Release Cycle

Deploying a release involves many tasks

Commit all current changes to version control

Upgrade the version number(s) and commit the changes

Tag the release version

Build and deploy this version

Update the version number and commit the changes

Building your release process on solid building blocks:

The Maven Enterprise Repository

The Maven Release Cycle

Deploying a release involves many tasks

Commit all current changes to version control

Upgrade the version number(s) and commit the changes

Tag the release version

Build and deploy this version

Update the version number and commit the changes

The Maven Release Plugin automates this process

Automates the release process

Updates version numbers

Commits changes and creates new SCM tags

Builds, tests and deploys to the Enterprise Repository

• Apache Tomcat Maven Plugin

to run your war project with an embedded Apache Tomcat. The run goals give you the opportunity to quickly develop your application without needing to install a standalone Tomcat instance. More details and features

http://tomcat.apache.org/maven-plugin-2.1/index.html

• The POM was renamed from project.xml in Maven 1 to pom.xml in Maven 2. Instead of having a maven.xml file that contains the goals that can be executed, the goals or plugins are now configured in the pom.xml. When executing a task or goal, Maven looks for the POM in the current directory. It reads the POM, gets the needed configuration information, then executes the goal.

http://maven.apache.org/guides/introduction/introduction-to-the-pom.html

• there is one aspect of Maven-based development that's potentially troublesome: the reliance on a remote central repository somewhere on the Internet.

When a new developer joins a team, every single dependency is copied from the remote repository to his or her local repository cache

This places an unnecessarily large load on the company's or individual's Internet link for the duration of the dependency download. Even worse, should the Internet link go down, the developer is unable to work.

So what's the answer to all that wasted Internet bandwidth? A local Maven proxy. The first time a developer requests a dependency, it is copied from the central repository to the local repository, which resides on the machine running the proxy. Subsequent requests by developers in the team are then fed the copy from the local repository, typically on the same local area network (LAN). That translates to quicker builds and — as long as no new dependencies are needed — no reliance on the corporate Internet link for builds.

http://www.openlogic.com/wazi/bid/188151/

• Maven Archetypes are project templates that allow users easily create new projects. Maven Archetypes are great way to share best practices and enforce consistency beyond Maven’s standard directory structure. For example, an organization can provide its developers an archetype bundled with company’s approved CSS and JavaScript libraries.

I have been creating a lot of Spring MVC based projects and each time I do, I copy a lot of information (configuration files, css files, dependency information etc) from an existing project. Following the DRY principles, I decided to create several Spring MVC based archetypes that can help me bootstrap my projects quickly

http://blog.inflinx.com/2010/04/16/creating-maven-archetypes-spring-mvc-example/

• Using the Build Cache for Apache Maven

While Maven does not provide support for incremental builds, the Gradle Enterprise build cache allows you to reuse outputs of goal executions from any previous build.
Thus, it avoids executing costly goals and accelerates your Maven builds significantly.
The remote build cache takes this even one step further: it allows you to share cached outputs across your whole team, including local and CI builds.
https://docs.gradle.com/enterprise/maven-build-cache/

• Remote Caching

A remote cache is used by a team of developers and/or a continuous integration (CI) system to share build outputs. If your build is reproducible, the outputs from one machine can be safely reused on another machine, which can make builds significantly faster
https://docs.bazel.build/versions/master/remote-caching.html

• Differences between Maven and Bazel

    Maven uses top-level pom.xml file(s). Bazel supports multiple build files and multiple targets per BUILD file, allowing for builds that are more incremental than Maven’s.
    Maven takes charge of steps for the deployment process. Bazel does not automate deployment.
    Bazel enables you to express dependencies between languages.
    As you add new sections to the project, with Bazel you may need to add new BUILD files. Best practice is to add a BUILD file to each new Java package.
https://docs.bazel.build/versions/master/migrate-maven.html