Foreword believe that as long as the Java development of children's shoes, ant must not be unfamiliar, we often use ant to build projects, especially involving a particularly complex workload, a build.xml can complete the compilation, testing, packaging, deployment and many other tasks, This frees the programmers ' hands to a great extent. But at the same time there are some other problems, such as: Jar file management Confusion, each time need to download themselves, build.xml due to the different project structure, resulting in a large number of differences. Overview Since the introduction of MAVEN into the project, MAVEN has provided a more concise solution than previously ant can solve, and Maven has been able to solve the problem previously. This leads directly to the upgrading of project management tools. Of course, this is nothing new. It's just that, until now, it's time to share the experience with Maven in the project, and I'm really sorry, and the follow-up will be updated in a timely manner. There's a lot of maven getting started online, so don't go into the basics here. If you have not touched Maven's children's shoes, please visit Google or Baidu. Then come back and read this article. In this article, I mainly discuss with you the use of Maven in the project, as well as the matters needing attention. principles The principle of Maven, in fact, is very simple, is the use of remote warehouses and local warehouses and a similar build.xml pom.xml, the jar files defined in Pom.xml from the remote repository to the local warehouse, Each application uses the same local repository jar, the same version of the jar is downloaded only once, and avoids having to copy the jar for each application. It uses the now popular plug-in architecture, keeping only the smallest core, the rest of the functionality is provided via plug-ins, so maven downloads are small (1.1M), and the required plugins are downloaded automatically when the MAVEN task is performed. Also, Maven is cross-platform and offers extensions that support many Java Ides. In development, we spend most of our time using Maven's plugins. For the inside of the company, there is still a need to establish their own, but this is not the focus, it is no longer discussed. Structure Project we will create a directory structure according to their own habits, although there are norms, but inevitably there will be omissions, long this, the structure of the project will be more and more chaotic. Maven solves this problem, and for different projects, it provides a variety of choices and as a catalog template, as shown in. the use of directory templates, you can make pom.xml more concise. Because the MAVEN2 has predefined related actions based on the default directory, no manual intervention is required. Take the resources directory as an example:
- Src/main/resources, responsible for managing the resources of the project subject. After executing compile with Maven2, all files and subdirectories in this directory are copied to the Target/classes directory, which provides convenience for future packaging.
- Src/test/resources, responsible for managing the resources of the project test. After executing test-compile with Maven2, all files and subdirectories in this directory are copied to the Target/test-classes directory, ready for subsequent tests.
These actions are in Maven1 and need to be done using <preGoal> or <postGoal> in Maven.xml. Today, you can do this automatically without having to specify it in Pom.xml. The use of resources in both SRC and test, which is easy to build and test, has been the experience of previous generations. By using MAVEN2, this experience has been popularized in the development team. The life cycle has a clear lifecycle concept in Maven2 and provides the corresponding commands to make project construction clearer. The main life cycle phase:
- Validate, verify that the project is correct and that all required resources are available.
- Verify, run any checks to verify that the package is valid and meets the quality standards.
- Integration-test, process and publish packages in an environment where integration testing can run.
- Generate-sources, generate any additional source code that the application requires, such as Xdoclet.
- Compile, compile the source code for the project.
- Test-compile, compile the project test code.
- Test, testing the compiled source code with the compiled test code.
- Package, a published format, such as a jar, packages the compiled source code.
- Install, the package is installed in the local repository, can be used as a dependency of other projects.
- Deploy, implemented in a consolidated or released environment, copies the final version of the package to a remote repository, allowing other developers or projects to share.
If you want to perform a project compilation, then direct input: mvn compile, for the other stages can be analogous. There is a dependency relationship (dependency) between the phases, such as test-dependent test-compile. When you execute MVN test, the MVN Test-compile is run first and then MVN test. Of course, in development, we generally do not directly manipulate Maven. Instead, the Maven plugin is used in Eclipse, with the most commands being clean, compile, install, deploy, and so on. depend on say the life cycle, there is a need to say that is dependent on management. In Maven, the jar package is introduced by adding dependencies to the pom.xml. The principle is that each jar will have its own coordinates, and Maven is going through the coordinates to locate the specific jar. , like a planar coordinate system, locates a coordinate point by the x-axis and y-axis. MAVEN defines a set of rules: Any component in the world can be uniquely identified with MAVEN coordinates, including GroupId, Artifactid, version, packaging, classifier, and the Maven coordinate elements. As long as we provide the correct coordinate elements, Maven will be able to find it. Suggestions Some people may have doubts, before Maven, we can go to the respective website to download the jar, but now only through the POM reference jar. So how do you know what dependencies you need to add? What version do you need? That's why some of them are used to downloading jars, and Maven doesn't know how to use them. Of course, MAVEN is not smart, and you can't directly command maven to give you the various components you need for a project, and perhaps later, an intelligent software management tool will appear, at least for now. Therefore, you need to add pom dependencies yourself. As for how to find this, here I tell you a way, although the method is a bit stupid, but perhaps it is helpful for you to quickly locate the specific components. For example, if you now need to add Hibernate dependency, but which version of it, you can do without the tube, directly to Baidu or Google, "Maven Spring repository" for the keyword search, often the first link , is the solution you need. After entering the first link, you will see a page that searches forThe results are all about Spring, depending on your needs, choose a link to enter, the list of versions of the components, click on the version you need, then you will see the Maven coordinates. Copy it into your pom file. of course, it's just a way to focus on the kids ' shoes just touching Maven. As your project experience increases, you will increasingly discover that Maven frees you not only your hands, but your most valuable time. feel Choosing to use a management tool in a project is risky, so how do you minimize it or turn it into a positive aspect of project development? This requires an architect or project leader to conduct rigorous technical inspection, technical (tool) selection, and study cost analysis prior to the commencement of the project. Choose a technology or a tool, not just because of its popularity, but also to consider the technical level of the company's developers, technology (tools) cross-platform considerations, scalability and integration considerations, as well as technology (tool) stability considerations. Of course, for a new technology (a new technology for developers), it is also necessary to consider the cost of learning, which restricts future development efficiency, development progress, and the problem can not be solved. The so-called technology selection, is not to choose how new technology, nor to choose the lowest cost technology, but can use the company's advantages, to find the most suitable for the company's technology and tools, within a limited scope, limited time to the company's ability to maximize. For example, if in the project management tools, the company has been using ANT, but also with special proficiency, and the project time is particularly urgent, the company's developers have no contact with Maven, then no longer consider Maven, because time is there, And there are developers of learning costs, in this case, then choose Maven, this is not Zuo Si? Of course, there are countless examples of this, and there's no more talking about it. concluding remarks should be in the final words, are placed in the feeling inside, for project management, there are many deficiencies, I hope in the future work continue to accumulate experience it. Of course, we also hope that we can communicate more and make progress together. Transfer from:http://blog.csdn.net/happylee6688/article/details/38798669
Maven Project management tool (GO)
