Re: Simplifying Framework Dependencies
On 9/12/06, Craig McClanahan [EMAIL PROTECTED] wrote: 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. snip/ The thread will be interesting in more than one ways ... in addition to the benefits of modularization and losing some of the direct dependencies for Shale, I expect to apply some of the lessons to other projects, which have similar dependencies and are also at 1.4. Generally, the content I snipped looked OK to me :-) -Rahul
Re: Simplifying Framework Dependencies
Craig McClanahan wrote: 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 snip 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 I use commons logging in all my applications. Thus, their is *one* place when all logging configuration is done. So my preference would be the reverse, maintain a direct dependency on commons logging. Commons Logging allows the developer use of the JDK 1.4 logging facility, or any other logging facility. It is reasonable to configure a logger used during testing, i.e. log4j or JDK 1.4. (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 Is this not why BeanUtils exists? I am all for minimizing dependencies, but their is a balance between using a stable and maintained library and maintaining additional code that duplicates the functionality in that existing library. (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 Agree. (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?) Agree on splitting off the Dialog(2) module. As to smaller modules, their should be some ground rule at to what is a module and what a dependencies a module should or should not have. In general, I agree splitting shale core into smaller modules. (5) Consider splitting out the view controller hierarchy into a separate module - Same goal as (4) Agree. (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. Agree. 7) Distribute Shale in 2 basic forms. a. A la carte - Each module, i.e. shale-validator, shale-dialog,... This allows the application developer much greater control over what is included in their distribution. b. Complete package - Because this will include all modules, it is very easy for some one to start using shale. Relative to maven this is nothing more then an project, i.e. shale-complete, that include all modules. 8) Versioning - what are the rules? a. Will each module be versioned independently? b. How will Shale be versioned? Thoughts? Craig Paul Spencer
Re: Simplifying Framework Dependencies
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
Simplifying Framework Dependencies
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