For all the truly common classes mentioned (Predicate, Factory etc), it really is a shame that they reside under the collections title or wherever. Another project needs similar functionality and they have to know that they have to go looking in collections for the answer?... this can only lead to dupliction of effort at some point.
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), but at the very least, the Commons project needs a common project. :) A "lang" or similar would be super. Arron. Ola Berg wrote: >>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) someo >ne 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]>
