Hi again, I have started created some tasks in JIRA to track this changes [1]. Feel free to add what is missing.
Benedikt [1] https://issues.apache.org/jira/browse/CHAIN-84 Am 01.06.2013 um 15:04 schrieb Benedikt Ritter <benerit...@gmail.com>: > 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
