>From: "Craig McClanahan" <[EMAIL PROTECTED]> > > 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 >
+1 > (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 > + 1 You've already checked this one off the list right? > (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 > +1 The validator has hooks into the core view handler. It is registering a RenderKitFactory wrapper. We could do this from the faces-config but would risk some other library doing the same. > (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 > This might be a good plan if we take a try at JSR 299. Ryan Wynn might like that option too :-) > - 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). > We could pull the this out of clay but I would also be interested in other ideas. The file watch dog in clay relies on a commons chain filter command. I could pull it out and we could then make a decision as to if it will work in the other scenarios. > - This is probably the hardest nut to crack in the dependencies area. > > Thoughts? > > Craig Gary
