MAVEN packs jsp/js/jsp static resources into JAR packages (Servlet3.0 modular features are used with Maven) __java

First spit, I stepped on a lot of pits, tears, ah, because not familiar with Maven, there are eclipse bugs, online article information asymmetry ...
Well, back to the point, we need to be like this: A project is made up of multiple projects. Because the project is complex and large, it is better to divide it into multiple subprojects (or engineering). So the question is, how do the dependencies of the parent and child engineering work? What to do with packaged builds. How to break. With Maven, we all know that Maven is strong, but with a powerful synonym it's complicated. That's why I used to love ant instead of maven. As we all know, the project will eventually be packaged for Jar/war deployment. For the IDE, from its perspective, in fact, there is an implicit built-in environment: we develop the time, knock Code, test, bug the IDE environment, is our developers mainly spend time in the environment, when the IDE can check whether the dependent package imported, can provide code association function ... And so on--the two environments are different, so it's not the same thing to do--that's why the IDE relies on the correct code when it comes to it, but it doesn't look like a problem, but the runtime complains about why Class not Found; the first is the development environment. We hope that each item is dependent on the automatic, synchronized. What does it mean. Is that subproject B relies on the parent project A, I have modified the code of a, B there will be a reaction, know. No one wants to build a a bit by hand B engineering can be used, this should be maven/eclipse backstage automatically help us do. It's a common requirement, okay, maven can do this, as long as the Pom.xml declaration depends on (of course, the premise is local engineering) as shown in the following figure, depending on the Ajaxjs-base/data two projects, code can be automatically synchronized
visible that is not a jar package. But if you close the Ajaxjs-base/data project in Eclipse, then Maven does not rely on local engineering, but provides jar packs; Well, so far, everything's fine. But just for pure Java projects. Web engineering is not good, can not automatically sync ... Here's one more word, no contact maven, I use the Eclipse Link resource function, build war also can, is quite good, sync any files can. The package failed.

For a long while, Shen Nong's method of experimenting with paraquat has been tried without much effort. MAVEN will make the entire Web project a jar rather than a standard Java jar package.
Later emperor, the correct operating posture is dependent on the war package:

"Dependency type War enables war package dependencies, B relies on a, and when packaged, the classes and files of a are typed in."

<dependency>
<groupId>com.handlecode</groupId>
<artifactid>diy-biz</ artifactid>
<version>${diy.version}</version>
<type>war</type>
</ Dependency>

http://blog.csdn.net/sxhong/article/details/72869359

Of course the dependent project type is war.

This web-inf will have a package containing the war, which is the temporary directory for Eclipse debugging.
Don't ask why it can be war, others are jars. I do not know, anyway can read inside the class ...

Then the build is Gone with the Maven-war-plugin plugin. Again, the problem is divided into two aspects, one is to meet the development environment matching, one is the final packaging environment matching. Solving a problem does not mean solving another problem, and sometimes two problems are contradictory.
This approach is limited to Java code reuse and synchronization. Packaging jsp/html/js/jpg Resources

Depending on the war package, the project can be imported into the parent project class. But 1, that is not a jar package, and contains other useless JSP, etc. 2, can not import static resources; 3, the parent project must be a war class, and I want to build a jar for others, change pom.xml is ok but very troublesome.

A friend asked why Jsp/html/js/jpg resources to import jars. Reuse Bai, reused Bai ~ are common resources. Please take a look at the new Servlet 3.0 features:

In the SERVLET3.0 protocol specification: ${jar}/meta-inf/resources/is treated as the root directory. Then the JSP and other static resources into the meta-inf/resources/directory is no different from the actual project.

This means that the JSP can be run in jars. And Webfragment.xml should also be supported.
I think this is very valuable, especially the whole stack of JS code of course want to pull in. You know it.
Please continue to see the specific operation. Enable Webfragment Project

Standard things Eclispe definitely support, but rarely used.

The Webfragment project is characterized by not being able to run in Tomcat, other than the standard Dynamicweb project.
You do not want to create new project also can, change project fact Bai ~

Eclipse can not be changed in the UI, change the configuration Bai,
Find Org.eclipse.wst.common.project.facet.core.xml

<?xml version= "1.0" encoding= "UTF-8"?>
<faceted-project>
  <fixed facet= "Wst.jsdt.web"/>
  <installed facet= "java" version= "1.7"/> <installed facet= "wst.jsdt.web"
  version= "1.0"/>
  <installed facet= "jst.webfragment" version= "3.0"/>
</faceted-project>

All right, convert to Maven project .

Of course, you can also create a new MAVEN project Porject fact, the order does not matter. Pom.xml Be sure to set the jar type
Deployment Assembly Settings

In fact, even dynamicweb engineering can be, because the key setting is Deployment Assembly, set right on the line.
But let's be clear about the requirements, and the jar packages that we want to generate are like this.

Mea-inf Directory has web-fragment.xml;resources is like webcontent, are jsp/js you like to put anything; tags are put TLD custom label (spit slot does not support the tag files. ）
This structure must be placed in a servlet container such as Tomcat or jetty to be read under Web-inf/lib.
The play is coming. Deployment Assembly must be such a droplet:
Specifies the/meta-inf corresponding root directory. In fact, WebContent directory does not need to exist, are placed under Meta-inf good/src/main is the designated Java files, put me to the root directory down ~

Well, that's the structure inside the jar. Every time you modify something, including Jsp,b, the project will be known simultaneously. Eclispe/mavne will toil in the back and pack it like this:
Finally, add up to now just say the development environment packaging, not to say build packaging. I've done it before, it can't be hard, it's certainly more flexible and free than eclipse. Mine is not the directory structure of the standard MAVEN project, but the traditional Dynamicweb project structure, somewhat different but not affected, the key configuration pairs on the line (insert a sentence here, before the NI error appears "Updating status for Tomcat v6.0 Server at LocalHost ... ". Java.lang.NullPointerException inexplicably, and then upgrades Eclipse on the line)

Reference:
http://blog.csdn.net/sxhong/article/details/72869359
http://blog.csdn.net/u011666411/article/ details/77160907
http://blog.csdn.net/mafan121/article/details/51862933
https://segmentfault.com/a/ 1190000007166005