Re: [all commons] Proposal: CommonsCommons package
From: Arron Bates [EMAIL PROTECTED] The Commons project itself is now housing separate sub projects which have seemingly their own boundaries Every little part is acting like its own jakarta project. Hell, the votes are even working that way... This guy's been doing some great work with HttpClient... we know the story. Could be that some of the projects should be kicked out to live on their own (but I'll stay out of that particular packet of politics) This is an issue for the whole of jakarta IMHO. The main jakarta page now has 23 top level projects listed. Which is probably more than a new user really needs to deal with. Plus there are 'hidden' projects of great value in Commons, Avalon, Turbine (and probably others). Plus there is the XML project to think about. I would also suggest that some of the 23 are distinctly more widely used than others ( no names ). There is a distinct danger of overload IMHO. Stephen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [all commons] Proposal: CommonsCommons package
I know what you mean, but I'm not sure that commoncommons is the answer. IMHO, code in the commons falls into three categories - - Widely used, and often as a group (BeanUtils, Betwixt, Collections, Digester, Logging) - Individual stable, less interrelationships (CLI, Cactus, DBCP, HTTP Client, ...(other commons)) - Developmental code (Sandbox) I know I might be a little controversial to separate out those 5, but they do often seem to be used as a group. (And this also affects the people working on them.) Something to tie the three groups together could be useful, but it could also be troublesome. Predicate, Transformer, Closure, and Factory _could_ all be separated from collections. But they are not big enough to exist on their own. (Plus moving gives backward compatability issues). Even adding some extra interfaces doesn't really make the case. You suggest Named (or Nameable ;-) although I'm not sure what advantage/use it gives. Earlier today in a betwixt discussion I suggested Identifiable. Transformations is a particularly complex case. There is collections' Transform, beanUtils' ConvertUtils, Betwixt and Digester in their entirity, and the new Morphos in the sandbox. One possible solution is to resurect the lang sandbox package which seems to be asleep and add these things to it. Then say everything depends on lang. The real trouble is deciding what is truly absolutely unquestionably common however. If you've seen a logging flame war, you'll know that the more common it is, the higher the tendency for problems. My view: there is merit in this proposal., but I have some doubts about the practicality. Stephen From: Ola Berg [EMAIL PROTECTED] Having looked at the code of almost all commons components, I see that there is a need for a base package that solves many generic problems, that today is solved differently within the packages. Candidates for such a package includes: Transformations - generic transformations (including type conversions and the special and often used conversion: creating Objects from Strings, which is tightly linked to a common factory platform wich is needed both in pool and in configuration which is needed in...) Predicate - Very useful. Also a number of common interfaces that guarantees that the class follows a certain pattern, like Named = all classes that has a String name property etc, which enhances reuse between the packages. This could also be a good spot for 1) an architectural birds view on the packages, and 2) potential migration to a merge effort so that each commons component could drop their special implementation of a feature as soon as the same feature in commonscommons feels OK. I bet there are some design descisions that would have been better today than when it started (\Oh, why didn\'t we let X inherit Y from the beginning?\). commonscommons (no I don\'t propose that name) could be the place for such \second\ tries. /O [EMAIL PROTECTED] 0733 - 99 99 17 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Re: [all commons] Proposal: CommonsCommons package
Hi, I think the most simple solution is to split redistributables like commons-collections.jar commons-transform.jar . It is nothing bad if some common class is maintained in collections. This requires agreement from collections as its not backwardsly compatable Well, for copying the classes and interfaces in another package, one doesn\'t need their opinion. On the other hand: for them to use this other package, it is all dependent on their opinion and their opinion only. Thus there is a time factor there. [snip] Architecture/patterns/design is fine, but in the end we need code. True. I can supply code, implementing the patterns I have suggested (spent last two years trying different methods to implement them). But consensus is needed at some level for others to use the common implementations (I guess the commons project as a whole has the same situation in relation to the other projects: \Hey, use _our_ stuff instead!\). What I said was (removing the words \'patterns\', \'architecture\' or \'design\'): reach agreement on how a general thing is to be done. Without the agreement between at least two component groups, the whole idea of single implementation of the general mechanisms are of no use anyway. Java offers this possibility for fine grain binary object reuse. Done right it translates into a massive heck of many things achieved with absolutely minimal effort. And even if such an ideal case is never to happen, one single general mechanism is a bargain. But it is dependent on 1) someone seeing how a certain mechanism could be used in more contexts than now, and 2) everybody else\'s ability to acknowledge what this person has seen. This will probably mean a slower pace. The role of such a \general reuse project\ is often to come in afterwards, suggesting refactoring of existing API:s (not necessarily afterwards but in practice this is often the case). If and only if the benefits of refactoring are so great that it is worth doing, it will be done. If not, the whole idea is pointless in practice (albeit fine in theory). /O -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
