Thanks for so fast response, Jorg. I'll try to use your solutions.
Best regards, Aleksey. Jörg Schaible пишет:
Hi Aleksey, Aleksey Didik wrote at Montag, 22. Juni 2009 08:08:Hello all. I have met a situation which confuse me a little. Let's imagine we have two assembly for one maven module: full version (for example server part of application) and brief version (client part for remote call). Will use maven-assembly-plugin for build them. Full (server): <dependency> <groupId>org.foo</groupId> <artifactId>foo</artifactId> <version>1.0</version> </dependency> Short (client): <dependency> <groupId>org.foo</groupId> <artifactId>foo</artifactId> <version>1.0</version> <classifier>client</classifier> </dependency> Both artifacts have the same pom.xml which is owned by full version. If I attach dependency on client jar I will have all dependencies of full version of artifact in spite of client artifact have less count of dependencies. Result of this is unnecessary libraries in application which use client jar.This is one of the unfortunate items with Maven. An attached artifact always shares the deps of the main artifact. In case of the ejb-client this is, well, suboptimal ;-) You have two possibilities: 1/ Use a common parent POM (note, this does not have to be necessarily in the parent directory, you can handle it as any other artifact) with a depMgmnt section that contains both the EJB and the EJB client. For the client you define additionally the exclusions. Then you're able to declare a dependency to the client without repeating the exclusions, because they get "mixed in" from the parent's depMgmnt section. 2/ A different approach is to create a separate artifact for the client. Use the dependency plugin to unpack the EJB and configure the jar plugin to include only the necessary classes. In the dependency section you declare the EJB with the appropriate exclusions. Hope this helps, Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
