Fall 2009 Day 3 - Maven Overlays in uP
MAVEN OVERLAYS
Susan - Yale
Goals - move an artifact from one environment to another
Needed to be confident of what we were moving
Deployers would not be the developers
Previously manually moving files
Jen - back on Yale turf
Decided to go with a giant package ear, which would include all of our portlets bundled and that is what would be deployed. In order to get there:
externalizede connections to JNDI
portlet parameters which had to be injected depending on ENV - packaged portlets with filter tokens
Plugin in the uPortal sandbox
Developers:
Released portlets with filter tokens
Portlets pulled together with tokens
Giant ear ready to go
Goals:
Deploy war and deploy ear - runs maven underneath
One filter file for the portal and all portlets
so if you change something in the filter file - so next time run applied to portal and portlets
Building for a particular environment
Deploys portal and portlets all at once
Utilizes classifiers heavily for ENV - picks up filter for that ENV
Production:
Admin runs and no source code on production server.
Helped make developers lives easier
Added to pom file - so you can run maven deploy war from developer environment
Q&A:
handled differently by creating an artifact for every environment
One advantage to using maven overlays, is that if you are using code from other schools and the version it was developed for is older it could be an issue
Need to utilize Pluto container sanctioned by the uPortal version you are running
You can overlay on a per file basis
You can add new dependencies - and make the adjust in the maven overlay
Really important to perform diffs during and upgrade to pick up changes which need to be implemented in the overlays.
UPortal doesn't have a good design for turning off all caching - so you could create an overlay to turn off all the caching
Option: Specify CSS directory for your main uPortal - shared instance, point Universality.xsl to somewhere else that designers have access to.
DB unload - default data to xml, will be fine.
Approaches are driven by local policies and who has access to what information, i.e. don't want the DEV build to have passwords available, that should only be in PRD
Products - nexus (UW: self service code hosting environment)
Encouraged to have a local repository