portals-pluto-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Scott Nicklous <Scott.Nickl...@de.ibm.com>
Subject Next Steps
Date Mon, 30 Sep 2013 12:58:42 GMT

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:

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:

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:

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 ...


View raw message