You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@ok2consulting.com> on 2015/11/21 18:01:22 UTC
HC 5.0: package / module structure; Re: HC 5.0: co-location with HC
4.x
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-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
Re: HC 5.0: artifact id; Re: HC 5.0: package / module structure; Re:
HC 5.0: co-location with HC 4.x
Posted by Michael Osipov <mi...@apache.org>.
Am 2015-11-25 um 21:07 schrieb Gary Gregory:
> [..]
>> |- 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)
>>
>
> I can't really imagine liking httpcomponents-httpcore5-5.0.jar. I do not
> think we need "httpcomponents" in the AID or jar file name, in the GID yes.
I have intentionally brought up this point, though I wouldn't promote
it. It feels too cumbersome. My first and foremost thought was simpyl to
avoid possible filename clashes.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: HC 5.0: artifact id; Re: HC 5.0: package / module structure; Re:
HC 5.0: co-location with HC 4.x
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Nov 25, 2015 at 12:03 PM, Michael Osipov <mi...@apache.org>
wrote:
> 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)
>
+1 to "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)
>
I can't really imagine liking httpcomponents-httpcore5-5.0.jar. I do not
think we need "httpcomponents" in the AID or jar file name, in the GID yes.
Gary
>
> 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-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
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: HC 5.0: artifact id; Re: HC 5.0: package / module structure; Re:
HC 5.0: co-location with HC 4.x
Posted by Michael Osipov <mi...@apache.org>.
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-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
>>
>
>
>
> ---------------------------------------------------------------------
> 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
HC 5.0: artifact id; Re: HC 5.0: package / module structure; Re: HC
5.0: co-location with HC 4.x
Posted by Oleg Kalnichevski <ol...@apache.org>.
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.
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.
Oleg
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-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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with
HC 4.x
Posted by Michael Osipov <mi...@apache.org>.
Am 2015-11-21 um 19:52 schrieb Gary Gregory:
> +1.
>
> I would not mind using Java 8 too.
Believe that is too early. We are using a company-wide, Eclipse
RCP-based product which is on Eclipse 3.4/3.6 and still HttpClient 3.x.
I highly doubt that the dev team will jump on e4 and Java 8 features.
Java 7 is a good base line.
Michael
> Gary
> On Nov 21, 2015 9:03 AM, "Oleg Kalnichevski" <ol...@ok2consulting.com> 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-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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with
HC 4.x
Posted by Gary Gregory <ga...@gmail.com>.
+1.
I would not mind using Java 8 too.
Gary
On Nov 21, 2015 9:03 AM, "Oleg Kalnichevski" <ol...@ok2consulting.com> 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-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
>
>
Re: Re: Re: HC 5.0: package / module structure; Re: HC 5.0:
co-location with HC 4.x
Posted by Michael Osipov <19...@gmx.net>.
> On Mon, 2015-11-23 at 10:51 +0100, Michael Osipov wrote:
> > > On Sun, 2015-11-22 at 20:42 +0100, Michael Osipov wrote:
> > > > Am 2015-11-22 um 20:11 schrieb Oleg Kalnichevski:
> > > > > On Sat, 2015-11-21 at 19:48 +0100, Michael Osipov wrote:
> > > > >> Am 2015-11-21 um 18:01 schrieb Oleg Kalnichevski:
> > > > >>> 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.
> > > > >>
> > > > >> I am quite happy with that. The rename is the very first step to get the
> > > > >> module in shape.
> > > > >>
> > > > >> We should immediately drop deprecated stuff and stuff which is already
> > > > >> in Java 7 by default. Moreover stuff which is in other Commons projects
> > > > >> which we could either verbatim copy into util or simply depend on it,
> > > > >> e.g., Commons Lang StringUtils/Validate.
> > > > >>
> > > > >> Have you thought about adapting group ids and artifact ids as well?
> > > > >> Currently, they seem counter-intuitive to me. Not the way I would expect
> > > > >> proper artifact id names. At least not sturctured the way I am used from
> > > > >> maven.a.o.
> > > > >>
> > > > >> Additionally, the parent POM has a stupid artifact id, as well as
> > > > >> configurations which are by now obsolete or already set by default by now.
> > > > >> I'd like to work on the parent POM to take it to a new level which would
> > > > >> introduce a new artifact id. It could co-exist with 4.x until it goes
> > > > >> out of life.
> > > > >>
> > > > >
> > > > > Are you referring to this one?
> > > > >
> > > > > http://svn.apache.org/repos/asf/httpcomponents/project/trunk/pom.xml
> > > > >
> > > > > If so, by all of means do feel free to improve it.
> > > >
> > > > Yes, that one. I would prefer to create a new one under
> > > > http://svn.apache.org/repos/asf/httpcomponents/pom/trunk/pom.xml to
> > > > avoid disruptive changes with a new artifact id. The POM is so old that
> > > > is hasn't been improved structurally for years. There have been so many
> > > > changes to Apache Parent and Maven Parent from which we can benefit from.
> > > >
> > > > If you are fine with that, I will copy and start my work next week.
> > > >
> > >
> > > Feel free to completely wipe out the existing pom.xml and start from
> > > scratch. Do we really need a new project location though?
> >
> > That is a deliberate choice. Given tha the user base is big, I don't want anyone
> > to open up the "old" URL and see a competely different POM with a different artifact
> > id. My primary goal is stability and predictability. Otherwise I would wipe 8-SNAPSHOT
> > and begin it anew.
> >
>
> Who would that be? Archaeologists?
I can't tell, that is why I am cautious.
> There are tags for previous releases for anyone still interested. See no
> reason of what so ever to keep the old branch.
If that is OK for you. I do not mind to re-start inline.
What do others say?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Re: HC 5.0: package / module structure; Re: HC 5.0: co-location
with HC 4.x
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2015-11-23 at 10:51 +0100, Michael Osipov wrote:
> > On Sun, 2015-11-22 at 20:42 +0100, Michael Osipov wrote:
> > > Am 2015-11-22 um 20:11 schrieb Oleg Kalnichevski:
> > > > On Sat, 2015-11-21 at 19:48 +0100, Michael Osipov wrote:
> > > >> Am 2015-11-21 um 18:01 schrieb Oleg Kalnichevski:
> > > >>> 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.
> > > >>
> > > >> I am quite happy with that. The rename is the very first step to get the
> > > >> module in shape.
> > > >>
> > > >> We should immediately drop deprecated stuff and stuff which is already
> > > >> in Java 7 by default. Moreover stuff which is in other Commons projects
> > > >> which we could either verbatim copy into util or simply depend on it,
> > > >> e.g., Commons Lang StringUtils/Validate.
> > > >>
> > > >> Have you thought about adapting group ids and artifact ids as well?
> > > >> Currently, they seem counter-intuitive to me. Not the way I would expect
> > > >> proper artifact id names. At least not sturctured the way I am used from
> > > >> maven.a.o.
> > > >>
> > > >> Additionally, the parent POM has a stupid artifact id, as well as
> > > >> configurations which are by now obsolete or already set by default by now.
> > > >> I'd like to work on the parent POM to take it to a new level which would
> > > >> introduce a new artifact id. It could co-exist with 4.x until it goes
> > > >> out of life.
> > > >>
> > > >
> > > > Are you referring to this one?
> > > >
> > > > http://svn.apache.org/repos/asf/httpcomponents/project/trunk/pom.xml
> > > >
> > > > If so, by all of means do feel free to improve it.
> > >
> > > Yes, that one. I would prefer to create a new one under
> > > http://svn.apache.org/repos/asf/httpcomponents/pom/trunk/pom.xml to
> > > avoid disruptive changes with a new artifact id. The POM is so old that
> > > is hasn't been improved structurally for years. There have been so many
> > > changes to Apache Parent and Maven Parent from which we can benefit from.
> > >
> > > If you are fine with that, I will copy and start my work next week.
> > >
> >
> > Feel free to completely wipe out the existing pom.xml and start from
> > scratch. Do we really need a new project location though?
>
> That is a deliberate choice. Given tha the user base is big, I don't want anyone
> to open up the "old" URL and see a competely different POM with a different artifact
> id. My primary goal is stability and predictability. Otherwise I would wipe 8-SNAPSHOT
> and begin it anew.
>
Who would that be? Archaeologists?
There are tags for previous releases for anyone still interested. See no
reason of what so ever to keep the old branch.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Re: HC 5.0: package / module structure; Re: HC 5.0: co-location
with HC 4.x
Posted by Michael Osipov <19...@gmx.net>.
> On Sun, 2015-11-22 at 20:42 +0100, Michael Osipov wrote:
> > Am 2015-11-22 um 20:11 schrieb Oleg Kalnichevski:
> > > On Sat, 2015-11-21 at 19:48 +0100, Michael Osipov wrote:
> > >> Am 2015-11-21 um 18:01 schrieb Oleg Kalnichevski:
> > >>> 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.
> > >>
> > >> I am quite happy with that. The rename is the very first step to get the
> > >> module in shape.
> > >>
> > >> We should immediately drop deprecated stuff and stuff which is already
> > >> in Java 7 by default. Moreover stuff which is in other Commons projects
> > >> which we could either verbatim copy into util or simply depend on it,
> > >> e.g., Commons Lang StringUtils/Validate.
> > >>
> > >> Have you thought about adapting group ids and artifact ids as well?
> > >> Currently, they seem counter-intuitive to me. Not the way I would expect
> > >> proper artifact id names. At least not sturctured the way I am used from
> > >> maven.a.o.
> > >>
> > >> Additionally, the parent POM has a stupid artifact id, as well as
> > >> configurations which are by now obsolete or already set by default by now.
> > >> I'd like to work on the parent POM to take it to a new level which would
> > >> introduce a new artifact id. It could co-exist with 4.x until it goes
> > >> out of life.
> > >>
> > >
> > > Are you referring to this one?
> > >
> > > http://svn.apache.org/repos/asf/httpcomponents/project/trunk/pom.xml
> > >
> > > If so, by all of means do feel free to improve it.
> >
> > Yes, that one. I would prefer to create a new one under
> > http://svn.apache.org/repos/asf/httpcomponents/pom/trunk/pom.xml to
> > avoid disruptive changes with a new artifact id. The POM is so old that
> > is hasn't been improved structurally for years. There have been so many
> > changes to Apache Parent and Maven Parent from which we can benefit from.
> >
> > If you are fine with that, I will copy and start my work next week.
> >
>
> Feel free to completely wipe out the existing pom.xml and start from
> scratch. Do we really need a new project location though?
That is a deliberate choice. Given tha the user base is big, I don't want anyone
to open up the "old" URL and see a competely different POM with a different artifact
id. My primary goal is stability and predictability. Otherwise I would wipe 8-SNAPSHOT
and begin it anew.
Some projects even choose a new Subversion tree/Git branch for every new major release.
See Tomcat or Maven. Everything can live side-by-side.
WDYT?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: HC 5.0: package / module structure; Re: HC 5.0: co-location
with HC 4.x
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sun, 2015-11-22 at 20:42 +0100, Michael Osipov wrote:
> Am 2015-11-22 um 20:11 schrieb Oleg Kalnichevski:
> > On Sat, 2015-11-21 at 19:48 +0100, Michael Osipov wrote:
> >> Am 2015-11-21 um 18:01 schrieb Oleg Kalnichevski:
> >>> 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.
> >>
> >> I am quite happy with that. The rename is the very first step to get the
> >> module in shape.
> >>
> >> We should immediately drop deprecated stuff and stuff which is already
> >> in Java 7 by default. Moreover stuff which is in other Commons projects
> >> which we could either verbatim copy into util or simply depend on it,
> >> e.g., Commons Lang StringUtils/Validate.
> >>
> >> Have you thought about adapting group ids and artifact ids as well?
> >> Currently, they seem counter-intuitive to me. Not the way I would expect
> >> proper artifact id names. At least not sturctured the way I am used from
> >> maven.a.o.
> >>
> >> Additionally, the parent POM has a stupid artifact id, as well as
> >> configurations which are by now obsolete or already set by default by now.
> >> I'd like to work on the parent POM to take it to a new level which would
> >> introduce a new artifact id. It could co-exist with 4.x until it goes
> >> out of life.
> >>
> >
> > Are you referring to this one?
> >
> > http://svn.apache.org/repos/asf/httpcomponents/project/trunk/pom.xml
> >
> > If so, by all of means do feel free to improve it.
>
> Yes, that one. I would prefer to create a new one under
> http://svn.apache.org/repos/asf/httpcomponents/pom/trunk/pom.xml to
> avoid disruptive changes with a new artifact id. The POM is so old that
> is hasn't been improved structurally for years. There have been so many
> changes to Apache Parent and Maven Parent from which we can benefit from.
>
> If you are fine with that, I will copy and start my work next week.
>
Feel free to completely wipe out the existing pom.xml and start from
scratch. Do we really need a new project location though?
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with
HC 4.x
Posted by Michael Osipov <mi...@apache.org>.
Am 2015-11-22 um 20:11 schrieb Oleg Kalnichevski:
> On Sat, 2015-11-21 at 19:48 +0100, Michael Osipov wrote:
>> Am 2015-11-21 um 18:01 schrieb Oleg Kalnichevski:
>>> 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.
>>
>> I am quite happy with that. The rename is the very first step to get the
>> module in shape.
>>
>> We should immediately drop deprecated stuff and stuff which is already
>> in Java 7 by default. Moreover stuff which is in other Commons projects
>> which we could either verbatim copy into util or simply depend on it,
>> e.g., Commons Lang StringUtils/Validate.
>>
>> Have you thought about adapting group ids and artifact ids as well?
>> Currently, they seem counter-intuitive to me. Not the way I would expect
>> proper artifact id names. At least not sturctured the way I am used from
>> maven.a.o.
>>
>> Additionally, the parent POM has a stupid artifact id, as well as
>> configurations which are by now obsolete or already set by default by now.
>> I'd like to work on the parent POM to take it to a new level which would
>> introduce a new artifact id. It could co-exist with 4.x until it goes
>> out of life.
>>
>
> Are you referring to this one?
>
> http://svn.apache.org/repos/asf/httpcomponents/project/trunk/pom.xml
>
> If so, by all of means do feel free to improve it.
Yes, that one. I would prefer to create a new one under
http://svn.apache.org/repos/asf/httpcomponents/pom/trunk/pom.xml to
avoid disruptive changes with a new artifact id. The POM is so old that
is hasn't been improved structurally for years. There have been so many
changes to Apache Parent and Maven Parent from which we can benefit from.
If you are fine with that, I will copy and start my work next week.
Michael
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: HC 5.0: package / module structure; Re: HC 5.0: co-location
with HC 4.x
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2015-11-21 at 19:48 +0100, Michael Osipov wrote:
> Am 2015-11-21 um 18:01 schrieb Oleg Kalnichevski:
> > 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.
>
> I am quite happy with that. The rename is the very first step to get the
> module in shape.
>
> We should immediately drop deprecated stuff and stuff which is already
> in Java 7 by default. Moreover stuff which is in other Commons projects
> which we could either verbatim copy into util or simply depend on it,
> e.g., Commons Lang StringUtils/Validate.
>
> Have you thought about adapting group ids and artifact ids as well?
> Currently, they seem counter-intuitive to me. Not the way I would expect
> proper artifact id names. At least not sturctured the way I am used from
> maven.a.o.
>
> Additionally, the parent POM has a stupid artifact id, as well as
> configurations which are by now obsolete or already set by default by now.
> I'd like to work on the parent POM to take it to a new level which would
> introduce a new artifact id. It could co-exist with 4.x until it goes
> out of life.
>
Are you referring to this one?
http://svn.apache.org/repos/asf/httpcomponents/project/trunk/pom.xml
If so, by all of means do feel free to improve it.
Cheers
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with
HC 4.x
Posted by Michael Osipov <mi...@apache.org>.
Am 2015-11-21 um 18:01 schrieb Oleg Kalnichevski:
> 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.
I am quite happy with that. The rename is the very first step to get the
module in shape.
We should immediately drop deprecated stuff and stuff which is already
in Java 7 by default. Moreover stuff which is in other Commons projects
which we could either verbatim copy into util or simply depend on it,
e.g., Commons Lang StringUtils/Validate.
Have you thought about adapting group ids and artifact ids as well?
Currently, they seem counter-intuitive to me. Not the way I would expect
proper artifact id names. At least not sturctured the way I am used from
maven.a.o.
Additionally, the parent POM has a stupid artifact id, as well as
configurations which are by now obsolete or already set by default by now.
I'd like to work on the parent POM to take it to a new level which would
introduce a new artifact id. It could co-exist with 4.x until it goes
out of life.
WDYT?
Michael
> 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-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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org