+1 Excellent idea... What's great is that this will make it easier to discern which parts of Shale are really popular, and which aren't, which will in turn make it easier to determine what makes sense for JSF 2.0...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Kito D. Mann ([EMAIL PROTECTED]) Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Craig McClanahan > Sent: Thursday, September 28, 2006 9:33 PM > To: Shale Developers List > Subject: [PROPOSAL] Refactor Shale Deliverables > > Based on feedback from the user list, and a desire expressed > on the dev list to separate validator support into a separate > JAR as well, I hereby propose that we so some splitting up on > the current contents of shale-core.jar, before the next > release. The motivations include: > > * Allow apps to only include the pieces of Shale that they > want (such as folks who > don't need view controller support, but need to run on Servlet 2.3). > > * Enable x.y.z.patch releases of individual JARs if we need > to, at a fine grained level. > > * Narrow down shale-core.jar (possibly eventually) to just be > common shared utility > classes. > > * Minimize intra-JAR dependencies within Shale functional > jars to reduce > impacts of changes in one area on functionality in others. > > Specifically, I propose creating the following new artifacts > under the "frameworks" directory, taking existing content > from the package names specified in shale-core: > > * shale-application -- Application Controller support ( > org.apache.shale.application, > org.apache.shale.faces). > > * (shale-dialog-xxx -- This will be a separate [PROPOSAL] thread). > > * shale-validator -- Commons Validator support > (org.apache.shale.validatorand portions of > org.apache.shale.{component,renderer,taglib}). This will > also require a new tag library > for the tags; we'll probably need to leave them declared in > the original TLD for at least a > while to assist in transitions. The JSF component stuff > will need to be repackaged under > something like org.apache.shale.validator.faces for the > component, renderer, and tag classes. > > * shale-view -- View Controller support > (org.apache.shale.view, org.apache.shale.view.faces, > org.apache.shale.view.impl). > > At the same time, we should do some changes to the website pages: > > * The "features" page for things that are in a separate > artifact should become the > home page for that artifact's generated website, with > pointers in the features list > updated to point there instead of a page in the top level website. > > * Update the API Stability page to improve its usefulness: > > - Split the packages intended for application developer use > away from those > intended for people modifying the framework itself. This > will remove the need > for the "Target" column in each table. > > - Consider combining all the entries for each target into a > single table (adding a > column for which JAR contains that package), and sort the > tables by package name. > > - See where we stand with respect to aggregated javadocs > (IIRC there was an > outstanding Maven issue in this area). At a minimum, > make sure that the package > names link to the correct javadocs in the overall website. > > - Update the details to reflect the latest breakdown of > jars and packages. > > If there are no objections, I propose to start on this > tomorrow (Friday) and get it done before the weekend -- > therefore before I head down to the Bay Area to speak at the > AJAX World Conference. > > Thoughts? > > Craig > > PS: While in Prague earlier this week, I had a chance to > have dinner with Jason van Zyl of Maven fame. It sounds like > the issue we have with resolution of transitive dependencies > are going to get addressed in Maven 2.1, and he plans to have > some test builds available for us (and others) to try later this year. >
