Skip to main content
Last updated March 04, 2014 14:57, by Martin Scott Nicklous
=Expert Group Meeting Minutes - Archive: Minutes up to 1 October 2013 ---- 20 August 2013 Andy Bosch x Edward Burns x Ross Clewley Boleslaw Dawidowicz Kenneth Finnigan Michael Freedman x Neil Griffen Werner Keil Kito Mann x Scott Nicklous x David Taylor Julien Viet * Discussed PORTLETSPEC3-11: Portlet Parameters proposals ** Impact on working with JSR 329 JSF Portlet Bridge Spec ... need to be careful ** ViewState - name OK, or different one? *** Name is not too good ... should look for different name if we want to do it at all - clashes with Portlet view mode, and "state" is overloaded *** RenderState might be a better name *** But the idea itself doesn't seem to provide much value to developers - should revisit whether we want to do it at all. ** #4 - New common interfaces using inheritance *** Adds a bunch of new interfaces ... on the one hand simplification due to common method naming *** On the other hand, loss of distinction since we no longer would have specific methods for the render parameters *** Altogether, might bring limited value; might not be worth doing. *** Between #4 and #7, choose #7. ** #7 - PortletParameters object, separation of action, resource, and render parameters *** Makes valuable distinctions between parameters *** Among developers not a lot of pushback, but not tremendous enthusiasm, either *** Positive: helps developers through the distinctions in parameter type that are made, is backward compatible, since current interfaces still available ** Might there be synergy with JSR 350 Java State Management? *** Maybe wait if possible for JSR 350 to get a little farther along *** Unclear about scope of JSR 350 - can it help us? ... need more info *** Depends also on schedule, "target" of JSR 350 - it's beyond scope of Java EE 7, don't really want dependency on spec that isn't finished yet. *** If it seems useful, might want to go the route of being careful not to do anything that would "break" 350 without directly supporting it ** General: State handling most critical part of JSF spec, be careful making changes. ** How to continue? *** Postpone decision, since a number of people on vacation, and because a critical area is being addressed *** Take it to the community - try to get feedback from developers about whether they would like this *** Might be a good idea to prototype it so people can write porlets with it and get a feeling for how it would work * Discussed PORTLETSPEC3-30: createActionURL & createRenderURL methods that allow for copying render parameters ** Looks good, adds a couple of additional utility methods. * Discussed PORTLETSPEC3-31: Automatically copy render parameters to StateAwareResponse ** Wait on decision to get more feedback from developers, make sure performance & other concerns are addressed ** Changing name of backward compatibility runtime option from "javax.portlet.copyRenderParametersToResponse=true|false" to "javax.portlet.parameterHandlingVersion=v2.0|v3.0" seems good. * Discussed PORTLETSPEC3-32: Parameter handling on ActionURL matches parameter handling on RenderURL ** Looks good; Liferay works according to proposal already. * Comments on resolved issues #8, #15, #17, #20, #23, and #26 that are up on [ portletspec3 apidocs page] ** None; looks good. Folks would speak up; reopen issue if something appeared to be not right. * Discussed PORTLETSPEC3-27: PortletMode & WindowState during resource serving with FULL cacheability ** I answered my own question - don't want parameters, portlet mode, or window state on resource URL with cacheability = FULL * As to processing of Jira issues: ** No response is equivalent to a positive response ** Improve changes for actionable feedback by formulating the issue well * General comment on APIs: don't return null. bad practice. Try to get away from that if possible. ** If the return value should be an enum, define a special value like "NONE" to indicate emptiness rather than returning null ** If returning a collection, an empty collection is better than null. * Scott will be on vacation from 1 September to 22 September ** Call on 27 Aug will take place as planned, but after that, next call will be on 24 September ---- 13 August 2013 Andy Bosch x Edward Burns Ross Clewley Boleslaw Dawidowicz x Kenneth Finnigan x Michael Freedman x Neil Griffen Werner Keil Kito Mann x Scott Nicklous x David Taylor Julien Viet * What version of dependencies should we use? ** In maven central there is a pom that can be used to refer to all java EE 7 components *** See: [ javaee-api-7.0.pom] *** Might be convenient to use in portlet spec pom ** On the other hand, it might be better to go with a minimalistic approach ** just declare dependencies on packages we really require *** Right now, only dependency is on the servlet pom *** May need to add WebSocket, CDI dependencies when use of that technology is aded to spec *** CDI perhaps as optional dependency - need to see how it plays out *** Adding dependency on entire java EE 7 pom would bring a lot of stuff in that the portelt api is not dependent on ** General comment: we should declare the lowest version of dependency that still allows us to achieve our technology goals *** But if we want to include stuff from Java EE 7, we should go ahead and do so ** What version of servlet should we use - 3.0 or 3.1? *** 3.1 is included in Java EE 7; 3.0 is included in java EE 6 *** Need to evaluate new features in Servlet 3.0 & 3.1; determine what makes sense for portlets *** WebSocket might have a dependency on Servlet 3.1, so that might mean we would have to require Servlet 3.1 as well ** Servlet 3.0 has some nice things we might want to include *** Web fragments - support componentization / plugability *** Improved annotations - makes web.xml optional in many cases *** Servlet container initializer - May want portlet container initializer, very convenient for Jetty * Tomcat 8.0 is in Beta ** 8.0 implements the Servlet 3.1 and JavaServer Pages 2.3 * All Oracle-managed JSRs conform to maven & OSGi packaging guidelines described [ here] ** JSR 362 will conform to these rules as well * Colored changebars for apidocs ** there are CSS classes for added, changed, and removed text *** "changed_added_3_0", "changed_modified_3_0", "changed_deleted_3_0" ** Ed integrated the basic support into portletspec3 ** Works great, looks fantastic - Thanks, Ed! * Discussed clarifications for PORTLETSPEC3-8 * Discussed state handling proposal - PORTLETSPEC3-11 ** Wrote new JSR 362 Parameter handling document to accompany the PortletState proposal document, see [ Parameter Handling 2020130812] ** Two proposals for API changes under discussion - #4 & #7. Major differences: *** #4 introduces new interfaces but retains current parameter handling model *** #7 separates handling of the portlet render parameters from the action & resource parameters; introduces a "Parameters" object ** I (Scott) prefer #7, even though it makes portlets look less like servlets *** The separation of concerns makes it easier to explain how the API works; improves clarity ** Let's try to discuss and close on this if possible in the next call. There are several issues to address: *** [ PORTLETSPEC3-11]: Do we want to introduce proposal #7, proposal #4, or leave the parameter handling API unclanged? *** [ PORTLETSPEC3-30]: Add createActionURL & createRenderURL methods that allow for automatically copying parameters *** [ PORTLETSPEC3-31]: automatically copy render parameters to the StateAwareResponse during action requests and event requests *** [ PORTLETSPEC3-32]: Change the parameter handling on the action URL to match the parameter handling on the render URL ** I don't plan to update these documents this week - will work on other issues * General comment: When resolving / closing an issue, it would be helpful to add link to updated apidocs as a comment in the Jira issue ---- 6 August 2013 Andy Bosch Edward Burns x Ross Clewley Boleslaw Dawidowicz x Kenneth Finnigan x Michael Freedman x Neil Griffen x Werner Keil Kito Mann x Scott Nicklous x David Taylor x Julien Viet * Discussed contents of the copyright file (file: NOTICE linked through apidocs) ** A proposal changing the version to 3.0 and adding 2013 to the years covered will be put up with the next apidocs change ** Evaluate and see if additional changes are needed * Revisited issue PORTLETSPEC3-6 from last week. ** Deleted the sentence about backward compatibility through underscore * Discussed apidoc changes for PORTLETSPEC3-9 (apidocs on ** Look good. If no additional comments by Friday 9/8, the issue will be closed. * Parameter handling proposal for PORTLETSPEC3-8 ** Preference from Liferay: *** getRenderParameterMap() (and similar map-returning methods) should return an immutable map. *** setRenderParameters() must be used to "make it so", in other words, to actually effect a parameter change *** Would be good to provide a runtime option that would allow map handling to work "the old way", whereby "the old way" is in this case vendor-specific ** No dissent, so corresponding javadoc comment updates will be prepared and made available * General comment: If we want to make changes that are not strictly backward compatible, we should go ahead and do so ** The container can recognize the portlet version and activate the "new way of doing it" for v3.0 portlets by default ** A runtime option should be provided in each case to allow portlet developers to explicitly deactivate "the new way of doing it" and reverting to version 2.0 behavior. *** This would aid in migrating v2.0 portlets to v3.0 * Mail went out to JUGs soliciting our project for adoption ** May want to contact London Java User Group *** However, that particular JUG seems to be most interested in openJDK & Java SE *** May have better luck with a JUG in France or Germany * Discussed proposal to provide color highlighting for apidoc changes like JSF does ** Great idea!! ... but how to do it? ** Ed created mechanism used in JSF apidocs. *** Ed, may we use that mechanism as well? Would there be licensing considerations? * Revisited discussion about apidocs licensing (Werner) ** Question posed, but no response yet ... follow up next week * Revisited discussion about TCK ** JSR 286 TCK under Sun license, can't check in to Apache ** We may want to recreate the TCK from scratch on Apache ** Mike faced same problem when writing tests for JSR 329 JSF Portlet bridge *** Created a test harness driven by maven running tests based on junit and selenium *** Maven kicks off Firefox, runs tests *** Available from [ Apache MyFaces JSF Portlet Bridge Project]. *** Could potentially reuse harness & tests for JSR 362 TCK re-write *** Great timesaver - would be a real benefit to JSR 362 effort *** Need to examine in more detail - but looks like it could be a tremendous boost to our project! *** Wow! Thanks, Mike! * Presented current version of [ state handling interface proposal] ** but no time for discussion - will revisit next week ** addresses PORTLETSPEC3-11, PORTLETSPEC3-30, PORTLETSPEC3-31 *** Let's use these Jira issues for discussion of the concepts ---- 30 July 2013 Andy Bosch Edward Burns x Ross Clewley Boleslaw Dawidowicz Kenneth Finnigan Michael Freedman x Neil Griffen x Werner Keil Kito Mann x Scott Nicklous x David Taylor x Julien Viet * David Taylor joined the EG to provide his portlet expertise, represent Apache, and help coordinate the spec work with the RI work when it commences at the Apache Pluto project ** Welcome, David! * Revisited issue PORTLETSPEC3-6 from last week. ** Question about how much information from other specifications do we want to reproduce in our spec. *** Don't want to reproduce too much, as the source might change and then we would have a maintenance issue. *** Current proposal provides a condensed description about language tags. *** Ed is working on a similar issue for JSF. *** We should wait for Ed's input to make sure the Portlet spec is compatible with the JSF spec in the area of Locales. * Discussed apidoc fixes for PORTLETSPEC3-7, 10, & 25. ** Seem to be good; can be closed. * Discussed errata implementation PORTLETSPEC3-14 in spec document. ** Seems to be good; can be closed. * Updated parameter handling document ** improved discussion about parameter handling during an event request ** Good improvement compared to last version. * Discussion about the mail "Thoughts about Parameters" ** As concerns automatically copying parameters in general *** There are some concerns about potential performance & state handling impact in the container implementation. ** As concerns automatically adding parameters to render URLs and action URLs *** great improvement from the view of the portlet developers *** However, if we wanted to change the behavior of the existing createXxxURL methods, would break compatibility with 286 **** big change, not sure we want to do that *** Alternative: introduce new methods containing a "copy flag" parameter (see new Jira issue [ PORTLETSPEC3-30]) ** As concerns automatically copying render parameters to the EventResponse & ActionResponse objects *** There are some reservations *** Would be a big break as compared to the existing 286 model **** Would certainly need a runtime option switch in the deployment descriptor to ease migration of existing portlets *** How would v3 portlets work with the JSR 329 JSF portlet bridge? **** Several areas in the bridge spec could be affected **** There is uncertainty about whether another rev of the bridge spec would take place **** Companies are currently writing their own bridges; however, they are based on JSR 329, therefore 329 continues to be important **** Have to be careful in this area *** See new Jira issue [ PORTLETSPEC3-31] for more discussion ** As concerns strange parameter handling behavior on action URL *** We didn't really discuss it, but see new Jira issue [ PORTLETSPEC3-32] for some details ** Question about backward compatibility: what should our goals be? *** In any case, v1.0 & v2.0 portlets should be able to run unchanged. *** There may be cases where we want to change the default behavior for v3 portlets **** Could potentially identify portlet version based on deployment descriptor; adapt container behavior accordingly. * Informed JCP folks that we want to participate in the adopt-a-JSR program ** Submitted text which will hopefully perk the interest of 1 or more JUGs * A couple of the Jira issues require actual code changes to GenericPortlet ** How can these be tested? need to create test cases * How can we get started creating a test suite, probably on Apache? ** Due to licensing issues, JSR 286 TCK can't be hosted on Apache *** Was published under the Sun license for historical reasons ** Three alternatives: *** Rewrite the TCK under the Apache license **** More work, but clean approach **** Question about backward compatibility - portal vendors may need to run 286 TCK as well in order to prove backward compatibility *** Split the TCK - use existing 286 TCK for 286 functionality; develop new 362 TCK under Apache *** Extend the existing TCK under the Sun license **** Big disadvantage: can't integrate under Apache Pluto ** Could create TCK subproject under Apache Pluto ** How do we get committers for the Apache Pluto project? *** David will contact Apache board for guidance *** Shouldn't be a big problem for people who actively participate ** Who from the EG would want to be a committer on Pluto? *** Please note your interest, either on the mailing list or in a private mail to me (Scott) if you prefer. ** There is a read-only Pluto git mirror on Apache, see: [ Pluto GIT] (thanks Werner!) *** There are read-only git mirrors for many Apache projects, see: [ Apache git mirrors] * Discussion about JSR 362 javadoc / interface code licensing ** Currently both are under the Apache 2 license and not the spec license ** Uncertainty about whether that is acceptable ** Werner will follow up ---- 9 July 2013 Andy Bosch Edward Burns Ross Clewley x Boleslaw Dawidowicz Kenneth Finnigan Michael Freedman x Neil Griffen Werner Keil Kito Mann x Scott Nicklous x Julien Viet * Discussed how to make changes to the JSR 362 interfaces ** Don't yet have the interface source code hosted anywhere ** Would be nice to host it on github, since it would be easy for all members to make changes *** We could start a github community for this work ** Activated the website feature on the JSR 362 main page. This contains a placeholder with a link to the apidoc documentation for now. *** Intention is to allow changes to be made to the api documentation in order to close errata issues. *** Intended as interim solution until the JSR 362 interface code hosting question is solved. ** The JSR 286 RI & interface code is hosted on Apache ** Intention is to host the JSR 362 code on Apache as well *** Need to contact Apache Portals people to see if they would be interested in participating *** Determine relationship of Apache to github ---- 2 July 2013 Andy Bosch Edward Burns x Ross Clewley Boleslaw Dawidowicz x Kenneth Finnigan x Michael Freedman x Neil Griffen x Werner Keil Kito Mann x Scott Nicklous Julien Viet * JSR 286 Parameter Handling Document ** Neil provided comments on the Parameter Handling document *** Should elaborate a little bit on the Event phase *** Provide more clarification to removePublicRenderParameter() on the ActionResponse ** Would be good to add examples, use cases - be prescriptive ** Historical question: why the name "Public Render Parameters" rather than "Public State" or "Shared State" for example? *** Named that way to maintain correspondence with the servlet naming ** Might need one part of the spec more oriented toward portlet developers, and another part more toward container implementers * Question about attributes - why do we have the runtime parameter "actionScopedRequestAttributes"? ** Needed a way of preserving state across Action and Render Requests ** JSF portlet bridge implements its own notion of scope management * Neil changed the portletbox license to BSD ** Thanks! ---- 18 June 2013 Andy Bosch Edward Burns x Ross Clewley Boleslaw Dawidowicz x Kenneth Finnigan x Michael Freedman x Neil Griffen x Werner Keil Kito Mann x Scott Nicklous Julien Viet * Looked at JSR 286 Parameter Handling document - pretty good, captured reality ** Parameter handling seems complicated ** Most of the complexity is seen by container, bridge develiopers ** Less of a problem for people devlopiong portlets - they can just work with getParameters ** Would be good to provide use cases * State Management Expert Group is aware of JSR 362 ** They are trying to speed up their work ** Public draft should be out soon ** Should be monitored for potential synergies * Niel will change the portletbox license to BSD ---- 4 June 2013 Andy Bosch Edward Burns x Ross Clewley x Boleslaw Dawidowicz Kenneth Finnigan x Michael Freedman x Neil Griffen x Werner Keil Kito Mann x Scott Nicklous x Julien Viet * Next week on 11 June there will be no call, as Scott will be out for the week. * There will be a WSRP call on Thursday of this week. * The JSR 286 Parameter Test summary page had to be split since it got too large for a single wiki page. ** The [[Parameters|Parameter Handling]] page provides links to the test results summary pages * A document summarizing JSR 286 parameter handling is available [ here]. * We discussed JIRA issue PORTLETSPEC3-29 "P3PUserInfos may need clarification and could be outdated in some areas" ** Concerns the P3PUserInfos class defined in the PortletRequest interface ** This class defines an enum for P3P user information constants ** There is no documentation on the meaning of the individual enum items *** This is a deficit that perhaps should be addressed ** In addition, the P3P constants appear to be out of date - no provisions for social networking information ** The enum is hard to use - must use toString() method to use the constants in methods. Why aren't they just strings to begin with? ** Clarification on the history of P3PUserInfos *** This class exists due to the P3P stuff defined in the WSRP 2.0 specification *** The P3P web site hasn't been updated since 2007, need to determine whether P3P is still being used *** May be a good question to address at the WSRP meeting * We discussed JSR 351 Java Identity API - Can it be leveraged for portlets? ** Werner & Boleslaw are both members of the JSR 351 EG ** Work is progressing slowly, but there should be a 1st draft soon ** The aim is go in the direction of SSO, building a combined profile from multiple identity providers *** Such as Facebook or Google ** Allows user to see only what he/she is entitled to see ** Use case: Health Care *** Doctor might have rights to see one set of information *** Pharmacist might have rights to see a different set of information *** Seems to go in the direction of user authorization *** Pretty generic API, high-level *** Might not be good for lower-level authorization use ** Targeting Java SE 8, but aim is to provide identity access in a distributed environment *** But would probably be implemented as JAR that would work on top of Java EE 7 ** We need to keep an eye on this, align portlet spec with it *** If schedules match & technology is relevant for portlets * JSR 350 Java State Management is another potentially interesting JSR ** However is progressing very slowly * We spoke briefly about the map returned from getParameterMap() ** Julien: on eXo Portal, Changing map does not change parameters ** Scott, Neil, Ross: On IBM, Liferay, Oracle portals, changing the map changes the parameters ** On Pluto, changing the map does not change the parameters ** We probably can't increase restriction, so we should define map behavior such that changing the map changes the parameters thanks for your participation, <br/>Scott ---- 28 May 2013 Andy Bosch Edward Burns Ross Clewley Boleslaw Dawidowicz x Kenneth Finnigan x Michael Freedman x Neil Griffen x Werner Keil Kito Mann x Scott Nicklous Julien Viet * We spent considerable time talking about parameters and how they are supposed to work. ** Mike provided clarification on public render parameters (through mailing list) ** Scott created table describing Pluto parameter handling behavior, see [[JSR286ParametersSummary|wiki page]] ** Several errata issues address parameter behavior *** We discussed them, but didn't reach closure - need general concept description for parameter handling behavior ** In the spec, the description of parameter behavior is not consolidated in one place, but is distributed in various sections ** We need a consolidated description of parameter concepts and behavior *** Scott will write such a description and make it available to the EG for perusal. Goal: FR 7 June 2013 *** It might be good to integrate a scenario walk-through like in the servlet spec to illustrate concepts *** Once any corrections from EG members are integrated, it will serve as the basis for further work on parameters *** The description will be integrated into the spec & API documentation in the appropriate manner *** Based on the description, decisions on the corresponding errata issues will be taken ** Changes to the parameter handling API may be necessary to improve clarity ** Are parameters really URL parameters, or are they just modeled after URL parameters? *** They are modeled after URL parameters *** Portal implementations are not required to put the parameters in the URL ** In the WSRP spec, there is a good description of navigational state *** Navigational state is divided into a public and a private part *** Parties interested in portlet parameter handling should review the WSRP material ** Public render parameters are common state managed by the container *** Common to all portlets using them *** They are "owned" by the container, in contrast to private parameters which are "owned" by the portlet *** Portlets can get, set, and remove public render parameters *** Conceptually, they are common state accessed through a request, rather than being bound to the request *** PRP's allow coordination between portlets through the common state **** In contrast to events, which coordinate through an action ** Parameter handling on resource requests is special *** Resource requests are meant to serve resources for a specific portlet in a specific render state (specific set of render parameters set) *** Render parameters active when resource URL is created are added to resource URL *** Questionable whether resource requests are appropriate for page updates through Ajax - may need a new method for that **** However, that is a discussion for later - will be deferred until Ajax support is discussed * Suggestion for getting errata closed: identify specific issues for focus and closure ** Selected issues need to have a clean, clear proposal of what is to be done ** Allow 1 weekly meeting for discussion with final decision made in the following meeting thanks for your participation, <br/>Scott ---- 21 May 2013 Andy Bosch Edward Burns x Ross Clewley Boleslaw Dawidowicz Kenneth Finnigan x Michael Freedman x Neil Griffen x Werner Keil Kito Mann x Scott Nicklous x Julien Viet * Scott still needs to follow up on spec & javadoc updates * There was some discussion on parameters ** Lack of clarity on how pluto & other implementations work ** A good task would be creation of a table showing pluto parameter handling behavior *** Scott will look into this, comeback next meeting ** Neil provided portletbox on GitHub containing test portlets for various aspects of parameter handling behavior *** Very nice way to share code, collaborate on code development ---- 14 May 2013 Andy Bosch Edward Burns x Ross Clewley x Boleslaw Dawidowicz x Kenneth Finnigan Michael Freedman x Neil Griffen Werner Keil Kito Mann x Scott Nicklous x Julien Viet * Neil provided information that the API documentation for JSF is under the spec license rather than the RI license. ** Scott will follow up with the legal folks to see if this can be arranged for JSR 362 * We went through all of the Jira issues that were filed under the component "JSR 286 Portlet Specification Errata" * The following issues were accepted for implementation: ** (Spec update) [PORTLETSPEC3-1] Errata: Clarification for javax.portlet.renderHeaders Container Runtime Setting ** (Javadoc update) [PORTLETSPEC3-3] Errata: Clarification in Javadoc for CacheControl.getExpirationTime() ** (Javadoc update) [PORTLETSPEC3-4] Errata: Clarification for PortletRequest.getPortletSession() ** (Javadoc update) [PORTLETSPEC3-5] Errata: Clarification about Private Render Parameters ** (Spec update) [PORTLETSPEC3-6] Errata: Clarification for section "PLT.25.8.2 Locales supported by the Portlet" ** (Spec & Javadoc update) [PORTLETSPEC3-7] Errata: Clarify Inconsistency about Removing Shared Render Parameters ** (Spec update) [PORTLETSPEC3-12] Errata: Clarify use of Portlet 1.0 Tag Library in v2.0 Portlets ** (Code update - GenericPortlet) [PORTLETSPEC3-15] Issue in GenericPortlet Annotation Processing ** (Code update - RenderResponse)[PORTLETSPEC3-17] Errata: Correction in setNextPossiblePortletModes ** (Spec & Javadoc update)[PORTLETSPEC3-19] Errata: Clarify when CacheControl parameters can be set *** Scott will update spec *** Neil will create proposal for related javadoc clarifications (see Neil's comment in issue) ** (Javadoc update) [PORTLETSPEC3-20] Errata: Clarification in Javadoc for an illegal scope use in PortletSession methods ** (Code update - GenericPortlet) [PORTLETSPEC3-23] Errata: Issue in GenericPortlet Exception Handling for Annotations * The following issues were discussed but need follow-up: ** [PORTLETSPEC3-8] Errata: Clarify inconsistencies regarding getting and setting parameters *** The aspect about removing parameters needs to be split out and clarified. A separate issue will be created and assigned to Neil. *** The rest will be updated in the comment section ** [PORTLETSPEC3-9] Errata: Clarification needed for method MimeResponse.createRenderURL *** Need to define use cases for propagating or not propagating the URL parameters *** Follow-up once the additional info has been collected ** [PORTLETSPEC3-10] Errata: Clarify setting parameters on Resource URLs *** Collect information on how current portals behave in this area and follow up ** [PORTLETSPEC3-14] Errata: Clarification about the Portlet Title *** Scott will follow up with proposal for text change in spec ** [PORTLETSPEC3-24] GenericPortlet.doHeaders(RenderRequest, RenderResponse) should throw javax.portlet.PortletException *** Missed this one when going through the list ... sorry! * During the discussion, Neil noted that he had created test portlets for certain areas to determine how the portal implementation handles these cases. He will create additional portlets and make all of his test portlets available to the group so that we can all easily determine how our implementations behave. * Scott will take care of the spec updates, and will try to have the changes implemented in draft form by the next meeting. * We talked about how to get the Javadoc and code changes implemented. ** Nobody from the EG is committer for the Apache Pluto project ** One idea would be to recruit a person who was active in Pluto into the EG - Julien will reach out to a potential candidate * The issues filed under component "Ideas for JSR 362 Extensions" will be discussed at a later date ---- 7 May 2013 Andy Bosch Edward Burns x Ross Clewley Boleslaw Dawidowicz x Kenneth Finnigan Michael Freedman Neil Griffen Werner Keil x Kito Mann x Scott Nicklous x Julien Viet * Ed Burns has joined the JSR 362 EG to represent JSF interests. Welcome, Ed! * We want to review the errata that were entered into the Issue tracker ** Everybody should try to review the issues in Jira by Friday 10 May. *** If you can't make that date, send me a mail and let me know, or post on the mailing list *** If you have additional issues, please try to enter them into the Issue tracker by Friday 10 May. ** If you see need for discussion, make a comment in Jira. ** All issues not marked for discussion will be considered to be accepted ** All issues marked for discussion will be discussed in the next meeting on 14 May. * We had a short discussion on potential topics to discuss after the errata have been taken care of ** Pros and cons of starting out with either a big, important issue or a small, easy issue ** One idea might be to review the servlet spec and realign the corresponding portlet APIs *** Since our goal is to align with the Java EE 7 specs, the target servlet version would be 3.1 *** Julien has some ideas about what could be done in this area ** JSF alignment or optimization would be very interesting *** However, this might be a larger topic that could potentially impact a number of areas, depending on how we want to handle it thanks for your participation, Scott ---- 30 April 2013 Andy Bosch x Ross Clewley Boleslaw Dawidowicz x Kenneth Finnigan x Michael Freedman x Neil Griffen Werner Keil Kito Mann x Scott Nicklous x Julien Viet * Neil - action item from last time, javadoc and method signatures for JSF licensed as open source, need to determine as to whether that would be part of the spec. ** Neil has sent mails to obtain information, will report when information is available * Scott is working on the errata list, hasn't made the hoped-for progress so far, but hopes to have a list available for discussion by the next meeting. ** apparently, not all can create JIRA issues ... Scott will report problem and obtain a solution hopefully quickly. * Scott tried to use the MyFaces JSF Portlet Bridge 3.0.0 alpha implementation with WebSphere, but ran into problems. ** Mike kindly offered assistance ** Neil promised to send a link around through the mailing list on how to use Mojarra 2.1 with WebSphere thanks for your participation, Scott ---- 23 April 2013 '''Attendees:''' x Andy Bosch x Ross Clewley x Boleslaw Dawidowicz x Kenneth Finnigan x Michael Freedman x Neil Griffen x Werner Keil Kito Mann x Scott Nicklous x Julien Viet * Welcome to the Expert Group! * We will start using the tools for communication, beginning now, more or less. ** I'm still learning how to administer the site, so please be patient. ** Expert Group: Please let me know your java-net userIDs, so I can give you appropriate rights to update things if I need to, once I figure out how to do so. **The EG calls will be private, but the minutes will be published on the public site. ** However, I would be open to allowing guests if needed to provide special expertise. * A working document based on the JSR 286 Specification is available on the download page. * We agreed I believe to start discussion with an errata / clarifications list for JSR 286. ** I unfortunately didn't get far enough along to post my list of errata ** How shall we go about collecting items? Shall we use the issue tracker, or put things on the project wiki? *** We will use the issue tracker. *** We will collect the individual items through the issue tracker and then I will put a consolidated list on the Wiki for discussion before they are incorporated into the document. *** Scott will look at the issue tracker and see if we need a naming convention or some such for the errata list. * Question about licensing for the JSR 362 Javadoc ** after discussion with IBM legal, it looks like the Javadoc will fall under the RI license (Apache 2 license), since it is derived from the Reference Implementation *** Other JSRs in the past used to fall under to spec license ... need to follow up. *** With JSR 329, the message signatures were in the HTML document, so they were under the spec license *** The Faces spec calls under the Java EE umbrella, so is a bit different. *** How would someone go about creating their own Impl based on the spec only? *** Scott will follow up. * Question about putting the TCK up under the Apache Pluto project ** We need to integrate the JSR 286 TCK to maintain & prove backward compatibility with JSR 286 ** The JSR 286 TCK is licensed under a Sun license ** Therefore the JSR 362 TCK will need to be licensed under the same license, or would have to include the JSR 286 TCK as a plug-in somehow ** Possible solutions? *** Yes, we could require folks to run obtain and run the the JSR 286 TCK in order to verify compatibility and then run the JSR 362 TCK on top of that. That way, we could put the JSR 362 TCK up on Pluto. thanks for your participation, Scott
Please Confirm