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 Re: Where should portlet-api_3.0 & portlet-tck_3.0 live?
Date Sat, 28 Jun 2014 10:30:09 GMT
Hi Ralph,

From my point of view, the overall project is to create a new version of
the portlet spec along with a corresponding new RI & TCK. So the project
has two parts - the "spec" part and the "RI / TCK" part.

The project page for the JSR 362 specification effort is hosted in the
"portletspec3" project on java.net. So far, there is no offical "JSR 362
Portlet Specification 3.0" document. Instead, there are JSR 362
"non-normative working documents" whose content is subject to change. Any
official JSR 362 specification document will be available from the JCP site
under the IBM specification license. The JSR 362 working documents are
available from the portletspec3 download area. So far, here is no single
document containing all of the proposed changes / features that I mentioned
in my other post - That's what I need to work on next.

The effort is based on version 2.0 of the portlet spec. The Apache Pluto
project hosts the v2.0 RI and also the API artifacts and documentation (I
don't know where else you could find the source) under the Apache 2.0
license.  The JSR 286 specification is available from the JCP org site
under the IBM spec license. Unfortunately, the v2.0 TCK was created under a
Sun license that contains clauses  such that it cannot be hosted on Apache.

The accepted JSR 362 proposal explicitly specifies creation of an RI & TCK
under the Apache 2.0 license. You can see that here, section 2.17:

The problem is that we cannot use the 2.0 TCK as a basis due to license
considerations. However, we can create our own new 3.0 TCK under an Apache
license. The new TCK can also include tests that exercise the 2.0
functionality as long as the new tests do not use code from the 2.0 TCK.
Since the new spec aims to achieve backward compatibility with the old
spec, I think we need to create tests that exercise the complete
functionality rather than only the new 3.0 functionality.

Since Apache hosts the Pluto RI, I don't think there is a problem with
putting the Apache-licensed 3.0 TCK into the Pluto Apache project as well.
Note that there is precedence for this:

1) The JSR 329 JSF Portlet Bridge RI & TCK are both hosted on Apache under
the MyFaces Portlet Bridge project:

2) More recently the JSR 352 group created an RI & TCK under the Apache
license, although they are both hosted on java.net:

So the way I understand it is that the official spec is owned & licensed by
the sponsoring company and is distributed through the JCP site. The
sponsoring company is responsible for development of the RI & TCK, but has
freedom in the licensing, and freedom  in exactly how the implementation is
performed. I don't believe there is any problem with implementing the RI &
TCK through an open-source effort. For Portlet Spec 3, IBM decided to
license the RI & TCK artifacts under the Apache 2.0 license, and my idea is
to host them on the Apache Pluto project and develop them together with the
Pluto community if it would be agreeable to you. The actual API & API
documentation is part of the RI (imho), so that would belong on Pluto as

But I'll double-check with the IBM project / legal  folks and get back to
you if I'm wrong.


Ralph Goers <ralph.goers@dslextreme.com> wrote on 27.06.2014 18:08:52:

> From: Ralph Goers <ralph.goers@dslextreme.com>
> To: pluto-dev@portals.apache.org,
> Date: 27.06.2014 18:09
> Subject: Re: Where should portlet-api_3.0 & portlet-tck_3.0 live?
> All ASF projects are supposed to host their source on ASF
> infrastructure. That said, there is an approved way for projects to
> use Github if they choose - although I have never done it so I’m not
> sure what is involved.
> However, what you are proposing is a bit unusual because, as far as
> I understand it, the portlet TCK and API are really owned by the JSR
> committee and not the Portals project.
> My personal opinion would be to bring them into svn (or the ASF Git
> mechanism) as soon as practical.
> Out of curiosity, where does the actual portlet spec document reside?
> Ralph
View raw message