Here is the excerpt on the proposal that I wrote earlier on using the existing Registry Information Model (RIM) and Maven repository for the Portlet Repository Protocol (PRP) definition. Note : The following content is just a proposal for PRP that I sent earlier on the PRP mailing list by no means a agreed interface.

The Portlet Repository Protocol (PRP) is a initiative that tries to define a set of agreed interfaces and meta-data for implementing portlet repositories. The intent of PRP is facilitate distribution of portlets binaries over the wire, where an administrator or a user can download and install portlets by a look-up or search on a PRP based repository.  Its a cross-vendor initiative and more vendors interested in the definition. We encourage you to join the alias and contribute to this definition.

The proposal is based on using the existing standard's and infrastructure rather than building everything from scratch. The proposal uses/builds-upon on the the following infrastructure.

1. Maven repository infrastructure and its dependency resolution mechanism for download and install &
2. The standard webservices (WS) registry infrastructure for meta-data definition/search/publish functionalities.

Here are more details/steps of the proposal on PRP in using the existing WS & maven infrastructure.

A. Steps for publishing a portlet:

1. The portlet-binary /war would be published to a maven repository.
2. A meta data about the above portlet would be published to the standard WS registry.
   

B. Download & install:

1. If the client knows the artifact id i.e not interested in searching the repository.
2. It can use the standard maven way of downloading the artifact by specifying it in the pom.
3. A mvn plugin can be provided to install the above artifact on to the portal server ( Note:  Each vendor can provide their own maven plugin for installation, hence it also solve the problem of where each vendor have their own way of deploying a portlet)
   

C. Search, Download and Install :

1. A WS client may search the registry based on various query parameters and search for a portlet on the WS registry (this would be a maven plugin too)
2. It obtains the maven repository and the artifact id as the response of the query.
3. The client uses the search results to download the maven artifact from the maven repository.
4. As indicated above the maven plugin to deploy the portlet could be used

D. Supporting preview for a portlet :

1. While publishing a portlet the administrator could publish the WebService for Remote Portlets(WSRP) artifacts associated with the portlet  (WSRP artifact meaning WSRP Registry Information Model-RIM defined by OASIS). We can even think even about PRP as an add-on to the WSRP RIM or vice versa.
2. The WSRP artifact points to the WSRP Producer which offers this portlet
3. The client which is interested in a preview of the portlet could use the standard WSRP interfaces to get the content.

Note : The above need not be limited to preview mode as WSRP supports all modes. So rather than a preview we could call it as "test drive" a portlet.

Note : The above could be a extension and not mandated in the RIM. So this would be a optional meta-data.

E. Cross referencing.

1. It MAY be possible to cross reference registries that would allow us to import all the data from other vendor hence offering more portlet (Need to check on cross referencing feature in registry)
2. Worst case importing the meta-data from other registries and importing to our registry would work.
   

Advantages :

1. We'd using the standard WS infrastructure (defining metadata, searching and publishing to the registry)
2. We can take advantage of the maven dependency resolution mechanism ie. a portlet may depended on some software that needs to be in the server classpath etc which can be resolved by the POM.
3. No need to invent any on the wire protocol rather use maven + WS registry infrastructure.
4. We can take advantage of the mvn distribution (i.e. we need not write new client or cli etc)
5. Everything defined above are based on standards so any one can implement their own solution . All we have to agree upon is the meta data.
   

Items to be done:

1. Define a meta data for the PRP
2. Write maven plugins for
1. publish
2. search
3. install of the portlet

If you have any comments or want to see the responses for the above proposal. Pls join the mailing list for PRP.