Am 2015-11-25 um 17:36 schrieb Oleg Kalnichevski:
Folks
I made the first pass at re-arranging packages in HttpCore trunk and
think it is presently good enough for 5.0-alpha1
Please feel free to take a look.
Just checked. Looks like a tremendous move action. I will require a day
or two to have a look at it. At first glance, it looks good.
I am now going to change artifact id from
org.apache.httpcomponents:httpcore
to
org.apache.httpcomponents.core5:httpcore
Please let me know if you have objections or better ideas.
The group id is good. I think we can do better with the artifact id(s).
httpcomponents-core-parent or even simpler httpcore-parent (a parent
should always be named as such)
|- httpcore
|- httpcore-ab
|- httpcore-osgi
We should always keep in mind that the artifact should be recognizable
by its filname or id. Maybe httpcomponents-httpcore, -httpcore-ab, etc.
would be better but they are, of course, longer. (imho)
Those depicted in the tree are probably an acceptable trade-off.
Michael
On Sat, 2015-11-21 at 18:01 +0100, Oleg Kalnichevski wrote:
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<n>
org.apache.http.hc<n>
org.apache.hc<n>.http
where <n> is a major release version
Something else? Any thoughts or preferences?
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
---------------------------------------------------------------------
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
