<project>
    <groupId>org.koshik.javabrains</groupId>
    <artifactId>JarName</artifactId> (A fldernamed JarName was created) 
    <version>1.0-SNAPSHOT</version>
    <packaging>jar</packaging>

    <name>JarName</name>
    <url>http://maven.apache.org</url>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

    <build>
        <plugins>
            <plugin>
                <groupId>org.jibx</groupId>
                <artifactId>jibx-maven-plugin</artifactId>
                <version>1.2.4</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>bind</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>3.8.1</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

字符串
如果你使用maven配置文件，你也可以把插件放在<profile>的<build>部分，顺序无关紧要。

对两个重要问题的迟来澄清
在哪里放置plugin

在大多数情况下，确实应该在build/plugins部分中添加plugin，但是将其放置在plugins中与将其放置在pluginManagement/plugins中之间有重要的区别。
这种误解经常是Maven中未调用插件或更难故障排除的原因：

• build/plugins下的插件直接是默认Maven构建的一部分，如果它们指定了execution或为默认构建配置了某些内容（参见下文）
• build/pluginManagement/plugins下的插件不是默认Maven构建的一部分，也就是说，是一个管理，这是对maven的一个提示：如果你碰巧使用这个插件，那么请使用我在这里指定的版本，配置，执行，在这个管理中。
  **但 * 碰巧使用 * 意味着什么？意味着：如果build/plugins部分也存在相同的插件，则应用此管理（只有这样它才有效）;或如果Maven默认调用该插件，则也应用它。
  **但默认情况下如何调用插件？**这是maven背后的主要哲学的一部分：约定优于配置。按照约定，当您指定某个packaging时，（默认为jar，但也可以是war），你希望调用某些插件。要构建jar，默认情况下调用maven-jar-plugin;要构建war，默认情况下会调用maven-war-plugin等等。因此，如果您在build/pluginManagement/plugin中为一个默认绑定到Maven构建的插件指定插件配置，那么它也会被使用。
  订购

关于pom.xml文件中各节的顺序，需要进一步说明：这在大多数情况下确实是无关紧要的，但是build/plugins部分中plugin元素的顺序可能很重要。由于Maven3.0.3（MNG-2258），附加到同一个Maven阶段的不同插件执行将按照它们在pom.xml文件中声明的顺序被调用。也就是说，在这种情况下，顺序很重要，因为它可能会影响构建的行为。
另外，dependency声明的顺序也会影响Dependency Mediation的构建，也就是说，在与传递依赖发生冲突的情况下，第一个声明的依赖获胜。所以，再次强调，在某些情况下，顺序很重要。
最后但并非最不重要的一点是，尽管顺序对于pom.xml文件的其他部分并不重要，但好的习惯是遵循官方的Maven recommendations，并且作为简化版本，遵循以下声明顺序：

<project>
  <modelVersion/>

  <parent/>

  <groupId/>
  <artifactId/>
  <version/>
  <packaging/>

  <properties/>

  <dependencyManagement/>
  <dependencies/>

  <build/>

  <reporting/>

  <profiles/>
</project>

字符串
sortpom-maven-plugin也可以用于自动应用此标准排序，只需在相关的pom.xml文件上调用以下命令：

mvn com.github.ekryd.sortpom:sortpom-maven-plugin:2.5.0:sort \
     -Dsort.keepBlankLines -Dsort.predefinedSortOrder=recommended_2008_06

型

进一步阅读：

• Stack Overflow: Maven: what is pluginManagement?的
• 官方Maven文档：Maven POM参考，PluginManagement
• Official Maven default bindings
• Official Maven doc: Dependency Mediation
• Official Maven doc: Maven Code Style And Code Conventions字符串

<plugin>应该放在<plugins>部分，<plugins>部分应该放在<build>或<pluginManagement>部分。<dependency>或<build>部分的顺序无关紧要。
关于pom.xml的完整参考资料在这里：http://maven.apache.org/pom.html

您可以将第二个代码片段插入pom.xml文件中两个<plugins></plugins>标记之间的任何位置。

如果你想使用插件来构建，你可以使用下面的结构。

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

字符串

POM中的节顺序并不重要。通常，Maven中有构建插件和报告插件。您的情况是使用构建插件，因此必须将此<plugin>块放入<project><build><plugins>...节中。
看看this了解一些关于插件的基础知识。

作为报告插件（例如maven-checkstyle-plugin）的附加答案，在pom.xml中，插件可以在build和reporting下使用2个标签。
使用报告标签VS构建标签
在pom中的<reporting>或<build>元素中配置报告插件不会有相同的行为！

mvn site

字符串
它只使用<reporting>元素中指定的每个报告插件的<configuration>元素中定义的参数，即站点总是忽略<build>中指定的每个插件的<configuration>元素中定义的参数。

mvn aplugin:areportgoal

型
它首先使用在<reporting>元素中指定的每个报告插件的<configuration>元素中定义的参数;如果找不到参数，它将查找在<build>中指定的每个插件的<configuration>元素中定义的参数。
来源：https://maven.apache.org/guides/mini/guide-configuring-plugins.html#Using_the_reporting_Tag_VS_build_Tag