First of all, I want to thank you all for your vote of confidence in allowing me to be Committer to the Apache Pluto project. I appreciate that, and I'll try to do a good job! :-)
With the Portlet Specification v3 taking form (see my previous post), I think we should discuss what we could safely start doing to prepare for the version 3.0 Reference Implementation effort. The Portlet Specification Version 3.0 API code & documentation is being hosted on Github, as previously mentioned. We decided to host it there, because not all EG members are committers at Apache, and we wanted to keep the hurdle low for people wanting to make contributions, and because some EG members had good experiences with Github and suggested we use it. However, the final home for that material will be the Apache Portals project, probably under the portals/portlet-spec svn branch. I hadn't worked with Git before the portlet spec work started, and I have to say that I like it very much. I did some looking around, and I see that writeable Git repositories are available for ASF projects on request, see: http://www.apache.org/dev/writable-git Which brings me to a question: would the community be interested in or willing to moving to an ASF Git repository? Personally, I would be in favor of doing so. But I have to admit that I have egoistic reasons for being in favor of a move - it would allow me to concentrate on a single SCM tool rather than switching between SVN & Git, and it would make it very easy to keep the API code in sync between the ASF and Github Portlet Specification 3.0 repositories. Another point has to do with the TCK for the portlet specification. The Portlet Specification 2.0 TCK was created under a Sun license and is not available through Apache. I would like to have the version 3.0 TCK freely available under the Apache license. However, that implies a certain amount of work, since the JSR 286 TCK will basically have to be re-implemented under the Portals project with an Apache license. We discussed this point in the JSR 362 EG, and a suggestion was made that perhaps the JSR 329 MyFaces JSF Portlet Bridge TCK (which is hosted on Apache) could be used as a starting point. See: http://myfaces.apache.org/portlet-bridge/jsr329tck.html I haven't looked at the code in detail yet, but it seems like a good avenue to explore. This would be work that could begin immediately, since we need the TCK in any case, and because I believe most would agree that it would be good to have the TCK available under the Apache license. Would there be ideas on how we should move forward here? Returning to the work-in-progress v3 API code - there would probably be work we could start with right away as well. In particular, there is a proposal for a new parameter handling API that I believe should be prototyped as soon as possible so that we can get a feeling about whether it is really an improvement with respect to the current parameter handling API, or whether it's just complicated in a different manner (the hope is naturally that it will improve clarity and make it easier to program portlets). The API code is not (yet) available on the Github site - I'm still working on it. However, the idea is described by the two documents located here: https://java.net/projects/portletspec3/downloads/directory/WorkingDocs/Parameter%20Handling%2020130812 Prototyping this idea would be another area we could begin working on soon (I'll work on getting the corresponding API code into a branch on Github that could be used as basis for this work). I would be interested in your thoughts ... regards, Scott
