Yes, and if it is documented and deprecated over enough time, then by struts 1.4 they could be removed.I have a few concerns with this. First, it's more work to maintainthis
new optional package with build files, tests, distribution, etc.Second,
it's likely that the unused code would decay because Struts isn't usingSince we don't currently have a struts-contrib or struts-tools distribution I would agree.
it.
Once that is in place I believe that would change.
Also, it's confusing to have some actions in o.a.s.tools.actions and some in o.a.s.actions. I think *all* standard actions that are distributed with Struts should live in o.a.s.actions.
or moved into the tools jar. I agree with what you said : "I think unused methods/classes should be deprecated and removed."
If the struts core doesn't use it then it doesn't belong in the core, and should be
moved to a seperate jar. That includes any actions
So you're proposing that all of the current actions be separated from the
standard Struts distro jar?
It's one way to get a lean struts-core. How do we make a distinction between the 'actions' classes and come other
methods()/classes say under the util package about which stays and which goes. Whats the reasoning ?
I think that will be highly confusing.
No more so than going from struts 1.0 -> 1.1 where the import statements changed for BeanUtils had to change. And much less confusing than pulling out the TagUtil from RequestUtils, which requires changing imports and code, instead of just the import statements.
Choose a job you love, and you will never have to work a day of your
life.
-Confucius.
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- ----- Rob Leland (703-525-3580)
Choose a job you love, and you will never have to work a day of your life. -Confucius.
