Fall 2009 Day 3 - Maven Overlays in uP

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