On 12/1/2010 3:36 PM, Steve Swinsburg wrote:
Hi all,
Thanks for all of the information, it does sound like some common
approach would be useful in uPortal. I don't particularly like the idea
of replicating the uportal-impl structure for each environment, I'd
rather manage that via configuration.
Steve & Everyone,
Inspired by this very good discussion, I went back to my patch, tweaked
it a bit based on emerging feedback, and committed it for trunk &
3-2-patches. I resolved UP-2813.
The final version was pared back a bit from the patch I posted to JIRA
earlier. I wanted to distill it back down to the core of it for this
pass, and leave some of the details of which files should get this sort
of treatment by default, etc., open to the future.
So for now the only files that are filtered by default are:
- portal.properties
- rdbm.properties
But of course, adding new files to this list is a lot more simple and
transparent now then before, when you had to add all the Maven filtering
config from scratch. It's a bit more difficult, for now, to add
filtering for files outside of src/main/resources -- such as
log4j.properties files in portlets-overlay -- because you'll have to
make more significant adjustments to the affected pom(s). But at least
there's one good example included, and you can use the same Ant-Maven
setup for it (see below).
With this enhancement in place, you have some new choices for
configuring environment-specific properties. Here are the highlights,
listed from simplest to more complex...
#1: You can change nothing. If you do what you've always done*, you
will get the results you've always gotten. (*Unless you're building
directly from Maven, without Ant. In that case you'll need a _tiny_
adjustment, as I discovered with the help of Bamboo.)
#2: You can add some filter tokens to properties files
(portal.properties, rdbm.properties, or any files you add to the list of
filtered files) and add some values for those tokens to
build.properties. I made build.properties the default filters file
because I noticed that I also always needed one of those for each
environment. This way we can take care of both needs for
environment-specific stuff with the same file.
There are helpful examples, in comments, in build.properties.sample and
rdbm.properties.
#3: If you want to check in (to Subversion, etc.) the build.properties
files for each environment (pretty common), you can give them different
names like 'build.prod.properties', 'build.test.properties',
'build.local.properties', or even 'build.foo.properties' -- anything
with this pattern. You would then invoke Ant by passing the environment
name as a -Denv parameter, like so...
>ant -Denv=local clean initportal
#4: Instead of defining the values for filter tokens in
build.properties (or even build.local.properties), you can use a
separate filters file. You can specify the location of the filters file
to the build system by either (1) defining it in build.properties (or
build.local.properties) as 'filters.file'; or (2) passing the location
of the filters file as a -Dfilters.file parameter, like so...
>ant -Dfilters.file=filters/local.properties clean initportal
Have a great weekend everyone!
Cheers,
drew wills
--
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
