Simplifying Framework Dependencies

[Craig McClanahan <cr...@apache.org>]

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

Re: Simplifying Framework Dependencies

[Rahul Akolkar <ra...@gmail.com>]

On 9/12/06, Craig McClanahan <cr...@apache.org> 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

[Paul Spencer <pa...@apache.org>]

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