CSU Chico is using the maven overlay for CAS and it's (with the exception of maven hating me on days ending in 'y') been great. I would love to see uPortal move closer to this model.
On Wed, Jun 30, 2010 at 7:10 AM, Eric Dalquist <[email protected]>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
