I want to separate the 3rd party jar in war file.
Currently we have 165 jars are using in our project. Out of this only 27
jars are belongs to Application jars then rest of jars are 3rd party jars.
In our projects our dev team is maintaining the jars in a separate folder in
one drive as shown
As Anders has said, you can use provided for those third
party JARs that you wish to exclude from the WAR file, but still need
when the application runs on your server.
There are few advantages to this and several disadvantages.
The advantages include a smaller WAR file, which means faster
Seems like a bad idea. Many would argue that you are invalidating all of your
tests run prior to creating the new binary with "extra stuff" in it.
You really should try to avoid rebuilding the application after testing it...
Robert Patrick
Sent from my iDevice
> On Mar 18, 2016, at 2:52 PM,
http://blog.artifact-software.com/tech/?p=121 Aggregation jars make
development simpler and wars smaller
http://blog.artifact-software.com/tech/?p=150 Separating Environment
from Maven Artifacts
This is an earlier approach that is geared towards an internal deployment.
The use of an installer
I want to separate the 3rd party jar in war file.
Currently we have 165 jars are using in our project. Out of this only 27
jars are belongs to Application jars then rest of jars are 3rd party jars.
In our projects our dev team is maintaining the jars in a separate folder in
one drive as shown
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,
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
If some dependencies are already provided by the runtime (e.g. the app
server) you use scope 'provided'. That will make those dependencies used
during compilation but htey are not included in the war. More details on
the different dependency scopes can be find by googling.
However, using a
Ron,
That is certainly another (and potentially excellent way) of looking at
this problem.
1. Use provided
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
Thanks Mark and Anders for quick response.
As you guys suggested i have used the provided 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
http://blog.artifact-software.com/tech/?p=121 is our experience with
this approach.
Worked very well.
We had about 80 3rd party jars.
Separating build from install is the next step.
Ron
On 18/03/2016 4:48 AM, Mark Eggers wrote:
As Anders has said, you can use provided for those third
party
11 matches
Mail list logo
