Fall 2009 Day 3 - Maven Overlays in uP

Owned by Tamra Valadez
Last updated: Sept 30, 2009Version comment
2 min read

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