Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 16213 invoked from network); 16 Jun 2002 06:09:30 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 16 Jun 2002 06:09:30 -0000 Received: (qmail 5749 invoked by uid 97); 16 Jun 2002 06:09:41 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 5717 invoked by uid 97); 16 Jun 2002 06:09:41 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 5705 invoked by uid 98); 16 Jun 2002 06:09:40 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) X-Qmail-Scanner-Mail-From: baliuka@centras.lt via jim.skynet.vl X-Qmail-Scanner: 1.03 (Clean. Processed in 1.348197 secs) Message-ID: <00a901c214fc$5ebffdf0$0111010a@user> From: "Juozas Baliuka" To: "Jakarta Commons Developers List" , "Ola Berg" References: Subject: Re: Re: [all commons] Proposal: CommonsCommons package Date: Sun, 16 Jun 2002 08:09:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-4" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: > For additional commands, e-mail: > -- To unsubscribe, e-mail: For additional commands, e-mail: