So this is a conversation we're having in a pull request for the hrs-portlets as well.  In smallish portlet-app projects, I feel strongly that Portlet API types are properly a part of the conversation that controllers have with the services layer.  Porlet-app projects are "defenseless" -- the only access they have to functions in the broader container is via the PortletRequest and the API types.  Therefore sharing these types between the controllers and the services layer is a key stratagem when it comes to modeling component interactions (through Java interfaces) that are non-brittle.  Furthermore, any code compiled and packaged as a part of a portlet-app war file is remarkably unlikely to execute outside a portlet lifecycle phase, so perhaps the most important reason you might want to decouple services-layer code from the Portlet API is essentially moot.

The situation with framework portlets is very different.  Framework portlets are not defenseless.  They can have as a dependency potentially any bean in the application context, and they can invoke, if needed, portal APIs directly -- both of which make their method signatures quite a bit less brittle.   Services-layer APIs, moreover, are actually good candidates for running outside the portlet or servlet lifecycle -- such as in a Quartz job.

So I support this proposed change and will take the Portlet types out of the package org.jasig.portal.tenants entirely... but I reserve the right to feel differently about services-layer method signatures in portlet-app projects.  ;-)