maven package bloated

[mudit tuli <mu...@gmail.com>]

Hi,

When I do maven package, this gives me a bloated WAR with all the
dependencies which is 19MB in size.

For some reasons I need to deploy WAR onto my VPS time and again to test.

But deploying a 19MB war is time consuming, can I try to strip off the
dependency JARs in the WAR ?

Tried packaging a skinny war and referenced the the dependency jars with
shared.loader in catalina.properties, is this the right way to do it ?

Using maven2 and tomcat6.

Not to mention, I am very new to maven.

Mudit Tuli

Re: maven package bloated

[Ron Wheeler <rw...@artifact-software.com>]

  On 28/08/2010 6:38 AM, mudit tuli wrote:
> Hi,
>
> When I do maven package, this gives me a bloated WAR with all the
> dependencies which is 19MB in size.
>
> For some reasons I need to deploy WAR onto my VPS time and again to test.
>
> But deploying a 19MB war is time consuming, can I try to strip off the
> dependency JARs in the WAR ?
>
> Tried packaging a skinny war and referenced the the dependency jars with
> shared.loader in catalina.properties, is this the right way to do it ?
>
> Using maven2 and tomcat6.
>
> Not to mention, I am very new to maven.
>
> Mudit Tuli
>
IMHO. This is the right way to do it.
We have a 60 POM project. About 10 build shared JARs that go into 
Tomcat's lib folder. A few are intermediate aggregations used to build 
larger composite POMs such as the Spring-Hibernate-MySQL-Tomcat POM 
which actually depends of the 4 POMs that define the individual components.
These are referenced by the POMs that produce the WAR file as "provided".
Benefits:
1) Skinny WARs that only contain our code and resources.
2) Control over versions so that we do not get 5 version of common 
libraries. The person defining the shared libraries has to do this once 
for each new release cycle if we are changing technologies 
(tomcat5=>tomcat6, MySQL5.0=>Mysql 5.1, new common-logging, etc.)
3) Developers do not have to worry about 3rd party libraries, there is a 
list of libraries and version already available and known to work in our 
set-up.
4) Module POMS have only 5 -7 dependencies to get everything that they 
need and it is almost always the same for each module (WAR) POM. The 
module POMs use a parent POM to get the Maven Plug-ins and repo 
definitions, so they are really minimal even for Web Services which have 
to produce both the WAR and the Client JAR.
Modules that are clients of Web Services will have the 5-7 common 
dependencies as well as the dependencies on the client JARs for the 
WebServices that it uses.
Very simple to make.
5) New versions are introduced in 1 place.
6) Deploy is fast since the WARs are tiny and once you have the shared 
libraries in your cache, you never have to download them again within 
the development of a single release of the whole application. (Our 
shared libraries are immutable within a release.)

Ron


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org