Usecase: Pack a war that includes only a limited set of the webapp's dependencies.
Usecase: To run from the development machines, need ejb*-client, only. And for deployment on the production server, those dependencies have to be omitted.
Solution: Still profiles. Create a "test" profile where the dependencies used only for the development machines (ejb*-client) are declared.
Concern: Don't want to duplicate all the dependencies of our-ejb-facade in the webapp's pom.
Answer: There will be no duplicates here because, like what Trygve said, you only need to declare the uncommon artifacts (in this case your ejb*-client dependencies).
Usecase: Packaging three .war files in a .ear. They share most of their dependencies. Same as "Developer packages multiple war files in an ear and wants to consolidate the dependencies onto the ear classpath."
- WAR1 (child-module)
- WAR2 (child-module)
- WAR3 (child-module)
Need to include the dependencies as .jar files in the .ear and have them loaded in my container by the EJB ClassLoader.
But don't want the .jar files packed into both of the .war files.
Declare common dependencies in WAR1, WAR2 and WAR3 in PARENT-POM2 with provided scope.
Also declare these dependencies (without the provided scope) in the EAR project.
Add WAR1, WAR2 and WAR3 to EAR-PROJECT's dependencies as well.
Verified this setup works in a similar project. WAR1, WAR2 and WAR3 builds but their common dependencies are not included in the wars. EAR-PROJECT includes all the WARs and their dependencies in its packaging.
Need: Dependency scope that is required for compilation but not in the runtime. Same As "Way to exclude certain dependencies from being packaged into war. Eg. servlet-api-2.4.jar is required for most of the sevlet or web framework but it should not be packaged into war because api is provided by container."
Answer: Provided scope, As was mentioned by Grzegorz Slowikowski. Also verified this and war builds but does not add jars with provided scope.