WARNING: A child container failed during start
java.util.concurrent.ExecutionException: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Tomcat].StandardHost[localhost]]
	at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
	at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
	at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1123)
	at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:302)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
	at org.apache.catalina.core.StandardService.startInternal(StandardService.java:443)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
	at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:732)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
	at org.apache.catalina.startup.Tomcat.start(Tomcat.java:341)
	at org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo.startContainer(AbstractRunMojo.java:1238)
	at org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo.execute(AbstractRunMojo.java:592)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:972)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:293)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:196)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
	at org.codehaus.classworlds.Launcher.main(Launcher.java:47)

The code change adds the following servlet dependency, and it starts successfully if you remove it, but it reports an error if you remove the reference to the project.
The reason is that adding the servlet dependency caused a conflict with another dependency when packaging.

Solution

You only need to add the scope tag in the dependency to exclude the servlet-api we introduced when packaging the project, as shown below

Classification of scope

Maven’s default dependency configuration items, the default value of scope is compile, the project is often silly to distinguish between the direct default. Today to sort out maven’s scope.

• compile: the default is compile, nothing is configured, which means compile. compile means that the dependent project needs to participate in the compilation of the current project, of course, the subsequent test, runtime also participate in it, is a relatively strong dependency. This is a strong dependency. It is usually included when packaging.
• test: The scope is test, which means that the dependent project is only involved in the test-related work, including the compilation and execution of the test code. Typical examples are junit.
• runntime: The dependent project does not need to be involved in the compilation of the project, but it is required to be involved in the later testing and runtime cycles. Compared with compile, it just skips the compilation. To be honest, in the terminal project (non-open source, internal system), the difference with compile is not very big. The API jar corresponding to the implementation of JSR×××× is compiled, and the specific implementation is runtime, which is enough for compile to know the interface. oracle jdbc driver package is a good example, and the general scope is runntime. I can use A to achieve it, or B to achieve it.
• provided: provided means that it can be packaged without being packaged in, and other facilities (Web Container) will provide it. In fact, the dependency can theoretically participate in the compile, test, run, etc. cycle. It is equivalent to compile, but with the exclude action done during the packaging phase.
• system: In terms of involvement, it is the same as provided, but the dependencies are not grabbed from the maven repository, but from the local filesystem.