we have to use maven for building the code. I understand the jar file can be created using exclude files. But, how to create the war file containing all the files. Using POM, we can create only single artifact.
Also, we have multiple projects say 10 projects which will generate 10 jars and a single war containing all jars with all jsps, css, js files.
Hi Ron, We need to build jar as well as war from same source code. Jar file is used to run on Unix as a java process - some schedularsetc. without any UI. and war is used to run as a web application having UI and backend.
So, jar should contain only proj/web/java class files and war shouldcontain all the files. And, i have given only one example folder we have around 30 such folders. SO, how to create 30 jars for classes and one war containing all java classes and jsp, css etc.
Ron has the right of it, put the classes in one project that builds a JAR, and put the web pages in another project that builds a WAR. The project that builds the WAR should have a dependency on the project that builds the JAR. Then, if you really want, you can configure your WAR project to include all its dependencies in the final artifact.
1. Build a JAR. Catalog it in your Maven repository.
2. Build a WAR, where the above JAR will be copied into the WAR's /WEB-INF/lib directory. There is no benefit to compiling the JAR classes directly into the /WEB-INF/classes directory. The net effect is the same either way and including the JAR is a lot less messy.
This approach means that you need 2 separate Maven projects, each with theit own POM. And, of course, if you're using an IDE, those 2 Maven projects should appear as separate IDE projects.
Now we get into logistical issues - that is, how tightly development of the JAR is bound to the WAR. You have 2 basic options. One is to define direct dependency of the WAR POM upon the JAR POM so that changes on the JAR will automatically trigger rebuilding of the WAR. The other option is for looser coupling. That is, the WAR POM demands a specific version of the JAR and has to explicitly requirest it, with that version having been built earlier. The second approach would be more appropriate for a single JAR used by multiple other projects, or in cases where it's more important to have a guaranteed-good release of the WAR than the latest build.
Externally, you could also implement build dependencies via a build system such as Jenkins. If different people will be working on the JAR and the WAR, you'd also want a shared local Maven repository such as Nexus.
Some people, when well-known sources tell them that fire will burn them, don't put their hands in the fire.
Some people, being skeptical, will put their hands in the fire, get burned, and learn not to put their hands in the fire.
And some people, believing that they know better than well-known sources, will claim it's a lie, put their hands in the fire, and continue to scream it's a lie even as their hands burn down to charred stumps.
Story like this gets better after being told a few times. Or maybe it's just a tiny ad:
SKIP - a book about connecting industrious people with elderly land owners