Uploaded image for project: 'Sakai'
  1. Sakai
  2. SAK-20843

Prep portal for off-cycle releases

    XMLWordPrintable

    Details

    • Type: Task
    • Status: CLOSED
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.9.0
    • Fix Version/s: 2.9.0
    • Component/s: Portal
    • Labels:
      None

      Description

      In order to perform off-cycle releases of OSP and other major CLE capabilities, a number of CLE projects that OSP is either directly or transitively dependent upon will also need to be prepped for off-cycle releases so that SNAPSHOT dependencies can be eliminated prior to performing an OSP release. Portal is one such project.

      Both OSP (osp/xsltcharon, osp/portal) and Metaobj (tool & util -> portal-api) are dependent on the portal.  Leaving aside the issue of moving osp's portal stuff to the portal project (which has been suggested in the past), I would like to make the following changes to the portal trunk poms:

      1. Change the <groupId> to org.sakaiproject.portal.  Portal coordinates will adhere to the pattern adopted for other indies, which is reflective of broader Maven naming practices including that practiced by Apache.  <artifactId> and <version> would not be changed.  It's also easier to debug/review binaries in the repo (either local or remote) when they all can be found in

      maven2/org/sakaiproject/portal
      like: http://source.sakaiproject.org/maven2/org/sakaiproject/basiclti/

      then the current scattered arrangement of

      maven2/org/sakaiproject/
      portal-base
      portal-render
      portal
           sakai-portal-api/
           sakai-portal-impl/
           sakai-portal-render-api/
           sakai-portal-render-engine-impl/
           sakai-portal-render-impl/
           sakai-portal-render-pack/
           sakai-portal-service-impl/
           sakai-portal-service-pack/
           sakai-portal-shared-deploy/
           sakai-portal-util/

      3. Set up portal so that we can deploy binaries to the snapshot repo. Basically boilerplate additions to the base pom. Add <distributionManagement>, <repositories>, <pluginRepositories> and <reporting> declarations to base pom. Update the current Jenkins job to deploy snapshot updates.

      4. Add an assembly which provides a Tomcat-overlay zip of LB. As I noted in LA we will not substitute an assembly for a full source check out of Sakai CLE trunk but the assemblies have proven quite useful to msub deployers such as Steve Swinsburg. Plus, if we ever get the app store concept going a zip of portal binaries will prove quite useful. Again, this code, a pom file and deploy.xml is largely boilerplate. It takes about 10 minutes to write.

      5. Set up portal to use the release plugin. Involves swapping out the master pom for the purepom like other indies. We have 2.6, 2.7, 2.8, 2.9 versions of purepoms. I expect that portal will benefit from use of the release plugin (which the purepoms provide) given the advent of the new neo portal.  The release plugin, as you know, provides the ability to generate off-cycle releases in a simple, nay trivial manner.

      6. Tidy up the poms. For example, substitute standard Maven variables such as ${project.groupId} and ${project.version} where appropriate for portal's own "internal" dependencies.

      7. Portal is bundling up a copy of the portlet-api-1.0.jar (available in /shared/lib) in the following *.wars. Include portlet-api in <dependencyManagement> and adjust the <scope> to "provided" in order to eliminate bundling up the jar in the *.war files.

      sakai-portal-render-pack
      sakai-portal-service-pack
      portal.war

      8. Update portal dependency declarations in other projects: master, metaobj and OSP.

      9. Implement any necessary build profiles. As discussed in LA one change we intend to make for 2.9+ is to perform API releases independently and ahead of tool releases. In the case of portal, sometime after code freeze we would release the portal apis.  In order to do this I envision replacing the api's current <parent> with a purepom-like "sakai api" pom that will be released first so that a portal api release can actually be performed (currently, you can't do a release of an api that has a snapshot dependency on its own project base pom). Ideally, once we hit code freeze, we release the kernel apis, then all the tool apis. We should then be able to better reflect version-wise the actual steady state of most project apis.  We'll need some additional build profiles to better segregate releasing apis and then everything else.

      The lead portal comitter, Chuck Severance, supports this effort.

        Gliffy Diagrams

          Zeplin

            Attachments

              Activity

                People

                Assignee:
                arwhyte Anthony Whyte
                Reporter:
                arwhyte Anthony Whyte
                Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved:

                    Git Integration