maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Eggers <>
Subject Re: I want to separate the 3rd party jar in war file.
Date Fri, 18 Mar 2016 19:52:25 GMT

That is certainly another (and potentially excellent way) of looking at
this problem.

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

This has several advantages.

1. Keeps your server generic - easier upgrades
2. Keeps the JARs associated with the appropriate project
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.

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

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 .

View raw message