Noel J. Bergman wrote:
1. Because the Avalon project voted that we should migrate to
Commons CLI and not Spice CLI.
My understanding is that the Avalon Community has adopted a policy that what it considers its core functionality should rely upon standard, maintained, packages, rather than expending resources to maintain ancillary, semi-competitive, packages. Standard appears to be defined as either java.*, javax.*, or org.apache. Apparently, CLI is not considered part of the core functionality.
In some cases, I have seen arguments that a standard package isn't suitable because it has incompatible interfaces, e.g., precludes IoC/SoC. Even so, it might be acceptable for Avalon to use adapter classes rather than complete implementations where possible.
I would have vetoed any code change that led to that. I was opposed to
the deprecation of a stable working library
As Noel pointed out I have pointed out the problems I have
with it numerous times in the past.
Once more won't hurt. Let's focus on the technical. What are the technical issues that block migrating Avalon dependency from its own CLI to Commons CLI? What would have to be done with Commons CLI to eliminate the objections?
Noel:
I have reviwed all occurances of the usage of the excalibur CLI package that I was able to identity across the CVS repositories I have locally, and any available Gump references I was able to track down. The lead me to the review of the Phoenix project, Cocoon, and Turbine. In each case the CLI usage patterns were consitent with the functioanlity provided by the Jakarta Commons CLI package. I made a note to that effect on this list when the dicussions took place concerning a community policy of migration from Excalibur CLI towards Commons CLI.
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
