Hi Bene, thanks a lot for following up the discussion, much more than appreciated :)
> * The xml module has dependencies to digister. This should be removed if > possible What I don't like is not the Digester dependency itself, but rather the fact that: * The XML config module *exposes* Digester APIs - the contract should work strictly to chain configuration APIs, it should have nothing to do with the underlying implementation; * The configuration module relies on the ConfigParser#parse() method behaviour, and returns nothing - that means that 2 different parsers could actually behave in 2 different way, switching from/to different chain textual representations is potentially broken; * Actually only the Config parse operation is available - I honestly think it would be really helpful having a component able also to dump a Chain/Catalog configuration - for that purpose I started exploring Codehaus Modello[1], which is the generator used in Apache Maven; I am not sure if it will give us the solution for that problem, but giving a try shouldn't hurt > * Base classes of the API are currently in o.a.c.c.core.impl package. This is > awkward, because the base classes really belong to the API. I came across > this issue while trying to create a test for o.a.c.c.Chains. I'm not able to > use ChainBase in that test because it is in another module (the core module). > > As a first step for me to get used to the API, I'd like to to move convenient > base classes like ChainBase and CommandBase to the API package. WDYT? > I am honestly against that proposal for the following reasons: * the `api` module just express the Chain contract and has nothing to do how chains are implemented - think about java.util.List and all implementations: of course, the JVM provides default implementations, but nothing prevents users can provide java.util.List implementations that backs data on the file system; * not necessarily users have to rely on our chain/commands implementation; having a clear separation between APIs and implementation - and ours is just _one_ implementation, not _the_ implementation - allow users compose their system including just what they need; * thinking in therms of OSGi (a topic you like, IIUC) bundles: in a running system, you can upgrade/switch chain bundle implementations without the need of updating the APIs bundles. Yes, it can be done somehow as well with monolith bundles, but having a more fine grained modules, really improve the OSGi experience. > Another point to consider is renaming o.a.c.chain2.generic. When reading a > package name like this I would expect that it has something to do with java > generics. > But instead it contains "concrete implementations of generic commands". I'd > rename this package to o.a.c.chain2.common or something like that. +1 this is something we inherited from previous chain version, feel free to fill an issue and provide the resolution. Thanks a lot for the followup, have a nice weekend! Alles Gute! :) -Simo [1] http://modello.codehaus.org/index.html http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
