On 19 November 2015 at 21:17, Michael Osipov <micha...@apache.org> wrote: > Am 2015-11-19 um 12:32 schrieb Oleg Kalnichevski: >> >> 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? > > > Finally -- at long last. This is something I had in mind for more than six > months now. The current approach taken by Apache Commons saved me tons of > work rewriting third party components just for namespace clashes. At some > point, I had a dependency on a third party, closed source library which > still uses HttpClient 3.x (!). Impossible to use 4.x. I had to reverse > engineer the calls and reimplement them from scratch. Wasted two weeks for > that. > > I would highly favor a package change/bump every major release. That would > give everyone the ability to update at their own pace w/o waiting for third > parties, etc. > >> org.apache.http<n> >> org.apache.http.hc<n> >> org.apache.hc<n>.http >> where <n> is a major release version >> >> Something else? Any thoughts or preferences? > > > First of all, I wouldn't use any of those. (Currently referring to package > names only). Artifact ids are a different story. > > org.apache.http: that is too general and confuses me with Apache HTTP > Server. > org.apache.http.hc: http seems redundant here due to hc (http components). > org.apache.hc<n>.http: same here. > > I would do: > > HC Core: org.apache.hc.core5 > HC Client: org.apache.hc.client5 > HC Async Cilent: org.apache.hc.asyncclient5 > > Clean and simple. Each project would be scoped in its namespace. Picking up > sebb's opinion, we even reflect the HTTP domain in the package name.
It's not just my _opinion_. We cannot freely choose the package name, because we are not the only Java project in the world, nor even in the org.apache namespace. Likewise we cannot use the domain com.oracle or com.ibm or even com.apache. We MUST use the ASF domain as the package name prefix or there is a risk of clashes with 3rd party software. org.apache.hc should be OK, since we already use HC for the website. It's very unlikely that any other ASF project will be named HC. > Michael > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
