Thats our goal! On 06/30/2010 12:54 PM, Patrick Berry wrote:
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] <mailto:[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
smime.p7s
Description: S/MIME Cryptographic Signature
