On 1/28/2014 11:34 AM, Scott Klein wrote:
I was hoping that someone could either show me best practice or just
comment on the correctness of my approach.
We have multiple projects which run on our app server (tomcat).
Therefore, we want our projects to share as much as possible when it
comes to provided artifacts in order to reduce our war file size - so
everyone relies on the same version of guava for example, which is
defined in the dependency management section of our common-parent
pom.
We have configured our app servers to include a 2nd lib folder (call
it "common-lib") - this is where we want to put all of our projects
provided artifacts (after wiping the files in the folder out - hence
the separate "common-lib" folder). Tomcat is setup to include this in
its classpath.
For example, our nightly build trigger would rm -f all jar files in
the common-lib folder, then Project1 would build and push all of its
provided jars up to common-lib, followed by Project2, and on, and on.
At the end of the build you have a completely refreshed "common-lib"
folder with all of the provided jars for each project. (Obviously, if
this were the "live" common-lib this might be an issue so we have a
"staging" area we actually deploy to - then in our tomcat startup
script we replace the "live" common-lib files with those from the
"staging" area)
Obviously, if we do not keep a tight rein on dependency versions in
project poms this could turn into a nightmare -- but let's assume we
can do that.
So here is the approach I am taking: 1. I use the
maven-dependency-plugin to copy provided jars into
"${project.build.directory}\provided" - I have tied this to
<phase>package</phase>
2. I use the maven-antrun-plugin to scp all files in the
"${project.build.directory}\provided" folder up to our "common-lib"
folder on our app server - I have tied this to <phase>deploy<phase>
I am afraid that maybe our horrible past practices have blinded me
from seeing the Maven best practice, so I am looking for a reality
check. To me, this seems like something that people would need to do
all the time - but I can't seem to find anything that specifically
relates to this approach.
Side Note: As I was writing this I kept thinking "why not just deploy
our wars with everything that they need, that would be much cleaner
and more reproducible. We shouldn't care about artifact (war) file
size if this happens in the middle of the night".
Yes, this is the way to go for a variety of reasons (most of which are
better discussed on the Tomcat mailing list). Run Tomcat 7 (currently
7.0.50), use parallel deployment, the Tomcat Maven plugin, and
deployments should be seamless.
Here is what I came
up with -- we have one jar file that we build which has all of our
hibernate code in it, it also generates all of our shared connections
for all of our contexts (these are shared session factories).
I (think I) know how Hibernate works . . . So you have one JAR that
contains the information for all of your connections? Each context then
gets all of the connections?
I'm not sure I would agree with that practice. So your hibernate.cfg.xml
has configurations for all of your connections? What happens if a
particular web application doesn't need one or more of the connections?
This single artifact *must* be shared - we simply cannot allow each war
file to include its own copy - due to singleton style bootstrap of
connections.
Singletons are isolated per web application. Again, this is more of a
Tomcat question than a Maven one.
Is it best practice for a war to deploy with all of its
dependencies?
Thanks, in advance scott
I'm new to Maven, so take the following with a grain (or two) of salt.
I'm working on creating a rational build environment by doing the following:
1. Examine applications
2. Break up applications into reusable components (WAR, JAR, etc.)
a. components should be as independent as possible
b. reference coupled components as a POM dependency
c. application-specific components belong solely in that application
3. If many projects have the same structure, make an archetype
4. Manage plugins in a parent POM
This all gets shunted off to an internal Nexus for artifact management,
and an internal Jenkins for continuous build, test, and deployment.
I'm not there yet, but we've already seen gains in reproducible builds,
ease of creating new projects, and earlier detection of issues.
. . . just my two cents.
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
