Hi Simo, Am 01.06.2013 um 14:28 schrieb Simone Tripodi <simonetrip...@apache.org>:
> 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 Agreed, sounds exciting! > >> * 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; This depends on what you define as the API. For me, convenience base classes are also part of the API. Users are free to use them, but can also choose not to. Your example actually confirms this :-) Think of java.util.AbstractList. It is an abstract convenience base class, that is shipped as part of the Collections Framework (and not in some impl package). > > * 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. Yes this is a topic I'm very interested in :-) But I don't see why this change would affect OSGi-ity of chain. I don't think it is absolutely necessary to move the base classes and since you have objections against this, we should just post pone this discussion until we have the API in an almost finished shape. > >> 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. I have created CHAIN-83 [1] for this purpose. > > Thanks a lot for the followup, have a nice weekend! > Alles Gute! :) > -Simo Thanks, you as well :-) Benedikt [1] https://issues.apache.org/jira/browse/CHAIN-83 > > [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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
