There is also a video of the presentation too at
http://www.screencast.com/users/JonathanMarkow/folders/Jasig%202010%20Conference/media/c9b343d0-9d13-4f8b-bfb9-d5be2dba15e8
On 12/1/10 7:31 AM, "Carroll, Timothy Dale" <tcarr...@illinois.edu> wrote:
My colleague Andy (Gherna) and I did a uPortal environment management clinic at
the Spring Conference (in San Diego). I'll track down the slides and send you
a link. Basically, we made some small modifications to the maven project
layout to allow for multiple configuration .jars, then managed which one was
applied to a given environment .war using Maven overlays. The presentation was
very step-by-step.
Regards, Tim
On Nov 30, 2010, at 8:27 PM, Steve Swinsburg wrote:
Hi all,
I am wondering how people manage multiple build environments using the one
source tree of uPortal. What I mean is that we have several developers as well
as dev, test, uat and prod environments all with different details for the
hostname, tomcat path and database connection details. And we want to run this
all out of one source tree.
What we've come up with so far is to use a local properties file which each
environment has, and is kept out of SVN, which contains a number of properties
specific to that environment, like the server.home url, CAS call back URLs and
db connection details.
I've added this to Ant to it get picked up before the build.properties file (so
it loads the server.home var), and adjusted parts of the the uportal-war and
uportal-impl to use these property placeholders instead of being hardcoded,
then added the filter to the poms for each project, and *almost* everything is
working.
I've found some bundled portlets perform filtering of their own from other
properties files in the uportal-impl (ie Bookmarks portlet grabs values for its
own datasource.properties file from uportal-impl rdbms.properties) and I'm
wondering if it would make more sense to have a global properties file that can
be customised for this exact purpose. Eg see below.
Happy to submit a patch, but it would mean that how you configure uPortal would
be different, but IMO easier - ie the most common properties that you can
customise are in one file rather than multiples, and would make source control
that much easier when dealing with multiple environments - edit one file at the
root level, not multiples all over the place.
Thoughts?
regards,
Steve
Current bookmarks portlet pulls its config from uportal-impl:
<configuration>
<filters>
<filter>${basedir}/../../uportal-impl/src/main/resources/properties/rdbm.properties</filter>
</filters>
<webResources>
<resource>
<directory>${basedir}/src/main/resources</directory>
<targetPath>WEB-INF/classes</targetPath>
<filtering>true</filtering>
</resource>
</webResources>
</configuration>
Proposed change:
<configuration>
<filters>
<filter>${basedir}/../../local.properties</filter>
</filters>
<webResources>
<resource>
<directory>${basedir}/src/main/resources</directory>
<targetPath>WEB-INF/classes</targetPath>
<filtering>true</filtering>
</resource>
</webResources>
</configuration>
Likewise, the CAS settings in uportal-war would be:
<filter>
<filter-name>CAS Validate Filter</filter-name>
<filter-class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class>
<init-param>
<param-name>casServerUrlPrefix</param-name>
<param-value>${cas.host}</param-value>
</init-param>
<init-param>
<param-name>serverName</param-name>
<param-value>${uportal.host}</param-value>
</init-param>
<init-param>
<param-name>proxyCallbackUrl</param-name>
<param-value>${uportal.callback}</param-value>
</init-param>
<init-param>
<param-name>proxyReceptorUrl</param-name>
<param-value>/CasProxyServlet</param-value>
</init-param>
</filter>
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
