On 19 November 2015 at 11:32, Oleg Kalnichevski <ol...@apache.org> 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<n> > org.apache.http.hc<n> > org.apache.hc<n>.http > where <n> is a major release version > > Something else? Any thoughts or preferences?
Java package names and Maven groupIds need to be globally unique. Both of these currently start with org.apache, which is a good start as it means possible duplicates are restricted to ASF projects. However we should also try and minimise our use of top-level sub-domains of the org.apache domain. [As Commons does] HC currently uses: Gid: org.apache.httpcomponents Package: org.apache.http Therefore any package names need to be under org.apache.http, e.g. org.apache.http.hc<n> Commons uses the artifactId to distinguish different release versions, keeping the same GID. > Oleg > > > --------------------------------------------------------------------- > 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
