Hi Steve,
As Drew mentioned, Unicon's been using a maven filtering-based approach for
several years now based on work we originally did for an internal demo
instance. I presented on this at the 2009 Jasig conference, and there are some
slides left over from that here:
https://wiki.jasig.org/download/attachments/22940141/uPortal_Build.pdf?version=1&modificationDate=1236555418744.
From your description, it sounds like our approaches are very similar.
Basically the strategy we've followed consists of using a single maven filter
file that's used for both the portal and all bundled portlets. I'd strongly
suggest that whatever strategy we adopt be capable of configuring both the
portal and bundled portlets, since it's so common for portlets to share
information about the CAS server, database connection parameters, log
directory, etc. I'd be more than happy to share customizations we've made to
accomplish this.
I've included a sample filter file below. We generally have one folder named
"filter" at the root of the portal, and place one file for each environment in
that folder. Filter files toggling is controlled by a environment variable
that can be set on the command line (like ant deploy-ear
-Denvironment.name=jen). This will all become a lot simpler once uPortal is
built only by maven, but for the time being, we've added hooks to pass the
environment name through during ant builds.
We also did custom work to allow configuration of the database dependency via
ant or maven parameters. This approach is still a bit awkward because of
uPortal's ant build strategy, but it does work. While most deployments
probably use the same database driver, having the driver be easily configurable
can be helpful for local developer instances (I don't really want to install
Oracle on my laptop).
The one downside of using maven filter files is that this approach can become
confusing for users who aren't completely familiar with how maven works and
developers with slower laptops tend to be frustrated by having to run a full
"ant clean deploy-ear" to deploy a simple database connection change. It can
also confuse sysadmins who don't use maven much, since if you don't explicitly
run a clean, maven of course doesn't know that the filter file in the parent
directory has changed and doesn't bother to update the portlet overlays.
I'd personally love this or some similar solution to become part of the uPortal
source. It'd certainly be much easier than maintaining all the modifications
ourselves, and it sounds like this use case is becoming increasingly common. I
think the patch Drew's already contributed looks like it contains most of our
changes, minus the ones designed to allow database dependency switching. Since
we can at least control the dependency for the portal and all portlets from the
main pom.xml right now, I'm inclined to think we should just leave that part
out for now. I would be all for applying Drew's current patch to the uPortal
trunk and building on that, if it seems to meet other people's needs as well as
ours.
Sample shared filter file for my personal development environment (with
passwords and such commented out, of course):
environment.build.logging.dir=/usr/local/tomcat_instances/up32-showcase/logs
# Database configuration properties
environment.build.hibernate.connection.driver_class=org.postgresql.Driver
environment.build.hibernate.connection.url=jdbc:postgresql://localhost/up3
environment.build.hibernate.connection.username=uportal
environment.build.hibernate.connection.password=<password>
environment.build.hibernate.connection.validationQuery=select 1
environment.build.hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect
# uPortal server configuration properties
environment.build.uportal.server=localhost:8443
environment.build.uportal.protocol=https
environment.build.uportal.context=/uPortal
# CAS server configuration properties
environment.build.cas.server=localhost:8443
environment.build.cas.protocol=https
# LDAP Configuration
environment.build.ldap.url=ldap://<ldapserver>:389
environment.build.ldap.username=<ldapusername>
environment.build.ldap.password=<ldappassword>
environment.build.ldap.userbase=<ldapuserbase>
environment.build.ldap.uidattribute=sAMAccountName
# Facebook portlet
environment.build.facebook.api_key=<apiKey>
On Nov 30, 2010, at 5: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 [email protected] as:
> [email protected]
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
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
