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