Return-Path: X-Original-To: apmail-hc-dev-archive@www.apache.org Delivered-To: apmail-hc-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 662D41862C for ; Sat, 21 Nov 2015 17:03:24 +0000 (UTC) Received: (qmail 67139 invoked by uid 500); 21 Nov 2015 17:03:19 -0000 Delivered-To: apmail-hc-dev-archive@hc.apache.org Received: (qmail 67094 invoked by uid 500); 21 Nov 2015 17:03:19 -0000 Mailing-List: contact dev-help@hc.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "HttpComponents Project" Delivered-To: mailing list dev@hc.apache.org Received: (qmail 67079 invoked by uid 99); 21 Nov 2015 17:03:19 -0000 Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 21 Nov 2015 17:03:19 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id A3661C048F for ; Sat, 21 Nov 2015 17:03:18 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1 X-Spam-Level: * X-Spam-Status: No, score=1 tagged_above=-999 required=6.31 tests=[KAM_LAZY_DOMAIN_SECURITY=1] autolearn=disabled Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id 5gy8RkCk0Csz for ; Sat, 21 Nov 2015 17:03:17 +0000 (UTC) Received: from kalnich2.nine.ch (kalnich2.nine.ch [5.148.180.21]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTP id B8C702026E for ; Sat, 21 Nov 2015 17:03:16 +0000 (UTC) Received: from ok2c (84.76.106.92.dynamic.wline.res.cust.swisscom.ch [92.106.76.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by kalnich2.nine.ch (Postfix) with ESMTPSA id 27B0D1600FC for ; Sat, 21 Nov 2015 17:03:10 +0000 (UTC) Message-ID: <1448125282.25520.8.camel@ok2consulting.com> Subject: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x From: Oleg Kalnichevski To: HttpComponents Project Date: Sat, 21 Nov 2015 18:01:22 +0100 In-Reply-To: <1447932726.2577.28.camel@apache.org> References: <1447932726.2577.28.camel@apache.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Folks I moved code to org.apache.hc.core5 namespace as the first step. Now I would like to move things around in order to make the package structure more consistent, reduce circular dependencies between packages and prepare for messaging code separation into HTTP/1.1 and HTTP/2 compliant implementations. However, more importantly I would like to fold httpcore-nio into httpcore. Separation into two modules made sense in 2005 but hardly makes any sense today in 2015. Please let me know if you have any objections to that. Oleg On Thu, 2015-11-19 at 12:32 +0100, Oleg Kalnichevski wrote: > Folks > > I would like to start working on the first alpha releases of HC 5.0. > > There is one issue that still needs to be discussed though before I can > proceed. We need to decide on how we intent to maintain compatibility > with HC 4.x. It is pretty clear that maintaining full compatibility is > unrealistic and probably counter-productive. HC 5.0 is likely to have > different APIs especially once HTTP/2 transport is implemented. > > A pragmatic approach could be to make HC 5.0 and HC 4.x deployable > within the same class loader context (so called co-location). This is > what Apache Commons do with their major releases. We should do > likewise. > > Effectively co-location is about moving major releases to a new package > space like org.apache.commons.lang3, org.apache.commons.lang4, etc. I > think we should adopt a compatible scheme. The trouble is that when the > project was started in 2005 the choice of 'org.apache.http' was pretty > natural and in line with Jakarta practices (anyone here still remembers > Apache Jakarta?). Now it can be seen as too presumptuous. This would be > a good opportunity to fix that. > > What would be a better name space for the project in your opinion? > > org.apache.http > org.apache.http.hc > org.apache.hc.http > where is a major release version > > Something else? Any thoughts or preferences? > > Oleg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org > For additional commands, e-mail: dev-help@hc.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org