Building and Releasing Portlets

Added by Dustin Schultz, last edited by Mary Hunt on Nov 11, 2009  (view change)

Profile usage

Portlets wars are created in three different phases:

Within the portlet project when developing and testing

The localdev profile supports the ability to build and test just the portlet war on local a server with local filter settings active.

  • The portlet-parent pom localdev profile includes a plugin management section that defines configuration for the war, pluto and uportal plugins and provides filtering of src/main/resources. 
  • The portlet project pom localdev profile specifies which plugins are to be used.  Because not all of the "portlets" in the YaleInfo ear are actually jsr-168 portlets some do not require pluto.
  • In order for the localdev profile to work across two poms we use a property also known as localdev which is set to true or false on the command line invoking maven.
  • The artifacts built by locadev profile will have the classifier localdev.

Within the portlet project when deploying to repo:

  • The portlet may be built for deploy to Yale repo with filter tokens in place. In this case the localdev profile must not be used.  The built artifact will have the unfiltered classifier. To build and deploy the unfiltered portlet war to the Yale repository run 
    mvn clean deploy

Within the YaleInfo framework project portlet-overlay section when building the ear.

  • This pom has no profile and filtering is applied by environment specific filtering applied in root pom.  The artifacts built for the ear have the group id org.jasig.portal.portlets-overlay.  To build the portal ear artifact and deploy to repository see build deploy and release scenarios.

See Adding a New Filtered Portlet to YaleInfo to set up a new filtered portlet

Releasing a portlet to Yale repository

Portlets artifacts are released to the Yale repository with filter tokens in place and eventually get filtered values when the ear is built for a particular environment. 

SNAPSHOT

Ensure that the version you are working on is a SNAPSHOT. You will not be able to continue unless it is.

Commit All Resources

Ensure that all local changes are committed, you will not be able to continue unless they are.

Releasing a Portlet

We use the mvn release plugin only when tagging for test or production.

Recommended: Use build server script

Run portlet-release.sh

Logon to the development app server (jerry).  Switch to portal-builder account: sudo su - portal-builder.  run the portlet-release script: ./portlet-release svn-folder/portletName.

The script does 3 things:

  1. svn co of portlet name from development branch.
  2. mvn release:prepare
  3. mvn release:perform

Alternate method from developer workspace

 
Ensure that you are at the root directory of where the project exists (this is where the pom.xml is located).

Test the release:

 mvn release:prepare -DdryRun [-Darguments=-D[name]=[value]]

The "-DdryRun" tells the plug in to not fully perform the preparation. You will find this generates some temporary files in the project folder. These include:

  • pom.xml.next : what the projects pom looks like after the release
  • pom.xml.releaseBackup : what the pom looked like before
  • pom.xml.tag : the pom for the tagged version of project
  • release.properties : the information about the release of the project

Execute the Release:

Run the command below.  If any arguments need to be passed in, prefix them with -Darguments=.  Example  -Darguments=-Denv.LdapPw=[password for s_univportal]

mvn release:prepare [-Darguments=-D[name]=[value]]

You will be prompted for a number of responses

  • What is the release version for "PortletName"? (edu.yale.its.portal:PortletName) 1.0.2: :
    • Enter the version number.  The classifier  unfiltered will be appended to the artifact name)
  • What is SCM release tag or label for "PortletName"? (edu.yale.its.portal:PortletName) FeedbackPortlet-1.0.2: :
    • Accept the default by pressing ENTER
  • What is the new development version for "PortletName"? (edu.yale.its.portal:PortletName) 1.0.3-SNAPSHOT: :
    • The version increments and you can accept the default.

This does many great things for you. It changes all references in the pom.xml to reflect the version you specified, tags and commits those changes, and changes all references of the current pom.xml to the new version you specified and commits those changes

Next, run the following command. As an example below, this will perform the release for the test environment.  Note the syntax if arguments, such as filters need to be passed into the release plugin.

mvn release:perform [-Darguments=-D[name]=[value]]

Like the release:prepare, this does many great things for you as well. It compiles all code, runs all tests, generates all JavaDocs, jar's all sources, and packages the war. (It will also run site:deploy that will generate the Maven 2 site and deploy it to a location if <site> is defined) It then deploys the release to the Maven 2 repository. You can view the release at https://repository.its.yale.edu/maven2 after logging in.

Labels

 
(None)