 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 362: Portlet Specification 3.0
The following information has been updated from the original JSR proposal:
2013.03.25: Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: IBM Name of Contact Person: Martin Scott Nicklus E-Mail Address: scott.nicklous Telephone Number: +49 7031 16 4808 Fax Number: +49 7031 16 2704 Specification Lead: Martin Scott Nicklous E-Mail Address: scott.nicklous Telephone Number: +49 7031 16 4808 Fax Number: +49 7031 16 2704 Initial Expert Group Membership:
eXo Platform Supporting this JSR:
eXo Platform Section 2: Request
2.1 Please describe the proposed Specification:This JSR requests the creation of the next version of the Portlet Specification. An update is necessary to address progress in Java EE Java technology that has taken place since JSR286 Portlet Specification 2.0 became final in 2008 and also to address new technology themes that have since come into focus. In particular we propose the following topics for the next version of the Portlet Specification:
* Align with JEE 7 Specifications 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)The Portlet Specification is an extension to the Java EE platform. 2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.As the Portlet Specification is an extension to the JEE platform, it is only relevant to that platform. 2.4 What need of the Java community will be addressed by the proposed specification?Version 2.0 of the Portlet Specification was aligned with J2EE 1.4 and the underlying Java EE technology has changed considerably since that time. Important functionality such as JSF has been extended and new technology such as CDI has been added. It is important to the Java community that Portlet Specification be updated to align with the current Java EE version. Also, client-side processing and mobile device support requirements have become more important over the last several years, leading to a need for improved and extended support for these technologies. The proposed next version of the Portlet Specification will provide portlet developers in the Java community with state-of-the-art tools to address these needs. 2.5 Why isn't this need met by existing specifications?The new version of the Portlet Specification will address technology requirements that became apparent after completion of the current version. 2.6 Please give a short description of the underlying technology or technologies:Version 3.0 of the Portlet Specification will be based on the version 2.0 that was defined in the JSR 286. Version 3.0 will be binary compatible with Version 2.0. 2.7 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.portlet. 2.8 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No. 2.9 Are there any security issues that cannot be addressed by the current security model?No. 2.10 Are there any internationalization or localization issues?No. 2.11 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?This specification would replace and extend the JSR 286 Portlet Specification 2.0 in a compatible manner. At this point, it is not anticipated that any programming interfaces defined by the current version will need to be deprecated. Depending on decisions taken by the workgroup, JSR 329 ?Portlet 2.0 Bridge for JavaServerTM Faces 1.2 Specification? will potentially need to be revised. 2.12 Please describe the anticipated schedule for the development of this specification.The schedule will be determined by the expert group. Initial target is to have a working EG by May 2013, a early draft beginning of 2014, a public draft by mid 2014 and a final version by end of 2014. 2.13 Please describe the anticipated working model for the Expert Group working on developing this specification.We anticipate a mixture of mailing list and occasional face to face or teleconference meetings. 2.14 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate: Is the schedule for the JSR publicly available, current, and updated regularly?
Can the public read and/or write to a wiki for the JSR?
Is there a publicly accessible discussion board for the JSR that you
read and respond to regularly?
Have you spoken at conferences and events about the JSR recently?
Are you using open-source processes for the development of the RI
and/or the TCK?
What are the Terms of Use required to use the collaboration tools you have prepared to use with the Expert Group, so that prospective EG members can judge whether they are compatible with the JSPA?
Does the Community tab for my JSR have links to and information about all public communication mechanisms and sites for the development of my JSR? 2.15 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.The RI will be implemented inside the open source project Pluto at Apache. RI and TCK will be stand-alone versions based on JEE 7. 2.16 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).Not applicable. 2.17 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.The Specification will be licensed under the following license:
1. A link or URL to the Specification at this location: (URL not yet assigned). The Spec Lead offers to grant a perpetual, non-exclusive, worldwide, fully paid-up, royalty free, irrevocable license under its licensable copyrights and patent claims for which there is no technically feasible way of avoiding infringement in the course of implementing the Specification, provided that you: (a) fully implement the Specification including all its required interfaces and functionality. (b) do not modify, subset, superset or otherwise extend the Specification's name space; (c) pass the TCK for this Specification; and (d) grant a reciprocal license to any of your patents necessary to implement required portions of the Specification. THE SPECIFICATION IS PROVIDED "AS IS," AND THE SPEC LEAD AND ANY OTHER AUTHORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. THE SPEC LEAD AND ANY OTHER AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE SPECIFICATION OR THE PERFORMANCE OR IMPLEMENTATION OF THE CONTENTS THEREOF. The name and trademarks of the Spec Lead or any other Authors may NOT be used in any manner, including advertising or publicity pertaining to the Specification or its contents without specific, written prior permission. Title to copyright in the Specification will at all times remain with the Authors. No other rights are granted by implication, estoppel or otherwise. Updated 2013.03.25: IBM Specification license for JSR 362 The Reference Implementation and TCK will be licensed under the Apache 2.0 license: http://www.apache.org/licenses/LICENSE-2.0.html 2.18 Please describe the communications channel you have established for the public to observe Expert Group deliberations, provide feedback, and view archives of all Expert Group communications.We have created a project on java.net for discussion and obtaining feedback. The deliberations through the mailing lists can be observed and commented on by the public. Archives or all Expert Group communications will be made available through the mechanism that has been defined. See: http://java.net/projects/portletspec3/pages/Home 2.19 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?The public can use the issue tracker located at: http://java.net/jira/browse/PORTLETSPEC3 2.20 Please provide the location of the publicly accessible document archive you have created for the Expert Group.http://java.net/projects/portletspec3/downloads Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.Portlet Specification 2.0 http://www.jcp.org/en/jsr/detail?id=286 Portlet Specification, Version 1.0 http://jcp.org/en/jsr/detail?id=168 Java Platform, Enterprise Edition 7 (Java EE 7) Specification http://www.jcp.org/en/jsr/detail?id=342 Web Services for Remote Portlets, Update to Version 2.0 (in definition phase) http://www.oasis-open.org 3.2 Explanation of how these items might be used as a starting point for the work.As an incremental upgrade to the technology, we will be building on version 2.0 of the Portlet Specification. The other mentioned materials will be taken into account to create a version 3.0 of the Portlet Specification that complies with these mentioned standards. |
