idea mvn trampling pit using mvn packaging

Posted by ruddyu78 on Sun, 12 May 2019 11:14:57 +0200

Recently, I started learning Spring Cloud. One of the pitfalls in using mvn packaging is that it succeeded in packaging, but none of the dependencies were introduced.
(I joined the spring boot mvn plugin). The jar package is only a few kb. I searched a lot on the internet, but all of them are saying that spring boot mvn plugin needs to be introduced.
So I can only find it slowly by myself, and eventually found that all the mvn projects I created were more than others, for example, many labels displayed by many people did not have this, and then I searched online, others explained that this is the plug-in version used by the parent project to unify the management of sub-projects, and it will not be referenced when loading.... Instantly understand that my spring boot mvn plugin is placed in this label.
So I removed the label and found a terrible problem. If I could not remove it, the reporting tool of mvn would be wrong and all the functions would be useless.
mmp... I had to find another way to solve this problem. It bothered me for a day.
Then try to recreate a project that was created with mvn
Archetype maven-archetype-quickstart in idea will load automatically
Many plug-ins, such as

  <build>
    <pluginManagement><!-- lock down plugins versions to avoid using Maven defaults (may be moved to parent pom) -->
      <plugins>
        <!-- clean lifecycle, see https://maven.apache.org/ref/current/maven-core/lifecycles.html#clean_Lifecycle -->
        <plugin>
          <artifactId>maven-clean-plugin</artifactId>
          <version>3.1.0</version>
        </plugin>
        <!-- default lifecycle, jar packaging: see https://maven.apache.org/ref/current/maven-core/default-bindings.html#Plugin_bindings_for_jar_packaging -->
        <plugin>
          <artifactId>maven-resources-plugin</artifactId>
          <version>3.0.2</version>
        </plugin>
        <plugin>
          <artifactId>maven-compiler-plugin</artifactId>
          <version>3.8.0</version>
        </plugin>
        <plugin>
          <artifactId>maven-surefire-plugin</artifactId>
          <version>2.22.1</version>
        </plugin>
        <plugin>
          <artifactId>maven-jar-plugin</artifactId>
          <version>3.0.2</version>
        </plugin>
        <plugin>
          <artifactId>maven-install-plugin</artifactId>
          <version>2.5.2</version>
        </plugin>
        <plugin>
          <artifactId>maven-deploy-plugin</artifactId>
          <version>2.8.2</version>
        </plugin>
        <!-- site lifecycle, see https://maven.apache.org/ref/current/maven-core/lifecycles.html#site_Lifecycle -->
        <plugin>
          <artifactId>maven-site-plugin</artifactId>
          <version>3.7.1</version>
        </plugin>
        <plugin>
          <artifactId>maven-project-info-reports-plugin</artifactId>
          <version>3.0.0</version>
        </plugin>
      </plugins>
    </pluginManagement>
  </build>

Error prompt unresolve d... Anyway, it feels strange that it's all mistake I don't want to take care of.

The solution is to recreate the project, but without mvn templates that do not refer to archtype, there will be no such problem

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                </configuration>
            </plugin>
        </plugins>
    </build>

Click package

Package success


implement
java -jar registrationCenter.jar
Successful runs do not report without sending to find the main list attributes, that is, there is no main-class path

      . eclipse doesn't have such a problem. idea doesn't feel friendly to me
     It is impossible to solve the problem of packaging failure caused by archtype application. If there is a solution, we should ask the elder brother to inform the younger brother.

Topics: Maven Spring Apache Java