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
