As Shale moves towards maturity, one of the usability issues on my mind is the set of dependencies that we currently mandate in shale-core and friends. I would like us to take a look at whether we can eliminate some or all of these dependencies, and therefore slim down the amount of code that must be included in a web application's WEB-INF/lib directory simply to use Shale features. A related aspect of this might be to divide shale-core into separate JARs for the discrete pieces of functionality one might wish to employ ... but the same issues will apply in those cases as well. One particular issue that will fall out of this discussion, of course, is how the framework should log its own messages ... my recommendation below might well engender enough discussion to need its own mail thread :-).
Before getting into details, an important philosophical issue is that fact that we (today) tend to inherit a bunch of transitive dependencies from whichever JSF implementation you want to use (MyFaces or the JSF RI), and any attempt to eliminate direct dependencies on the same JARs seems useless. We have to remember, however, that JSF 1.2 is part of Java EE 5 and the typical usage pattern on an EE 5 server will be to *not* include a JSF implementation in the webapp. In a similar vein, it's pretty easy to configure something like Tomcat (or JBoss, or Jetty, or whatever) to include a JSF implementation in the parent class loader ... so we should be sensitive to developers who want to leverage such shared resources and minimize the payload that must be loaded into each individual WAR. At the moment, shale-core depends on the following external resources (I'm leaving specific version numbers out of the equation because they aren't relevant to the overall discussion): * Commons BeanUtils - Transitive dependency from Commons Digester - Cleanup code on application shutdown (can be modified to use reflection to do this optionally) - Also used directly in other modules * Commons Chain - Parsing chain-config.xml files for the application level filter * Commons Digester - Transitive dependency from JSF implementations - Used to parse configuration files in modules like shale-clay and for dialogs * Commons Logging - Transitive dependency from JSF implementations - Directly used all over the place * Commons Validator - Required if you use the validation tags (maybe separate into separate module?) * Jakarta ORO - Transitive dependency from Commons Validator I would propose the following initial steps to simplify our dependencies, and will create JIRA tasks for them after implied or explicit consensus is achieved: (1) Switch to using JDK 1.4 logging for all framework related logging - We require JDK 1.4 or later anyway, so this is always available - Shale's logging needs (on its own behalf) are very simple and require no special functionality - Using this does *not* prevent an application from using something else (such as Log4J) for its own logging purposes (2) Eliminate direct BeanUtils dependencies - Replace by use of utility methods for property copying that are already available in shale-core - Need to implement standalone replacement in shale-test to avoid introducing new dependency - Do the BeanUtils cleanup functionality optionally, and via reflection, instead of directly (3) Split the validator related stuff into a new module, so you don't need to inherit its dependencies if you only need shale-core - This module will inherit most of its dependencies transitively (4) When/if the updated dialog2 stuff is migrated out of the sandbox, keep as separate modules - Goal is to minimize size of shale-core (maybe even eliminate if everything gets factored into smaller modules?) (5) Consider splitting out the view controller hierarchy into a separate module - Same goal as (4) (6) Evaluate alternatives for configuration file parsing, in conjunction with potentially generic support for reloadable config files (there's machinery for this already in shale-clay). - This is probably the hardest nut to crack in the dependencies area. Thoughts? Craig
