maven skinnyWars does not remove ejb jars from WEB
I've stumbled across maven topic skinnyWars at http://maven.apache.org/plugins/maven-ear-plugin/examples/skinny-wars.html. As described, I can use this method to move selected dependencies from WAR module to EAR module. They will be available for all other WAR modules located in EAR.
As I have discovered the dependencies which are moved must be declared in EAR module and have to be included in META-INFlib catalog. That does not apply for EJB modules , which are located in root catalog of EAR module.
My question is how to remove duplicated EJB modules from WARs and point the reference to those located in EAR file?
The structure right now is like this:
-EAR
-ejb.jar
-META-INFlib
-shared libraries
-web.war
-WEB-INFlib
-ejb.jar
-other non-shared libraries
I've answered a similar question: How to make maven place all jars common to wars inside the same EAR to EAR root?
Unfortunately this doesn't seem to work for ejb modules. They'll get duplicated as you have already mentioned.
One thing you can additionally use is a configuration for the maven-war-plugin:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
<configuration>
<packagingExcludes>WEB-INF/lib/*.jar</packagingExcludes>
</configuration>
</plugin>
This will completly erase everything from the WAR's lib folder but it can also have its drawbacks in cases where you have to deploy the WAR additionally itself on a separate machine without the surrounding EAR.
The problem here is that it is not the same to reference an EJB from the ear module which will be used to deploy it into the server than to reference it from a client which needs the EJB classes to interface with the server.
If you include the dependency in an ear module, it will consider you are declaring an EJB module to be deployed. It will place it in the root of the EAR and declare it in application.xml.
If you include the dependency, for example, in a war module, you will get exactly the same artifact, but it will be considered as a library and placed in WEB-INF/lib.
Now, when you are generating the skinny wars, the explicit dependency to the ejb module does not match the dependency in the WAR, as Maven does not consider them to be the same thing. This results in the JAR being kept in the WAR/s which use it.
The only solution I know is to always generate a client artifact for the ejb module, even if the client artifact will be identical to the main artifact.
Now, you only use a <type>ejb</type> dependency in the EAR. For clients, you always use a <type>ejb-client</type> one.
To remove the client from the WAR/s and locate it in the lib directory of the EAR, you have to explicitly add the dependency to the ear module.
So, you will have two dependencies to the ejb module in your ear module: one to the ejb itself and one to the client. The first one will place the EJB in the root of the EAR and declare it in application.xml. The second one will place the client in the lib directory of the EAR and update WAR/s manifest/s, if necessary.
But if client and main artifacts are identical, you get it duplicated?
The short answer is yes. The long answer is yes. It does get duplicated, but only once, and not in every WAR using it. I don't think there is a clean way to avoid this and I'm not sure it makes sense conceptually. You could, of course, use packagingExcludes and customise manifests, but it makes sense to have the JAR twice.
If your client JAR is really thinner (for example, only the interfaces) having the WAR/s reference the client JAR effectively disallows them to access to EJB implementations, which is always a good idea.
You can consider the identical JAR's as a special case of the previous one and it makes conceptual sense to keep them separate.
So, my recommendation is to always generate a client artifact for the ejb and proceed as explained. There are always things you can exclude from it, be at the very least any unneeded non-class files such as package.html or ejb-jar.xml.
链接地址: http://www.djcxy.com/p/14498.html上一篇: 异步/等待的紧凑框架v3.5