What the board has decided about this committee or office, and the reports it filed, most recent first. Generated from the published minutes.
These categorised views are best effort. They are read from the published minutes by a program, and what it can attribute to a committee depends on how each resolution happens to be worded — so a page may be incomplete, and nothing here overrides the minutes themselves. The raw minutes are the source of truth.
Please note. The board approves the minutes of a meeting at the meeting after it, and they are published then - so the most recent meeting is not usually here. ASF Members can read the draft in the board's own repository until it is.
[raw] the published minutes, which are the record. [main index]
| Date | Action | Decided by |
|---|---|---|
| 2008-03-19 | Appointed Gary VanMatre | the board, by resolution |
| 2006-06-27 | Appointed Craig McClanahan | the board, by resolution |
| Date | Decision | Item | Outcome |
|---|---|---|---|
| 2009-05-20 | Termination of the Shale PMC | special order | approved |
| 2006-06-27 | Establish the Apache Shale Project | special order | approved |
The Shale PMC was concluded on May 20.
The Shale PMC has voted that the Shale project should be retired and moved into the attic. The vote was passed with 5 affirmative votes. This decision has been made over several months and was reported in our last board report. The activity of the community and the Shale volunteers has gradually decreased to the point that it is time to dissolve the community as the project has become stale. Shale has served as a proving ground for JSF with value added features. Some of these ideas have been adopted by the JSF specifications and others have been reinvented in similar projects. As previously reported, the MyFaces community has interest in taking ownership of the Shale test library. We are uncertain of the proper protocol for MyFaces to take ownership of the Shale test subproject.
Shale had another slow quarter. There has been very little discussion on the mailing lists and no new activity. The 1.0.5 release is pending as the final steps to release are outstanding. In the past week, the PMC has discussed if Shale should be retired to the attic. It was an unofficial vote with four affirmatives. There are several factors that would lead us to this decision. The first is the lack of time that the Shale volunteers have to contribute. Besides the declined activity of the community, many of the value added features provided by Shale are being considered in the next draft of the JSF specification. Similar concepts will be provided by the JSF runtime and supported by the MyFaces community going forward as the have already began implementing JSF 2.0. The MyFaces community has expressed that they have interest in taking ownership of the Shale Test library. This discussion has come up several times with the last having to do with the implementation of the JSF 2.0.
Shale is still working towards the 1.0.5 release. All the artifacts are published to the Maven repo and the mirrors. The only thing lacking is updating the website. Shale has added Paul Spencer as its newest committer. Paul is a MyFaces committer and has been a positive supportive of the Shale project. There has been recent talk of a 1.1.0 release. The talk has been about the Shale test library. It is unclear at this point if all the shale libraries will be release or just the shale test library. There was more discussion on the mailing list about the future of Shale. Shale test is always at the center of this debate. We have addressed these concerns and encourage volunteers to step forward and submit patches and engage in the community.
Shale is still working towards the 1.0.5 release. All the artifacts are published to the Maven repo and the mirrors. The only thing lacking is updating the website. There has not been a lot of activity on the mailing lists over the past several months. Questions are being responded to but few patches offered. Shale has two subversion branches, 1.0.x, 1.1.x. Shale's subversion trunk his positioned at 1.1.0-SNAPSHOT. This branch holds a few enhancements that are not found in the 1.0.X branch. In particular, there are some features added to the test framework that are not offered in the 1.0.5 branch. There has not been any recent release planning for the 1.1.x branch. Shale contains several subprojects. We recently voted to discontinue support for the tiles integration subproject. Apache MyFaces Tomahawk has provided an integration library that is more current providing support for JSF 1.1 and 1.2. Several of the Shale projects have been discussion points for JSF 2.0 planning. The following is a list of Shale libraries/sub projects along with recent issues or discussion points: * Application Controller - This project uses Apache Common Chain to add pluggable filter chaining. MyFaces Trinidad has a similar strategy used for installing decorators and other pluggable services. * Clay - Shale brought in an eclipse plugin to manage Clay's xml metadata. This was fast-tracked through the incubator. This plugin is still in the sandbox. JSF 2.0 will provide an alternative to JSP for view composition. The proposed solution will not have some of the features in Clay but will be part of the core JSF Runtime. * Core Library - All other shale libraries have a dependency on this library. * Dialog Manager - There was a recent reported serialization issue on the mailing list. The person reporting the issue was not able to help with the problem resolution. * Dialog Manager SCXML - This project provides an alternative base Dialog Manager implementation using Apache Commons SCXML. * Remoting - The JSF 2.0 experts group is reviewing this project. * Spring Integration - Adds Spring's IOC container into the EL resolver chain. Spring 2.0 provides the same integration with JSF. * Test Framework - There has been a lot of interest in this library. This is one of the few libraries that have not been re-invented by other projects. Many in the Myfaces community would like to move this library under their umbrella. Unfortunately, there has not been many recent patches or contributions offered. * Tiger Framework - The JSF 2.0 experts group is reviewing this project. * Validator Support - This project utilizes Commons Validator to build JSF validators and converters. The client-side validation is the most popular feature. Unfortunately, JSF doesn't make it easy to provide rich validators that are not coupled with a component library. * View Controller - This project was based on JSF 1.1 and one of the original Shale libraries. It extends the JSF lifecycle. This became less important as JSF 1.2 provided support for before and after phase listeners attached to the view and the ability to extend the JSF lifecycle. Another feature that View Controller attempted was better exception handling. This is also a topic being discussed in JSF 2.0.
See Attachment Q Jim requested that they submit a report for next month
The Shale project does not have any product distributions that contain or use cryptography. Craig McClanahan has stepped down as chair and Gary VanMatre has taken this role. Shale is moving for a 1.0.5 release lead by Greg Reddin. This release will contain all Shale libraries.
The Shale project has had another slow quarter. The libraries have seemed to stabilize with not may reported issues. There has not been a lot of new development resulting in the community to question the future of the project. There has been talk of Shale merging with MyFaces but we are not sure that would be beneficial long term. Several committers are on both projects so both projects are represented well. The lack of activity by the project members might change in the near future leading to more time to contribute to the project. However, due to the non-commercial backing of the project, we realize the Shale community should be looking for new volunteers to help grow the project. Struts, a similar project, seems to have remained strong by bringing in new volunteers. We are already seeing positive effects of bringing in new member Rahul Akolkar. He has recently joined the Shale PMC and we have benefited from the experiences that he brings from other apache communities. We realize that we are due for a new release but are struggling to gain momentum. We are targeting a new release for the next quarter.
A quiet quarter (actually only two months, since last quarter's report was late), with a few bugfixes but no major forward motion towards a release. Questions on the mailing lists are relatively few but are getting answered. No issues that require board attention need to be raised.
Progress has been made this month in preparation for a 1.0.5 release. We have resolved several bug items and incorporated the recent Jakarta to Commons namespace changes. The recently donation, shale-clay-plugin-for-eclipse has been pulled into the sandbox. We still need to consider how to best incorporate this plugin into the nightly builds since there is a dependency with the eclipse IDE. With any luck, we will be able to pull together the resources to assemble a new release within the next month.
Overview ------------- The Apache Shale TLP was created in June 2006 to further the development of the Shale Framework, a web application framework built on top of JavaServer Faces. This is our latest quarterly report. PMC and Committer Changes -------------------------------------------- We have added one new committer this quarter: * Hermod Opstvedt, who has initially focused on Shale Clay, as well as Norwegian translations for our resource bundles, tutorials, and being generally helpful across the board. Current Development Activities -------------------------------------------- The 1.0.4 release has occurred, with slightly increased uptake and a few bug reports. Slow progress has been made towards dealing with these concerns, due primarily to busyness on the part of the various committers. We anticipate that the Spring and Tiles plugins will be updated to reflect the most recent versions of their dependent frameworks in the near future. Community ----------------- The Shale developer community continues to operate harmoniously, both within the project and with other projects (such as Struts and MyFaces) where there is substantial overlap in committer base, and many of the committers are active on multiple projects simultaneously. There are no community issues to raise to the Board's attention.
Overview ------------- The Apache Shale TLP was created in June 2006 to further the development of the Shale Framework, a web application framework built on top of JavaServer Faces. This is our latest quarterly report. PMC and Committer Changes -------------------------------------------- We have added two new committers this quarter: * David Geary, who has worked on Shale code when it was part of the Struts project * Rahul Alkolar, who has made substantial contributions (particularly in the Dialog Manager area, where one implementation is based on his work in the Commons SCXML project) Current Development Activities -------------------------------------------- This quarter, we have focused on several major areas of work, in preparation for what is hoped to be a 1.0.4 release that can be voted GA quality: * Per many requests from the user community, split the functionality supported by Shale into finer grained individual modules, so users can pick and choose which combinations of functionality they prefer. * Improve the quality and organization of the web site documentation and user guide information, including migrating it to the corresponding submodules (we use Maven2's website generation technology). * Replace the original dialog manager implementation with a two tier API that addresses the major functional limitations of the original design (such as only supporting a single window or frame), plus added pluggable back end support for the state manager engine. Two implementations are provided by default -- a "basic" one that is functionally compatible with the previous support, and an advanced one that uses Commons SCXML to manage execution. * The inevitable bugfix and minor enhancements endeavors. The 1.0.4 release has been approved by the PMC, and is awaiting final release management activities before being announced. A quality vote will take place later (we follow essentially the same process that Tomcat and Struts do in this regard). Our plan is to post a separate quality vote for the Shale Tiles module (included in the release) from the rest of the code, since it relies on an unreleased snapshot of the Standalone Tiles code that is now in the process of being migrated to a TLP. In conjunction with this release, we are branching the 1.0.x development train so that important bugfixes and/or security vulnerabilities can be repaired quickly, without disrupting existing downstream users by the inclusion of new features (many of which might not have stabilized yet) if such a release were cut from the trunk. The trunk has been designated as version 1.1.0-SNAPSHOT and is currently open for new features and enhancements, as well as bugfixes. In this way, we hope to avoid the issues some other projects have had of a very long time between releases due to only doing intermixed bugfix and feature releases from the trunk. Community ----------------- At ApacheCon US, we announced the winner of a logo contest, to have a nice website logo (and a "powered by" image) that would be made available for use by developers using Shale. The winning artist has attempted to submit his ICLA via fax, but it has not yet been recorded (he's in Egypt, which might be part of the issue there). The Shale developer community continues to operate harmoniously, both within the project and with other projects (such as Struts and MyFaces) where there is substantial overlap in committer base, and many of the committers are active on multiple projects simultaneously. There are no community issues to raise to the Board's attention.
Overview ------------- The Apache Shale TLP was created in June 2006 to further the development of the Shale Framework, a web application framework built on top of JavaServer Faces. This is our latest quarterly report. PMC and Committer Changes -------------------------------------------- We have added two new committers this quarter: * David Geary, who has worked on Shale code when it was part of the Struts project * Rahul Alkolkar, who has made substantial contributions (particularly in the Dialog Manager area, where one implementation is based on his work in the Commons SCXML project) Current Development Activities -------------------------------------------- This quarter, we have focused on several major areas of work, in preparation for what is hoped to be a release that can be voted GA quality: * Per many requests from the user community, split the functionality supported by Shale into finer grained individual modules, so users can pick and choose which combinations of functionality they prefer. * Improve the quality and organization of the web site documentation and user guide information, including migrating it to the corresponding submodules (we use Maven2's website generation technology). * Replace the original dialog manager implementation with a two tier API that addresses the major functional limitations of the original design (such as only supporting a single window or frame), plus added pluggable back end support for the state manager engine. Two implementations are provided by default -- a "basic" one that is functionally compatible with the previous support, and an advanced one that uses Commons SCXML to manage execution. * The inevitable bugfix and minor enhancements endeavors. Because it is likely that some of the Shale dependencies (such as Standalone Tiles from Struts) will not be completed yet -- they are gonig through a major refactoring cycle at the moment -- we are considering posting an upcoming release where different modules might have different quality grades, so that the parts of Shale that are GA quality can stop suffering from users waiting for a "final" release before they get started in earnest. Community ----------------- At ApacheCon US, we announced the winner of a logo contest, to have a nice website logo (and a "powered by" image) that would be made available for use by developers using Shale. The winning artist has attempted to submit his ICLA via fax, but it has not yet been recorded (he's in Egypt, which might be part of the issue there). The Shale developer community continues to operate harmoniously, both within the project and with other projects (such as Struts and MyFaces) where there is substantial overlap in committer base, and many of the committers are active on multiple projects simultaneously. There are no community issues to raise to the Board's attention.
Overview ======== Per the Apache Board resolution at the June 2006 meeting, Apache Shale was created as a top level project. This is the first of the "every month for the first three months" status reports to the Board on activities within the project. All of the initial root and infrastructure requests have been completed. We are still de-tangling a few loose ends (wiki and JIRA instance shared with the Struts project), but these are not considered to be urgent. PMC and Committer Changes ========================= None. Current Development Activities ============================== As the creation of Shale as a TLP was coming to fruition, we had nearly completed a migration to a Maven2 based build environment. This work has been substantially completed, and Shale is now completely M2 based for its build infrastructure. Nightly builds are still currently hosted on my (Craig's) home desktop, but steps are underway to migrate this to a Continuum instance on Apache infrastructure. We have initiated a contest to pick an official logo for the Apache Shale project -- details are at <http://wiki.apache.org/shale/LogoContest>. The entries so far have ranged from humorous to compelling ... it will be interesting to pick a final winner. Current release activities are focused on a 1.0.3 release, which is still likely to be considered "beta" quality (due to dependence on unreleased components, plus some outstanding bugs), but which has been requested by some downstream users to avoid their need to depend on snapshots.
