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
