Steve,
The approach you describe -- maven filtering, environment-specific
property files -- is one we have often used at Unicon, and with pretty
good results. In fact I had worked up a proposal and a patch myself to
add this feature to uP, though only against the trunk (uP.next). The
main reason I want to bake this feature into uP is that it requires
customizations to the pom(s), and those are risky documents to fork.
https://issues.jasig.org/browse/UP-2813 (patch attached)
I really intended to complete this item by now but I got distracted by
other priorities. I still intend to complete it. Please compare notes
with me. ;-)
I believe I can minimize or actually eliminate the impact on the
configuration & build process for those who do not wish to use it. This
patch, for example, will use build.dev.properties if you use the system
and specify you're building for dev, but it will use build.properties
(same as ever) if you're not using the system.
I also intend to add a writeup of this approach to this page I've been
working on:
https://wiki.jasig.org/display/~awills/Taming+uPortal+--+Multi-Project%2C+Multi-Environment+Builds
I think one of the more significant groups who *aren't* interested in
this approach are those who, by preference or through organizational
fiat, hope to deploy the same built artifact to every environment: the
*exact same build* goes to dev, then QA, then perf test, and ultimately
to prod. This group is sometimes interested in building the portal with
the filter tokens intact, then performing the replacement as a part of
the deployment process.
drew wills
On 11/30/2010 6: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:
awi...@unicon.net
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
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
