Mailing-List: contact pluto-dev-help@portals.apache.org; run by ezmlm
Precedence: bulk
Reply-To: pluto-dev@portals.apache.org
Reply-To: pluto-dev@portals.apache.org
Received-SPF: pass (athena.apache.org: domain of scott.nicklous@de.ibm.com
 designates 195.75.94.108 as permitted sender)
Subject: Next steps
To: pluto-dev@portals.apache.org
Message-ID: 
 <OFC0092FE9.BFC1BE8A-ONC1257CEC.0035702C-C1257CEC.004130C1@de.ibm.com>
From: Martin Scott Nicklous <Scott.Nicklous@de.ibm.com>
Date: Tue, 3 Jun 2014 13:52:03 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII


Soo ... we're (finally) at the point with Portlet Specification 3.0 that we
can begin working on the Pluto Reference Implementation. This time, there
will not be a "big bang" code drop that integrates the new functionality as
there was with v2.0. Instead, we'll develop the new RI & TCK together :-) .

I see three major pieces of work that we can begin with:

1) Re-implementation of the  JSR 286 TCK under the Apache license.

The jsr 286 & 168 TCKs were implemented under a Sun license and for that
reason, they cannot be hosted on Apache. For JSR 362, we would like to have
a TCK implemented under the Apache 2.0 license and made available through
the Apache Pluto project. This implies a certain amount of work, since we
can't use the earlier RI as a starting point.

JSR 362 will provide backward compatibility to the JSR 286 spec, and we
need to prove it by means of the TCK. This means that we more or less must
re-implement the JSR 286 TCK as a basis, and from there we can add
additional tests for new JSR 362 functionality as needed.

A related specification, JSR 329 "Portlet 2.0 Bridge for JavaServerTM Faces
1.2 Specification ", is hosted under the Apache myFaces project and
contains a TCK that is licensed under Apache 2.0. We may be able to reuse
portions of that code for our TCK.

2) Implement the new portlet APIs defined in the Portlet State proposal. It
isn't yet 100% clear that it will make it into the spec, but the EG wants
to prototype it so that we can see if it makes it easier to develop
portlets. The current JSR 362 API Working Document contains the updated API
code for the proposal. See:

http://msnicklous.github.io/portletspec3/apidocs/index.html

3) Integrate the Portlet Hub mockup into the Pluto theme and make the
appropriate changes in the mockup & Pluto code to make JSR 362 Stateful
Ajax Support come to life! The link provided in item 2 contains the
JavaScript mockup and JavaScript API documentation, and the "PortletHub"
branch of the portletspec3 github  project contains the mockup along with
JavaScript test cases written for the Jasmine JavaScript test tool. The
maven build setup available from the "PortletHub" branch contains a pretty
complete setup for JavaScript handling - it produces jsdoc documentation,
runs the Jasmine test cases, and uses a JavaScript compressor  (the YUI
compressor) to shrink the portlet hub mockup from 68k down to 7k, which is
pretty good shrinkage, I think. Naturally, the source before shrinkage
contains all of the jsdoc documentation, so you have to take that into
account.

In addition to these three items, we need some cool demo portlets to show
off the new functionality represented by items 2 & 3.

Now we have to figure out how to organize the work. We could do it the
"fun" way, which I imagine for many folks would mean executing the items in
the order 3-2-1. Or we could do it the "prudent" way, which would mean
re-implementing the JSR 286 TCK first thing, so that we can run the tests
to make sure we don't break anything as we implement points 2 and 3 and
further items.

Otoh .... I think the topics are fairly orthogonal, so that if there were
enough interested parties, we could split up the items among ourselves,
work on them in parallel in separate branches, and integrate at the end.

 .... thoughts?

For my part, I'd like to start working on the TCK first, because I'd like
to have the tests to run as we implement further items.

regards,
Scott