Return-Path: X-Original-To: apmail-commons-dev-archive@www.apache.org Delivered-To: apmail-commons-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5898DB451 for ; Mon, 16 Jan 2012 20:49:16 +0000 (UTC) Received: (qmail 46286 invoked by uid 500); 16 Jan 2012 20:49:15 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 46123 invoked by uid 500); 16 Jan 2012 20:49:15 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 46114 invoked by uid 99); 16 Jan 2012 20:49:14 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Jan 2012 20:49:14 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [212.227.126.187] (HELO moutng.kundenserver.de) (212.227.126.187) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Jan 2012 20:49:07 +0000 Received: from [192.168.178.20] (dslb-088-069-195-043.pools.arcor-ip.net [88.69.195.43]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0Ls7Op-1SoMxH3zjj-013PFT; Mon, 16 Jan 2012 21:48:45 +0100 Message-ID: <4F148D2A.4000000@oliver-heger.de> Date: Mon, 16 Jan 2012 21:48:42 +0100 From: Oliver Heger User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Commons Developers List Subject: Re: [configuration] Generics and next release References: <4F131F46.30005@oliver-heger.de> <4F141FE6.5030109@apache.org> In-Reply-To: <4F141FE6.5030109@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:scnKxJ4Zmrx047L2090UnhUT5sWVsxYw4djdPQoDBoG YO2DA0V3XCDkOtOutrsCMgHBpBG9IrbMOiJNsiP6+KbtUkvKvY ZnCdoqO0ayjMl73/ZmRnNCYsWqXhT9mOglTd4z/yvY5+GNWEZy NAMJyfwOLJMMQe87fjFlkwVTFLHJzP/7b72fO1mhVHE5JdnDkl GeYTBx2/Nzv+lXrzbxJC28rlYhT4CqPLmbLf5JTjK6NJokBiII w/eUKvHtuqrnr3eOqAtPI7h3Kcmn36RcwAs+D7Fes/GtNcGGnm qLn0gy2NBDUHMnlBUcWgKcsgix9lkvBXq3b0DTsMpTtJbcxd6h sMxKsu/8gUKDRrdPFD8o= Am 16.01.2012 14:02, schrieb Emmanuel Bourg: > Thank you for the hard work Oliver. The generified API alone is worth a > release IMHO. Other Java 5 features like better synchronization can be > added later. > > I think the heavy refactoring can still take place on the experimental > branch, the Java 5 migration is simply no longer one of its main > objectives. > > Emmanuel It is also my point of view that we have enough stuff for the 1.8 release. It is not a problem to push out version 1.9 with new features in the near future. That said, release preparations always take some time, so Ralph, if you come up with some code or enhancements, just go ahead. Regarding the experimental branch: Maybe we should step back and start a new discussion about design changes, new features, and the scope of Configuration 2.0? Just to get a clearer direction. Oliver > > > Le 16/01/2012 02:21, Ralph Goers a �crit : >> >> On Jan 15, 2012, at 10:47 AM, Oliver Heger wrote: >> >>> Hi all, >>> >>> the "generification" of [configuration] is now complete. The tests >>> were addressed, too. Clirr does not report any compatibility breaks. >>> >>> If you do not have any objections against the current API, we can >>> start thinking about a new release. There are some Jira issues I am >>> going to have a look at. Are there other wishes/changes that should >>> go into a 1.8 release? >> >> 1. Are we dropping the experimental branch? >> 2. Now that we are using Java 5 I'd like to change the locking I added >> from syncrhonization to read/write locks as that will significantly >> reduce contention thread contention. >> 3. It is my intention (whenever I can find the time) to create an >> AggregateConfiguration that works similar to CompositeConfiguration >> but supports HierarchcialConfigurations. This will be much more memory >> efficient than CombinedConfiguration, at least when used in a manner >> similar to DynamicCombinedConfiguration, and have a lot less locking >> issues. However, I'd like it to be configurable from >> DefaultConfigurationBuilder. Needless to say, I don't see this >> happening for a 1.8 release if that is going to happen soon. >> 3. It is still on my wish list to make the hierarchical configuration >> the base instead of the flat structure, but that will have to wait for >> a 2.0. >> >> Ralph >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >> For additional commands, e-mail: dev-help@commons.apache.org >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org