maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <>
Subject Re: I want to separate the 3rd party jar in war file.
Date Sat, 19 Mar 2016 14:06:46 GMT Aggregation jars make 
development simpler and wars smaller Separating Environment 
from Maven Artifacts
This is an earlier approach that is geared towards an internal deployment.
The use of an installer is newer and I have not written a blog article yet.

On 18/03/2016 3:52 PM, Mark Eggers wrote:
> Ron,
> That is certainly another (and potentially excellent way) of looking at
> this problem.
This all works well.
We have been doing this for the last 3 years.
We moved out thrd-party dependencies to "provided"  more than 5 years 
ago (as you can see from the dates on the articles on our blog)
The first project had over 80 wars and jar that we built and included 
about 50 third party libraries.
Not quite as big as the project that started this discussion but big 
enough to test the concept.

The current project is smaller but is much more sophisticated in its 
deployment requirements.
It creates installers for different clients that use the identical code 
but different supporting files.

More comments interspersed below.
> 1. Use <scope>provided</scope>
> 2. Create a deploy job in something like Jenkins
>     a. Add a dependency to your product WAR
>     b. Add dependencies to the JARs marked as provided in step 1
>     c. Deploy the resulting WAR
An installer like IzPack will do this
> This has several advantages.
> 1. Keeps your server generic - easier upgrades
> 2. Keeps the JARs associated with the appropriate project
And keeps them in your Maven Repo not in your SCM
> 3. No need to worry about production, UAT, test, dev mismatches
> The only drawback I see in this arrangement is keeping the deploy job
> dependencies in sync with the <scope>provided</scope> dependencies in
> the product WAR.

> You might be able to manage this by using a parent pom with properties
> defining the scope in a DependencyManagement section. In your product
> WAR pom.xml, set the property to provided. In your deploy pom.xml, set
> the property to compile.

Use an installer like IzPack that uses your parent POM to control versions.
Use aggregation jars to reduce the number of jars required to deploy the 

> I don't know if the above would work, but if it does then keeping the
> versions of the third party JARs in sync becomes much easier (managed by
> the parent pom.xml).
> . . . . just noodling out loud
> /mde/

> On 3/18/2016 12:37 PM, Ron Wheeler wrote:
>> This looks like another case of someone trying to use a build tool as
>> an installer.
>> An installer will look after your third party jars and your
>> production configuration files and keep dev and prod well organized.
>> This makes the builds much easier (and smaller) while still providing
>> a repeatable installation that you can test and certify.
>> It also clearly separates configuration files that are managed
>> during development from those that are managed by the system
>> administrator.
>> The files that are immutable from the System Admin point of view are
>> part of the "code" and the configuration that depends on the
>> production or test environment are part of the installer project(s).
>> You can make as many installer projects as you need to support
>> different production deployments.
>> These can be maintained by deployment specialists or people who are
>> clearly acting as deployment specialists when setting up these
>> files.
>> It also allows one to have a good place for resources such as
>> READMEs, docs, licenses, etc. that are not really part of a coding
>> project but might be required when the project is put in production.
>> I use IzPack which builds installers using a maven plug-in which
>> knows about maven dependencies so you can control versioning as you
>> normally do (in the parent POM - right?) It also knows about
>> platforms so developers do not have to worry about mixing up
>> platform-dependent configuration files. The installer will install
>> the "right" set of configuration files for Linux or Windows or Mac.
>> So we write the code and test it until we are ready to deploy to
>> production. Then we build the installer with Maven and install it or
>> send it to the client for them to install it.
>> Makes for a much simpler life.
>> Ron
>> On 18/03/2016 10:01 AM, Anders Hammar wrote:
>>> As stated earlier, you need to setup your production environment
>>> similar to your dev environment. So if those 3rd party libs are
>>> part of Tomcat in your dev environment they should be so in prod as
>>> well. Or keep them in your war for dev and prod.
>>> /Anders
>>> On Fri, Mar 18, 2016 at 11:48 AM, pradeepkumar
>>> <> wrote:
>>>> Thanks Mark and Anders for quick response.
>>>> As you guys suggested i have used the <scope>provided</scope>
>>>> for some of my dependencies in pom.xml. Then i generated the war
>>>> the jars count was reduced from 165 to 130 (Still i need to add
>>>> the scope for all the pom.xml's).
>>>> But while deploying the war (only application jars ) i have to
>>>> use the 3rd party jars for successful deployment and application
>>>> up n running.Without 3rd party jars i cannot use the application/
>>>> even cannot deploy.
>>>> Currently all the 3rd party jars are maintaining in SVN (One of
>>>> the folder in svn i.e Tomcatconfiguration).
>>>> Please help me on this .

Ron Wheeler
Artifact Software Inc
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message