Eric,
I might be wrong, but I think what John was suggesting was something
even beyond him having to setup a number of subdirectories, poms and src
dirs to overlay and have a custom version of required uportal/jasig
artifacts in order to do a custom build with Maven 2.
I think he is asking:
1. Whether the templates, skins, etc. could be seperated out from
uPortal so that he neither has to tinker with specific files in the
deployed+exploded war nor does he have to rebuild/repackage the uPortal
webapp to get the custom changes from his build.
2. If the configuration could be separated out from uPortal's webapp and
portlets so that he neither has to tinker with specific files in the
deployed+exploded war nor does he have to rebuild/repackage the uPortal
webapp to get the custom changes from his build.
The answer to both, I think, is that this could be done via a few methods:
* Various properties and config files, etc. loaded from classpath could
be loaded via Tomcat shared classloader
(tomcat)/shared/classes/(path/to/config/file)
* Webapp descriptor config could be overriden/set in
(tomcat)/config/Catalina/localhost/*.xml
* Could front with apache/etc. and use URL rewriting to convert
http(s)://(host.domain)/(uPortal, portlet, etc.)/(pattern that would
only match non-classloaded resource files hosted by uPortal, a portlet,
etc.) to point at a different path that was specific to the environment
so that images files on a test server included with a skin might be
loaded from /some/test/server/path/to/skin/resource/files
However, it is not straightforward to do this in uPortal (or Bedework
for that matter- both heavily XSLT + file-based). The way that Atlassian
handles this sort of skinning stuff (other than relying on third-party
plugins) in Confluence, etc. is via:
1. Separating local config and files away from the application (in its
"home directory" which can be away from the webapp and tomcat if you want).
2. As much as possible, putting config into the database. (However, you
need config to get to the database, and some things it just makes sense
to have locally so there is local "home directory" file area as well).
3. Make sure as much as possible that skins, etc. are packaged into
jars. Those can be uploaded to the temporary filestore in its "home
directory" (so even temporary files are self-contained) and then stored
in the database after upload to be loaded by the application.
Of course doing that in uPortal would be a significant amount of rework,
so probably not an option for anytime soon.
Thanks,
Gary
On 6/30/10 10: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
