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.
