One thing I like about this approach is that you have a single point of
control over the versions of your portlets. You can just scan the
pom.xml file and know what versions are deployed.
There are a few issue I have with this method though:
1. Build Time
Even though Maven doesn't have to recompile everything it takes a while
to scan through its build and pack/unpack the WARs. If you're just
updating a single portlet deploying the portlet separatly would be much
faster. Also, I'm always nervous about not doing a "mvn clean" before
the build because there's been a number of times where Java builds
didn't compile correctly for me until I did a clean. Maybe this is
obsolete paranoia these days, but I've been bitten enough times that I
prefer to do a clean, which means we're rebuilding everything if the
source is setup this way.
2. Non-Maven Operations
Sometimes you include other files with a project: database scripts,
command-line tools, etc. If Maven is obscuring your source code it's not
as easy to access these tools. There's no way to run special ant
commands or executables. Maybe we should handle these kinds of things
differently, but as we operate now it's nice to have the portlet source
when we need access to these kinds of things.
3. Direct Injection/Deployment
With Freemarker (and probably other view layers) you can just overwrite
your templates in the deployed location and the portlet will update
instantly. So we've created ant targets that directly inject the
.ftl,.css,.js files to the deployed location. Being able to update the
view layer without taking down the application is really convenient.
There's no way to do this with a monolithic Maven build.
Let me know your thoughts on these issues or if there are better
solutions for them.
--
Arlo White
Application Management / ITS
CalPoly, San Luis Obispo
[email protected]
On 06/30/2010 07:10 AM, Eric Dalquist wrote:
The maven overlay capabilities might be able to do what you'd like.
uPortal is already using this functionality for the bundled portlets
and CAS. If you look in the uportal-portlets-overlay/cas directory you
can see how uPortal uses the pre-build CAS war file and adds a few
custom classes, some and custom configuration without actually
recompiling CAS.
Our long term plans at UW have this approach in mind as well. I'm
hoping to have it in place in time to talk about it at the next
conference in greater detail but the high level view is:
-Setup a local Maven repository server that hosts a few local
repositories plus mirrors of all the remote repositories we depend on.
We've been using Sonatype's Nexus project for this with good success
so far.
-Setup a skeleton overlay maven project. This looks similar to just
the uportal-ear and uportal-portlets-overlay folders from the current
uPortal project.
-Create an overlay of the Jasig released version of uPortal to apply
our local modifications and configuration
-Create overlays for each additional WAR we included in our portal
Once that overlay project is all setup building uPortal your
environment is simply running 'mvn package'. None of the code is
recompiled, the WARs are simply extracted, the local configuration
placed on top and then everything is bundled back up. You then have an
EAR file you can deploy wherever you'd like.
I believe this approach is in-use at Rutgers and perhaps other places
as well.
-Eric
On 6/30/10 8:48 AM, John A Parker wrote:
I'll admit it up front... I'm old school. Take that into account
while considering the following.
We're new to uPortal 3.2.1 having been on v2.5.3. for years. Our
standard Tomcat deployment platform involves a stack starting at the
OS (in our current case being 64bit RHEL5 on VMs) and topping off at
the Tomcat container (for uPortal Tomcat v6.0.26, but for other
applications - Tomcat v5.5.28). This stack is the basis for our
"hosted" Tomcat offerings to the Cornell University community.
As far as uPortal 3.2.1: We've gotten through the process of building
our own copy of uPortal.ear, manually extracting its components (the
various .wars and .jars), and then deploying these pieces into our
Tomcat container.
Everywhere that I read of deployment strategies (for new instances or
for new/altered components) I keep finding the approach is to use
ant/maven to build and deploy. (This seems to even include the
introduction of new skins.) Unless I block maven's automatic download
of updated source it seems to me I'm faced with builds containing
more changes than I intend. It also seems like I need to do builds on
every server I plan on instantiating a new uPortal instance (dev,
test, prod, ...).
My questions/concerns are these:
Is there no way to make controlled changes to the application stack?
For example: I want to introduce an update to a Cornell skin. Is
there no way to make JUST that change to my instances?
Is there no way to build and deploy JUST the modules affected by
updates/fixes/etc. without replacing our entire application with
recompiled objects whose only difference is the date stamps put into
them by the compiler?
If I want three instances that are identical EXCEPT for a handful of
know configuration files, why would I want to do three builds? Why
not make a "gold copy" and reuse it?
As you can tell, I want rigid control over changes to my deployments.
It just feels like this build-to-deploy approach is looser than I'm
comfortable with.
Thoughts?
John
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
