uPortal developers,
Drew Wills and I cooked up a new approach to managing .jar dependencies
in uPortal that I'd like to use for the 2.6 release.
The fundamental idea is that instead of build.properties properties
naming paths to individual .jars and hard-coded logic in build.xml to
treat these .jars differently, such that to add a .jar you've gotta
update build.properties and build.xml, there are instead (optionally
configurable) magic directories. The build process discovers .jars in
these directories and treats them according to the properties of the
directory they're in. To add a .jar to the build, simply drop it into
the /lib/compile directory. To instruct the build to include a .jar at
compile time but not deploy it with uPortal because you believe your
container will provide it, stick it in /lib/provided . Etc.
This approach makes it easier to update .jars in maintaining uPortal
(less configuration to update every time a .jar changes) yet allows the
build to continue to include .jar names that include version numbers for
easy identification.
This approach also allows uPortal deployers to add locally required
.jars without touching build.properties and/or build.xml
I've committed a working version of this new approach in HEAD for
developer community review. If it ends up blowing up I'll be happy to
back it out, but I hope it can roll forward alleviate some of the pain
of keeping dependencies up to date. I'm testing support for some of the
extra build targets, such as JavaDoc generation, now.
Andrew
--
Join your friends and colleagues at JA-SIG with Altitude: June 24-27, 2007 in
Denver, CO USA.
Featuring keynotes by: Phil Windley, Matt Raible, Matt Asay
Sessions on topics including: CAS, uPortal, Portlets, Sakai, Identity
Management, and Open Source
For more information & registration visit:
http://www.ja-sig.org/conferences/07summer/index.html
---
You are currently subscribed to [email protected] as: [EMAIL
PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
