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 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
app.
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
<pradeepkumar....@gmail.com> 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
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
